1

I am starting a project based on multiple webapplications (Website, ControlPanel, RestAPI) each based on the same Data[bases] and an MVC framework.

To avoid parallel code maintenance I thought of having the same model-files for each app. But when thinking deeper all possible approaches have some pro's and con's. I thought I'd ask some experts.

Possible ways to go (I know of) :

1. Plugin ~one4all

The very core of logic encapsuled as a plugin which is deployed in each app.

++ Only one model per table for all apps

-- One bug can crash 4 apps

-- lots of unused code per app

2. Duplicated code ~all4one

Double maintenance of duplicated model files.

++ Bugs affect only one app

++ Models does not contain unused code

-- Inefficient development

3. Api between apps ~lonewolves

Apps get its data from an api.

++ one code serves all apps

-- uncommon approach

-- massive overhead

4. Models symlinked ~lazy1

One application holds the model files, the other apps will symlink/include it.

++ almost no extra work to do

+- seems hilarious

-- one bug affects all apps

-- could restrict debugging

Are there more possible approaches? Which one is common/recommended? I don't want to combine the functionality of all apps into one to avoid crashing the whole thing with one pull.

More approaches and ideas are very welcome. Thank you in advance.

Community
  • 1
  • 1
  • Can you show your sample model code? – Hien Nguyen Feb 08 '19 at 02:18
  • There is no code. I am asking for logical structuring of the applications I wanna code. –  Feb 08 '19 at 02:33
  • I don't really think that "One bug can crash 4 apps" is relevant as a negative. In any given project, we strive to "not repeat ourselves" in order to minimize bugs and to gain time. Although you have several apps, I would look at it as a single project and focus on architecture and unit testing. Plugins sounds nice, but I'm not an expert. Could you explain why there will be "lots of unused code per app" ? – Ariles Feb 08 '19 at 13:51
  • Number threes "--" are false. Three essentially describes a micro service architecture which is used by almost all big players like Netflix for example. They do exactly this. And the overhead is virtually nothing, it's clearly not "massive" because the requests happen in your own network and these requests are very fast. I can't find the video with the benchmark right now :( – floriank Feb 08 '19 at 15:43
  • Agree with @Ariles that the "one bug" thing isn't really an issue. If you use your option #2, then either you sync the code between them (in which case the bug gets replicated) or you don't (in which case bug *fixes* don't get replicated). And "unused code per app" doesn't seem like a problem either; code that isn't running doesn't cause overhead, and disc space to store that extra code is going to be meaningless in the grand scheme. So, I'd go with #1, though I may be biased because I've actually done projects this way. – Greg Schmidt Feb 08 '19 at 19:03

2 Answers2

0

Implement SOLID in proyect. Valid all framework.

Sergio
  • 2,369
  • 1
  • 15
  • 22
0

One option you missed is to keep the projects as one. Instead of splitting the model, and thus maintaining it across three or more separate projects, you could make only one project, and just divide the portions with controllers. Although this method can create a monster of a project, it can also be kept in one place, and many controllers can divide the project down into easily managed pieces.

If it were me, and I wanted to keep the projects as separate cakephp projects, I would probably end up duplicating code. It's not that bad to copy and paste. That's what I do on a website that I work on, in order to separate testing and production.

Although, I would also probably try including separate files, which contain the same code. Even though you are using cakephp, you can also use php code. What if you require() files that contain cakephp logic. Not sure if this works, but I would at least give it a try.

Millar248
  • 403
  • 8
  • 18