many sub application or a big one

Question

i have a question concerning a best practice on application architecture and managment.

I have an application developed in Yii2 (php+mysql) that is the main company backend. At the moment there is the request to develope other Yii2 application in some way connected to the main one.

I look at two possible ways:

• create the new applications merging it with the main one;

• Pros

  • all application with the same UI
  • single login
  • everything in one place

• Cons

  • one big git project
  • more difficulties to manage and realease updates

• leave it like separate projects

• Pros

  • separated git project
  • easier to realease updates without conflicts
  • easier to implement different logic between app

• Cons

  • implement a single sign on system between all the app
  • duplicated libraries and common files

This is my analysis, what about your considerations? Thanks to all would give advise.

Answer 1

There is no "one-size-fits-all" solution to this, it all boils down to the question what exactly

in some way connected to the main one

means. If both applications, especially from the viewpoint of their use cases, are tightly coupled and interwoven, with an interface between them which changes frequently, then it may be better not to separate them. If they, however, can be separated in a meaningful manner, maybe with a decoupled release management, then two applications maybe the better choice. But let me comment on some of your pros and cons:

all application with the same UI

depends on what you mean by this: if you mean "similar looking UI", this is quite independent from the decision for one or two applications. If you mean "just one UI for both", then this might be an indication the use cases are so entangled that one application will be better.

"single login" vs "implement a single sign on system between all the app"

is indeed a little bit more effort when creating separated applications, but should IMHO not be the driving factor behind the decision.

one big git project

is not necessarily a bad thing, managing too many git projects can actually become a downside (but of course, when creating separate apps you will still be free to use just one git repo). Separate git repos are favorable if there are different teams for each application, and there are no common, reusable libs in the repository, but if there is only one team, I can imagine one repo might be the better decision - for both approaches.

Then you wrote

more difficulties to manage and release updates

on the con-side for "one application" - that can be actually true, or it can be false, it depends. If there are stable interfaces between the two applications, so you can mix different version of app#1 and app#2 almost arbitrarily, then releasing a newer version of just either app#1 or app#2 will be easiy. If there are no stable interfaces, and there will be only specific version combinations of app#1 and app#2 compatible with each other, then managing and releasing updates for separated application will increase your configuration management costs, and it will probably be easier for a single application.

duplicated libraries and common files

When you have two applications with common libraries, those libraries should not be duplicated, they should be reused from both applications. If you mean "duplicated on the production server": space for typical libs is cheap, and the deployments should be automated by some scripts, so deploying the same lib twice should not make any problems. And "common files": if there are things in these files which will need to be maintained in both applications in parallel, try to move the commonalities into a common library and reuse it.

TLDR; this depends heavily on the requirements of your individual case, functional as well as non-functional ones.