loading...

re: Rails 6 Dependency Management with Service Objects VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Hi! This looks awesome. How has it been working with Rails Engines? I was looking at them for a project in the past, but decided not to do it at ...
 

Great question! Maybe I need to write about that next 😉.

I will be honest: engines have had their ups and downs. In my workplace, we introduced 3 engines into our app at once. One of my coworkers documented a list of all the small modifications you have to make on top of the bootstrapped engine from running that plugin new command. I would recommend that if you plan on adding more than one engine - it's a great resource.

So far the pros have been:

  • You have to be more cognizant of dependencies - which was why we decided to go in this direction. Previously it was really easy for us to leverage tightly related code that didn't need to be that tightly knit together. So plugins have definitely made us better about thinking WHERE logic should live and HOW you access it between the core app and the engine.
  • Having an isolated environment does make development on the engines easier. It's nice to be in a box and I think it makes it easier to think about the purpose of that engine vs. if it was inside the core app. Because of this, we actually ended up deleting one of the engines we thought we needed and left that code in the core app. That turned out to be a good decision to NOT use an engine.

Some of the challenges:

  • Getting them set up just right has been a bit tough; knowing when the engines DO have access to the core app and when they don't can sometimes be tricky. So things like API requests occurring across the engine and the core app and testing setup took some time to figure out.

Overall I'm still happy with our decision to use them. But they are definitely not a tool I would recommend 100% of the time to 100% of projects. They're a very niche tool that works well in a specific context.

Code of Conduct Report abuse