KingFish
KingFish

Reputation: 9183

Architecture Design: Separating Apps and Interacting by Way of APIs

I'm creating an entire website that will me a conglomeration of a bunch of smaller sites. Naturally they're all interrelated, but different people will log into different sections for different reasons.

One thing I'm trying to get away from is a a monolithic architecture, I like the idea of breaking up everything into subprojects so one team can work on one project, one team can work on another project, etc.

My question: I'm hearing more and more people doing interproject communications by way of restful APIs rather than having direct access to the database.

For instance:

                app 4 
                  |
app1 ----->   central core <------app2
                  |
                app 3

so apps 1-4 would communicate with a central core by way of APIs. They would have their own individual models for their own specific applications, but a central core would contain the bulk of the application.

My question: Is it correct implementation to go about this design, or should I just stick with the traditional monolithic project which contains one model implementation?

Where can I get examples of good system architecture?

Thanks

Upvotes: 1

Views: 76

Answers (1)

Saurabh
Saurabh

Reputation: 1069

There is no doubt that abstracting the functionality into API is the right way to go to reduce the maintenance overhead. You should see a project like llvm.

The problem which comes with breaking your application into a "core" and a "driver" is, that the software upgrade gets a little tricky. Because now you have to upgrade both core and driver together. That is the biggest issue in shipping software as a library. If core is old and driver is new then it will not work.

But I do not think this is an issue for you.

THere are many good books on software design.

Upvotes: 1

Related Questions