You should still be able to adopt a lot of this episode's code to accomplish this.

Have a look at this episode https://www.driftingruby.com/episodes/docker-on-rails-7 as I think it covers a lot of the issues that you may have. I'll try to fill in some of the gaps as well.

database.yml - This is getting covered by having the environment variable in our docker-compose file. DATABASE_URL=postgres://postgres:postgres@postgres:5432 is getting set and available to the Rails container. in the database.yml file, you'd just need to add

development:
  url: <%= ENV['DATABASE_URL'] %>

Tests - An alias that I use from that episode is dcr. I will run this command to pull up a shell in the Rails app container. From there, I can run my tests as I normally would. Though, I do run system tests as headless. 

dcr bash

Conflicting ports - You need to decide which services you want to use and where they are. If you have a postgresql instance that you keep installed locally for various reasons, but want to spin up a docker instance of postgresql for your development, you're going to have to change the ports on one of the running instances. That really is up for you to decide, but I would recommend changing the port for the one that you interact with the least.

Working through a feature in a docker dev environment - I'll use the dcr alias for anything that I need to do when interacting with a running container. However, for pushing to git, I keep my code on my host machine. It is linked through a container through the volume mounts. So, in that case, I would use my host machine's git to push to the repository.

Caching & Multiple versions - I'm a believer that docker containers should be treated like cattle (verses pets). We should be able to destroy and recreate them without issues. If I have a situation where I'm installing a bunch of gems, I may specify a directory and use volume mounts.

custom Rails application template - I have an episode for that! https://www.driftingruby.com/episodes/easy-deployments I use this methodology for any application that I'm creating. Combined with the next episode after that one, I can create a new dockerized Rails application that I use for development AND I can deploy it to a FQDN within minutes of creating the application.

Hope this addresses some of your concerns.

  01fe20bec001 It seems to work fine for me when I pulled down your code. 

The one difference is that I noticed that you did not have stimulus-autocomplete added to your package.json, so I added it with

yarn add stimulus-autocomplete

I think when your dataset is small (up to a few million records), your querying complexity is low and you don't need super high performance then the database full-text searching should be sufficient. As an application's requirements change as well as the dataset grows, you can start to consider moving the heavier bits over to a full-text engine like elasticsearch. 

I've made the mistake of "prematurely optimizing" my applications and used Elasticsearch/Searchkick from day 1. The growth was never there and the query complexity remained low for the life of that product. We would have been find with some simple querying and/or using full-text within the database. Instead, we added infrastructure complexity and cost without the justification.

Then, you also have to look at cases like Hey email where they are doing massive amounts of records. I'd imagine that the query complexity is low, but their dataset is massive. Performance is also very important in these situations because someone isn't going to wait 10 seconds for a search to complete and be happy with that kind of delay.

As of Sidekiq 7, you do not have to have a separate service running. Previously or now optionally you ran Sidekiq as a separate process.