-1

I was going through an old, largely untouched part in my company’s codebase and found one API. It does the following things.

A POST API with path host/entities/trigger which fetches a list of entity IDs from the database. For each of these entity IDs, it’s making another POST call to the below API in the same service (host/entities/{entityId}/process) which does sole operations based on the entity ID.

My doubt is, what is the point of having it like this? Because, we can simply have the first API, and instead of making the second API call to the same service, we can just call the process() function. Are there any disadvantages of doing it like this? Or, are there any advantages doing it in mentioned format above?

Improve this question
2
  • given an old, largely untouched part in my company’s codebase then we can just call the process() function. might not be that simple. It will depend on the dependency graph, abstractions, complexity (aka spaghetti code), etc. Commented Feb 28, 2023 at 15:47
  • Code which has been untouched for years may just have been working really well for years -- seems ideal to me; code which lasts so long without needing to change is often a sign that the original developer did a good job at understanding the requirements and making something work (measured by the fact that nobody has needed to invest more time/money changing it). What's the actual issue you're trying to solve here? can you explain the problem/disadvantage that you've found doing with things this way or why it might need to change? Commented Feb 28, 2023 at 15:55

1 Answer 1

Reset to default
1

There may be valid reasoning behind it and it can both be due to future proofing or actually legacy code.

Option 1. Future proofing:

At one point the developer working on the microservice intended to split the trigger and process functionality into two sepparate services. As such, he coded it in a generic way that would account for that future refactor by having the code already POST to the process entity as if it was a separate service, which also works with having the endpoint in the current service.

Option 2. Legacy code:

The microservice did NOT initially contain the code to satisfy the host/entities/{entityId}/process endpoint, instead it was (at the time) calling another service that was performing that function.

At some point in the past it was refactored and the "process" API endpoint was merged with the microservice but the trigger call was never refactor to directly call the internal method.

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.