Breaking one large Craft app into multiple smaller apps

Question

Some background information:

We use a Craft app that has several modular components that we've put into separate plugins. IE: a purchase plugin, "logged in" plugin, and so on.

I'm thinking of breaking this very large app into multiple smaller Craft apps which would be able to be deployed independently to AWS instances. This way when we make a change to our Purchase flow we no longer need to redeploy the entire app /remove-headaches.

I've been looking around and haven't found much on terms of people doing this with Craft? The instances would all share the same database instance since we don't store any data in the database anyways so that wouldn't be an issue... but is it just as simple as including the /craft and /public folder on every instance? How would these apps access each other's functions? So if the Purchase Plugin needs to access something from the "Logged in" plugin on the other app it would need to be via HTTP request which would hit the other app's index.php and go from there? I guess we would need to build a gateway for these apps to speak to each other if we need to do cross-app talk?

This is what I was thinking it would look like:

1. Remove "Purchase plugin" from the original repo.
2. Create a new repo for purchase app
3. Plug the "Purchase plugin" into the new app which only has the necessary folders for Craft to run. Ie: craft and public folders with only this one plugin.
4. Create a gateway for requests coming from "Logged in" app and "Purchase app" to correctly direct to the other app for cross-talk. This would route purchase app requests to logged in app if/when it needs to access something.
5. These craft instances would point to the same database that has data about all plugins. Or would it be better to each have it's own database? Is this something that would become hectic to maintain for business partners?

Essentially I'd be creating an "API" out of these two apps. They would both be ale to stand independently and the implementation can change for either one so long as it fulfills its contract. This would allow me to deploy them separately and have separate teams maintain them without worrying about something in one app being broken because of something in the other app being deployed.

Answer 1

The instances would all share the same database instance since we don't store any data in the database anyways so that wouldn't be an issue...

Brad or Brandon from P&T is probably going to chime in here with a better answer but it sounds like more trouble than it's worth.

For one thing, Craft relies on the database to determine if plugins are enabled or not. If your plugin is only "enabled" on one instance, the database is going to reflect that state. That sound likes a recipe for disaster.

Even if you make every piece self-contained, with multiple databases for each that "talk" to each via API like JSON or something else, you'll also have the problem of updating Craft's core files in multiple places whenever Craft itself gets updated. Multiple that by how many instances you have to determine what factor of headache you want...

Modularity is a good concept but it reads to me a bigger problem here is your deployment strategy and getting everyone on the same page as to what everyone should be working on, development wise. If one of your developers breaks the API for the other team that's calling it, you're just as screwed as before.

If your team is pushing up code that's broken, you want some way to revert back. That's true of any kind of system, modular or not. Small commits often. You might want to look at DeployBot or Capistrano or something else of that nature.