<blockquote>
  <p>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...</p>
</blockquote>

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

<p>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.</p>

<p>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 <em>Craft</em> itself gets updated. Multiple that by how many instances you have to determine what factor of headache you want...</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2016-06-20T17:52:43.400Z
Well said... it feels like OP is trying to solve the wrong problem.
Lindsey D
CC BY-SA 3.0
2016-06-20T19:41:07.280Z
To me it feels weird to have this massive of an app that needs to be deployed in full every time a change is made. It feels odd deploying something at opposite "ends" of the app when no changes were made. 

It's not that the process is broken, I just feel that it could be done better. Plus this would allow for better autoscaling on AWS. If 80% of our users are purchasing why would we want to scale up the entire app instead of just the portion that contains the purchase piece? 

Maybe it's not easy with Craft (or any CMS for that matter), but figured it was worth a shot to look into.
Exziled
CC BY-SA 3.0
2016-06-20T20:07:34.153Z
Not sure what you mean about needing to deploy in full? That's kind of what I was trying to allude to in the answer. When you push an update to one of your Craft plugins, you don't need to overwrite every single file on the file system again, just the files in your plugin. If you use something like git and post receive hooks, you can do it automatically. [This](http://joemaller.com/990/a-web-focused-git-workflow/) is an older post but shows the process.
RitterKnight
CC BY-SA 3.0
2016-06-20T20:36:50.103Z
@Exziled Can you elaborate on how your currently handle your deployments?
Brad Bell
CC BY-SA 3.0
2016-06-20T20:47:51.523Z
@RitterKnight -- When we deploy to an environment we have Jenkins tar and gzip all of the files in the /craft and /public folders. We then send these to an Amazon S3 Bucket and then use AWS OpsWorks to grab these files and put them onto an EC2 instance. 

I can't think of a way to break it apart so that the "Purchase" and "Logged In" plugins could be deployed separately unless they each live in their own repos but with the current build process of tarballing the /craft folder I don't think it's possible.
Exziled
CC BY-SA 3.0
2016-06-20T20:48:00.147Z
@BradBell - I commented above.
Exziled
CC BY-SA 3.0
2016-06-20T21:21:52.690Z
I'm not an AWS/Jenkins expert but looks like Amazon's CodeDeploy [integrates](https://blogs.aws.amazon.com/application-management/post/TxMJROUIFQZ4HS/Setting-Up-the-Jenkins-Plugin-for-AWS-CodeDeploy) with Jenkins? Not sure if that's a better fit than OpsWorks in your workflow...
RitterKnight
CC BY-SA 3.0
2016-06-20T17:45:27.800Z
2016-06-20T17:50:33.433Z
2016-06-20T17:50:33.433Z
RitterKnight
<p>Some background information:</p>

<p>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. </p>

<p>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.</p>

<p>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?</p>

<p>This is what I was thinking it would look like:</p>

<ol>
<li>Remove "Purchase plugin" from the original repo.</li>
<li>Create a new repo for purchase app</li>
<li>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.</li>
<li>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. </li>
<li>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?</li>
</ol>

<p>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.</p>

<deployment><bootstrap-craft><aws>
Breaking one large Craft app into multiple smaller apps
# Breaking one large Craft app into multiple smaller apps

(Asked by: username_0 on 2016-06-20)

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.

**Tags:** deployment, bootstrap-craft, aws


---

## 1 answers

### Answer by username_1 on 2016-06-20. Score: 3

> 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.

> **Comments:**
> **username_2**: Well said... it feels like OP is trying to solve the wrong problem.  
> **username_0**: To me it feels weird to have this massive of an app that needs to be deployed in full every time a change is made. It feels odd deploying something at opposite "ends" of the app when no changes were made.   It's not that the process is broken, I just feel that it could be done better. Plus this would allow for better autoscaling on AWS. If 80% of our users are purchasing why would we want to scale up the entire app instead of just the portion that contains the purchase piece?   Maybe it's not easy with Craft (or any CMS for that matter), but figured it was worth a shot to look into.  
> **username_1**: Not sure what you mean about needing to deploy in full? That's kind of what I was trying to allude to in the answer. When you push an update to one of your Craft plugins, you don't need to overwrite every single file on the file system again, just the files in your plugin. If you use something like git and post receive hooks, you can do it automatically. [This](http://joemaller.com/990/a-web-focused-git-workflow/) is an older post but shows the process.  
> **username_3**: @username_0 Can you elaborate on how your currently handle your deployments?  
> **username_0**: @username_1 -- When we deploy to an environment we have Jenkins tar and gzip all of the files in the /craft and /public folders. We then send these to an Amazon S3 Bucket and then use AWS OpsWorks to grab these files and put them onto an EC2 instance.   I can't think of a way to break it apart so that the "Purchase" and "Logged In" plugins could be deployed separately unless they each live in their own repos but with the current build process of tarballing the /craft folder I don't think it's possible.  
> **username_0**: @BradBell - I commented above.  
> **username_1**: I'm not an AWS/Jenkins expert but looks like Amazon's CodeDeploy [integrates](https://blogs.aws.amazon.com/application-management/post/TxMJROUIFQZ4HS/Setting-Up-the-Jenkins-Plugin-for-AWS-CodeDeploy) with Jenkins? Not sure if that's a better fit than OpsWorks in your workflow...  

---

