-2

We have created an LMS using Angular JS 1, Python(Django ) API and mongoDB as a database. Now we want to extend the LMS to make it a job portal. We have decided to create another front end project and keep the database as same. We decided to change the front end as we want to create the new project in Angular 5 and get rid of Angular JS 1 eventually.

My doubt is regarding the service which we wrote in Python. We have api.applicationname.com as the service. Shall we create a completely new project for the service ? ie A new git repository and a new URL. Or shall we edit/add to the existing git repository and the service URL? I am seeing the following advantages for using the same old services project.

  1. We don't need to create another git repository and project tracking will be easy.
  2. We don't have to rewrite the login APIs or reusing the existing APIs will be quite easy as it will be a single project. I understand that even if we are creating a new service, we can still call the old service. But is there any advantage of doing like that other than asking the developer to remember another API and I am afraid that as different people will be working on different projects, there are high chances that developers will end up writing the services again.

Currently we have 611 services in the current python project.

  1. If we add more services to it, will it be too complex ?
  2. Will it be too heavy for nginx to handle?
  3. Is there any other factor that we need to consider while taking this decision?
  4. Will there be any performance issue if we add a lot more services to the existing project?

If I have missed any major points, please let me know that as well. Thank you.

Please note that the question is not about using different framework in one project or front end and back end in one project. Same framework and technology is used. Just that we are extending it with additional functionalities.

Cyber Square Professional
  • 105
  • 5
  • 1
    Possible duplicate of [Two frameworks one repo](https://softwareengineering.stackexchange.com/questions/334491/two-frameworks-one-repo) or [When to separate a project in multiple subprojects](https://softwareengineering.stackexchange.com/questions/194822/when-to-separate-a-project-in-multiple-subprojects) – amon Mar 15 '18 at 17:28
  • It is not a duplicate of https://softwareengineering.stackexchange.com/questions/334491/two-frameworks-one-repo or https://softwareengineering.stackexchange.com/questions/194822/when-to-separate-a-project-in-multiple-subprojects – Cyber Square Professional Mar 15 '18 at 18:52
  • 1
    Simply stating that they're not duplicates is not enough. You need to explain why you think they are not duplicates. – Robert Harvey Mar 15 '18 at 18:58
  • 1
    Ok. The first one "Two framework one repo" talks about using two framework in one project. In the second question "When to separate a project in multiple sub projects" talks about server side scripting and client side scripting on the same project. In my case the frameworks are same and it is completely a back end (python django) project. In simple words the question is "Is it better to create a services API with 200 services or create two 100 services for a project which connects to the same database? The developer may or may not be different. Also there is no change in the Python version. – Cyber Square Professional Mar 16 '18 at 04:30

1 Answers1

0

I have decided to go with the same service project. I talked to some of the experienced persons from industry and the findings are below:

Disadvantages of going for two services :

  1. Since the database is same, if you go for different services, you will end up duplicating many services. For example registration, user login etc.
  2. It may lead to data integrity issues especially if you are using a no sql database. For example if the developer for the new project is different and if he writes a registration form with totally different fields, it can break the existing user logins in the other application or reports. In our case even if a user is registered in the new application, he/she should have access to the old application using the same credentials.
  3. Project management overheads will be more. It is not just about keeping two repositories but hosting it as a different service. If you are going to host it as a same service, again it will be nightmare to manage the code versions.
  4. If you need to reuse any existing service, the cross service calls will be complicated and difficult to maintain.

Advantages of going for a new service:

  1. Even though the development effort will be more, the developer can develop the services fast as they don't have to worry about the existing service.
  2. You can create a different python environment for running the new service. So if you are using any python library which needs to used only in the new project, it need to be installed and it will not impact the old the services project. A counter argument for the same is that if you want to use any new python library for the development of the new service, it is better to rewrite the old code as well so that the performance of the existing service is also improved.

Final recommendation:

Create the service in the same project in such a way that it can be moved to another project in a later stage if required. For example use some coding pattern or different app in Django project that will help to identify the new codes easily.

Go for the new project if you are planning to change the framework or you want to completely get rid of the existing services project. If you are going to use the old one and new one, make it as same project. One of my friends with more than 13 years of experience told me that in a project in CTS, he had same service project for close to 10 applications. It is better to have one service project with 200 services than having two 100 services project connecting to the same database with same technology and framework.

Cyber Square Professional
  • 105
  • 5