What type of implementation will be more suitable in service layer?

Question

I am developing a new microservice application that will be part of big architecture with lots of other microservices. This application needs to get content from other applications and I want to encapsulate HTTP calls into the service layer. But I noticed there are two different approaches.

---

Let's assume that my application will get contact information from another microservice which is deployed as User API.

1. Business as file

This approach has the business name as the file name. Inside the file, there is only one public method which is get and it receives a single parameter. The method calls user-api/contact/{id}.

Filename: contact.service.js

Method: get(id) -> contact

2. API as file

This approach encapsulates all communication between User API and the consumer application into a single file. There is a method for every endpoint provided for User API.

Filename: user.service.js

Method: getContact(id) -> contact

---

What are the pros and cons using these approaches?

Answer 1

This question is more of an opinion question really, different companies / different software developers might give you different answers.

My take on this is, I think splitting them into their individual files - down to even the methods if the logic is complex - helps a lot with maintainability / testing.

• Testing: If you use the same splitted pattern across the test files - which I mimic our code in terms of structure and do, I've found it helps people locate code easier, execute the tests exactly the way they wanted to execute them. Something like test contact.service.test.js where the change is isolated and they can run the related tests immediately pretty easily.
• Maintainability: I try to keep stuff as small as possible in the last service layer. This is not to say that everything is abstracted and layer after layer you can't find the real code / but even then I'd have services splitted down to their methods in different files with super convenient names. Documentation is insanely easy this way, you can just write all that's needed in the same file.
• Code reviews: Becomes a lot easier, it forces the change to be small in each file, because you have files with much less content.

Ask these questions to yourself;

• Do your services have very complex logic in them which will extend the file into thousands of lines - making it harder to document / harder to spot the mistakes / harder to refactor? Or are they smaller endpoints which the logic is offloaded to some other part of the system?

• Are the tests for these methods / services going to exist in (another) single file - mimicing the pattern in the service implementation? Will you be able to call an individual test while testing a feature?

• Are you prepared to accommodate the decision that you made across all of your services? Your particular service(s) therefore that exact file might be relatively small, what about a service which one of your colleagues might write and turn into a giant 1K line file?