CODEWITHSUNDEEP
web-servicesapiweb-applicationsmobilearchitecture
Emad
Emad

Reputation: 4200

Architecture design, how to setup our development infrastructure to support multiple apps and app types?

We are trying to setup the infrastructure for all our developments... We will be building web apps, mobile apps, other plugins for outlook and so on

All these apps will be using the same "data"...

We were thinking for web apps we would use single-page angular apps that talk to an API... Some of these apps are external and some internal i.e. inside/outside firewall...

The question is do we build ONE API that every single app talks to (internal and external)?

If we do that, what is this API talking to? Should it talk to the database directly or talk to internal web services that talk to the database directly?

Or in other words...

Design 1 = apps > API > web services > database

Design 2 = apps > API > database

The next question is that my boss wants an API for each app which is puzzling me a little and we have been arguing it back and forth...

Does it make sense to have

app 1 > API for app 1 > web services > database

mobile app 1 > API for mobile app 1 > web services > database

Personally, I am leaning towards:

app 1 > API > database

app 2 > API > database etc...

What are your thoughts?

Upvotes: 0

Views: 156

Answers (1)

Praveen Prajapati
Praveen Prajapati

Reputation: 989

As per given scenario apps > API > web services > database is better because...

In "app 1 > API > database" approach APIs would be having business logic which would duplicate in each API....obviously it is not so good to put business logic in app itself or in DB.

In "apps > API > web services > database" we can put a lot of common business logic and other infrastructure related stuff under shared web services which can be used by all APIs.

Since web services can be consumed by heterogeneous web or windows applications...it is always good to put shared functionality in such a way.

Upvotes: 1

Related Questions