CODEWITHSUNDEEP
databaseapirest
CodeNinja
CodeNinja

Reputation: 847

is it neat to have 2 applications which query 1 database

First of all i will apologize for my bad English....

I'am working on a kind API which provides data from an local database. The data in the database is managed by another application (called CMS). The API need to be operate without using the CMS (costumer wish).

There are 2 ways to manage the data in the database of the API.

The first way is that the CMS calls an rest API from the "API backend" which updates the API database. The same "API backend" is providing the data from the database over an rest API to the API gateway which makes the whole thing scalable and manages API keys and so on.

enter image description here

In the second way the CMS is manage the data directly in the API database and the "API backend" provides the data from the database over an rest connection to the API gateway which......"same story"

In this situation the "API backend" only read data from the database so it is imposible that 2 applications try to write on the same record.

enter image description here

Now my question: Is one or both of these methods the right (usual) way to solve my "problem"? I go for the first solution, one of my colleagues for the second one.

I say it is not neat to query an database from another application. He say in the second situation you need to program 1 API less (the one which communicates with the CMS) so it saves time.

Time isn't the problem in our situation but when it is neat to do it on a way which need less time than we will do that.

Upvotes: 3

Views: 541

Answers (2)

dagnelies
dagnelies

Reputation: 5319

actually, both cases are pretty close to each other. It boils down whether you write directly to the database or through another layer. The rest is identical.

So, IMHO, I'd follow the KISS principle and pick the solution which is the most straightforward. ...it's not necessarily the one or the other. It's likely to depend on your technology stack and current code.

Besides of this, the two key differences between both alternatives are...

For direct DB access

  • It's quick and highly customizable. You can optimize your queries easely. Quite handy for large data.

For access through REST API

  • Here, you have another pass through serialization/network/deserialization. It's very likely a negligible overhead, but it's worth mentioning if you bombard it with requests.
  • If you have to change what data is written or how, you might have to tweak two places: the CMS and the Backend API
  • Going through the Backend API offers an easy way to apply generic stuff (logging, statistics, validation, monitoring...) ...in case you need it. Otherwise, forget it, YAGNI
  • ...it may be useful in case other services need this REST API too ...otherwise, YAGNI

Basicaly, I'd go for whatever way seems simpler in your case.

It's not a big fuss anyway. You can abstract it behind an interface so that you can swap whether it goes through a REST API or to the DB at any time. It'd just be a matter of porting a bit of code from the DB access layer to the Backend API, or vice-versa, provided it's the same language.

Upvotes: 1

Neville Kuyt
Neville Kuyt

Reputation: 29629

The architecture you describe is typically known as "content as a service" or "headless CMS". It's becoming a popular design - it allows you to use your content in web sites, mobile apps, kiosks etc., and - theoretically - decouples your website from the CMS vendor.

When you say "CMS", I assume you're building this yourself, rather than use an off-the-shelf solution. If that's the case, I'd consider looking at off-the-shelf first; it will almost certainly be cheaper, quicker and better than anything you can write yourself.

However, if you are building this yourself, your question comes down to "service oriented" versus "data oriented" design. In general, it's risky to combine those two patterns - it makes the application more complex, and therefore more bug-prone. For small applications, that's probably not a big deal, but for large, long-lived or business-critical applications, that's a bad thing.

It may help to think through a basic task of the CMS - edit an existing article.

In a service-oriented design, the CMS code would be something like:

article = articleService.get(id)
application.render(article)
onSave(article)
  articleService.put(article)

in a mixed design, it might look something like....

article = articleService.get(id)
application.render(article)
onSave(article)
  db.updateArticleHeader(date, user, article.metaData.title, article.metaData.byLine)
 forEach(article.Header.keywords)
   if not (db.getArticleKeywords.contains (keyword))
     db.addArticleKeyword(keyword)
 next
 db.updateArticleBody(article.body)

(and that, of course, leaves out all the database logic). There's more code in the CMS application, and more logic.

Now imagine what happens when you add another attribute to the article - you have to update the DB layer, the rendering layer, and the business logic layer in the CMS.

If you have a service-oriented approach, with a little bit of luck, you just have to change the service layer.

"Neat" isn't usually a useful way to evaluate software. It's better to use established non-functional requirements:

  • performance: mixed model is probably faster, as it removes the API layer.
  • development time: mixed model may be faster for simple solutions; for complex applications, it's probably quicker to build the API layer and centralize logic.
  • maintainability and extensibility: service-oriented approach is usually (much) better for anything but trivial applications

Upvotes: 1

Related Questions