Advice on Merging Applications in a Distributed Monolith with REST and ActiveRecord

System Design
1

This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.

Message originally sent by slack user U70X77PNXY6

I’m working on a distributed monolith. We want to start merging applications.
Currently the apps use REST to talk to each other, but they use the same database server. As a first step we want to replace the REST calls with direct ActiveRecord calls. We either want to use Rails` multi database support or use Postgres foreign tables. Does anyone have experience with this?

2

Have you tried starting with one app by merging it and keeping the REST calls?

3

Next step could be to replace a REST call with a method call to the service object that implements the backend

4

Message originally sent by slack user U70X77PNXY6

Have you tried starting with one app by merging it and keeping the REST calls?

We are trying that with one application. The problem is that every app talks to every other app :grimacing:

5

Message originally sent by slack user U70X77PNXY6

In the image the thicker the line, the more REST endpoints are implemented. Merging app A into B would require every other app that talks to A, to also talk to B.

6

Message originally sent by slack user U71S0G4TZY5

I would suggest tackling one endpoint at a time.

Using your example, if you are merging A into B, then pick a single endpoint from A, and copy that endpoint into B. Mark the A endpoint as deprecated, then begin to change all consumers of the A endpoint to the B endpoint. Finally, remove the A endpoint. Repeat until all A endpoints are moved, then remove A altogether. Subsequently repeat for all applications.

You potentially reach a point where an app is consuming its own endpoint — and this is when you can remove the endpoint altogether and handle the logic server-side (presuming there are no public consumers).

It takes time, and you have some risk of duplicate logic existing for a temporary period of time, but so long as contract tests are robust, I think this approach could work.

I would encourage very verbose logging and usage of custom response headers to monitor consumers vs producers.

7

Message originally sent by slack user U70X77PNXY6

Thanks for the tips <@U71S0G4TZY5>!
Doing it endpoint-by-endpoint would have my preference as well, but some on my team want a more big-bang approach :confused: Maybe I can convince them.