jomaestradama  You shouldn't be bringing in the two background workers unless you have a very specific use case. However, if you're transitioning from one to the other, just keep in mind that you can have only one ActiveJob adapter enabled at a time. I don't recommend trying to switch them on the fly as the jobs are getting processed as it could end up with some really strange situations where the wrong adapter is processing a job. You can always enqueue the jobs as you normally would without ActiveJob and just queue them up as if you weren't within a Rails application. But, this kind of circles back to why have two different kinds of background workers that are performing similar functionalities. One reason for two workers would be for something that had mission critical transactions. Think of it like a banking transaction where you needed something to be queued up with a critical need for ensuring that the job did not get lost. Using DelayedJob to persist the job information in the database could be a viable use case, but the other background jobs were of much less importance so Sidekiq is used for those. 

I feel that the default conventions are sufficient in most cases. If something else is needed for a more unique use case then add just the one in.

Yea, most often when I find that something isn't working the way I expect in some kind of event listener or when we lose the context of the stimulus controller, I find that binding solves the issue.

  David Bean  I used the Fulltext Search within MySQL for some time, but ultimately ended up moving to Meilisearch as it provided more functionality. However, the Fulltext Search within the database got me very far for many years.

  jaroslavhorak I'm using the browser session instead of current_user so the session could be replaced with user

Order.create(session_id: session.id, ...)
Order.create(user: current_user, ...)

Sorry for the confusion.