0

I am planning to make a service which will have simple REST APIs and will have a database in backend. I also wanted to add a logic to listen to notifications emitted by other service and there is some business logic which will update the row in the database.

For updating the database row from Notifications, I can think of 2 approaches:

  1. Should I create a API which is kind of internal to just used by service and this listener process calls this API instead of directly updating the database?

  2. Listener process directly updates the service.

I can see some pros and cons of each approach. In Approach 1, we are adding a REST API unnecessarily which is never used by clients.

In Approach 2, we are giving one backside way to reach the database instead of all the requests coming from REST API.

Can someone help me here to tell if one of them is anti-pattern and which one is better to use?

Improve this question
2
  • The service you are talking about, will it be placed on the server or on the clients? The clients should never be able to access the database directly. So if it is placed on the client, create a new rest API which it calls. But I don't think that it is very clear exactly what you are asking Commented May 27, 2020 at 5:47
  • With option 1 this API endpoint can be used by other API users. This may or may not be acceptable. Commented May 27, 2020 at 8:44

1 Answer 1

Reset to default
1

Layers

As best I can deduce your question can be restated as:

Why should I go through the Business Layer of a Service, when I can just insert the data directly into its database?

Lets contrast these two approaches.

The Two Approaches

If I go through the public interface to update the data.

Cons:

  • Its slower, the database is updated, but there is all these extra layers of code, data transformation, validation, and technologies.
  • There are more components the could go down, such as the web service.
  • A REST API resists the use case of streaming events.

Pros:

  • One set of Business rules applied to all incoming data.
  • Decouples the event source from the backend details.
  • Allows seperate teams to maintain the event source separately from web service.

If I go directly to the database.

Cons:

  • Any change to the database structure/engine has to consider compatibility with two separate code bases
  • The Web Service has to be aware that the database is changing behind its back (essentially the database becomes a third codebase/service of its own distinct from the rest api, and the event source).
  • Validation and business logic must be rewritten/shared between projects.

Pros:

  • Fast.
  • The validation/business logic can be stream lined on a per project basis. The Event Source and the REST API need only know the pieces relevant to their circumstance.

A very short list of pros and cons, spend some time thinking up more...

Engineering

Is picking between the two solutions.

Look at the trade off and figure out what works:

  • Today - because you have to write it now, and have it work now, with what you have now.
  • Next Week - because something will go sproing and will need to be fixed.
  • Next Year - because what is needed changes overtime, and as such the solution will need to be revisited and updated.
  • When You Die/Leave - Because you are not immortal, and will probably move onto something else sooner or later. At which point someone else has to be able to pick this up and work with it. Add those hand holds now.

Personally if nothing else is interacting with this API, why not implement it as a Library instead. Later, you can revisit the API question.

When you do revisit it, the library can be easily wrapped by some form of networked API, and the library interface can be stubbed with a proxy implementation to use the Networked API.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.