I am a rails developer that normally prefers the “majestic monolith”, and I will normally recommend to not doing it, and even I sometimes think if I should split my apps or not. But I think that at least in my this normally caused by hype or frustration.
So this is a list for you and for me, with some things to consider when you have “reasons” for splitting your app like…
Maybe you are thinking that with rails every interaction will be server side rendering….
Are those parts the majority of the app? Do you want to increase the complexity of the whole app for does parts? Can you plug those apps with stimulus.js?
Was the mess caused by not splitting? Could stimulus.js and turbo help to reduce that complexity?
After that mess… Do you now have and idea of how you can structure your code better?
When our system tests start getting slow and complicated we can think that is easier to have two separate test suites, one for the api and one for the front end app.
And maybe it is true that is easier to test both things as a separate thing, but it is just easier as it is easier to write a test for a single method than a system test.
If you split are you going to avoid system tests that execute through both parts? Are you going to feel the same confidence?
This is true, but I think that there is no easy path, finding good engineers is not an easy job.
It will be hard to find a great full stack rails developer, but it will also be hard to find a great frontend developer and/or backend developer.
As you have seen I am very biased to the monolith, maybe this should not be your only reference for this decision, but I hope it could be useful in some way.
I send an email each week, trying to share knowledge and fixes to common problems and struggles for ruby on rails developers, like How to fetch the latest-N-of-each record or How to test that an specific mail was sent or a Capybara cheatsheet. You can see more examples on Most recent posts or All post by topic.