There are two external APIs that I have to consume in my app, parse the data and serve it to front-end. The APIs have different response and request objects and one handles XML and the other one handles JSON and front-end has the possibility to see the data coming from both external APIs.
My question is what would be the best approach to do build this app? How should I structure the code, bearing in mind that another APIs could be added in the future, so I would like to make it modular as possible, but I'm not sure how to achieve this.
Should I go for microservices architecture, where I have the main app and it communicates through Feign, where API1 is one service with the models and services etc and API2 is the other microservice and front end is hitting those microservices separately? Or should I have one monolith where I have both API1 and API2 service layers, controllers, models etc and front end is hitting the monolith where the business logic determines which API service/model/controller to use?
So something like this..
**
API1 Microservice/**
API1 model
API1 service
..
**
API2 Microservice/**
API2 model
API2 service
..
**Monolith**:
Services/ (Feign implementations, other business logic etc)
API1 service
API2 service
Model/
API1request
API1response
API2request
API2response
Controller/
API1controller
API2 controller
I'm able to actually build the app and write the code but would love some input as to how I should organise the actual app and possible make it as modular as possible.
Thanks.
CodePudding user response:
One approach you could take is to use a microservices architecture, where each API is its own microservice. This would allow you to develop and deploy each API independently, and make it easier to add new APIs in the future.
In this architecture, your main app would communicate with the API microservices using a client library like Feign. Each microservice would have its own models, services, and controllers for handling requests and responses.
Alternatively, you could use a monolithic architecture, where all of the API logic is contained within a single application. In this case, you would have one set of services, models, and controllers that handle requests and responses for both APIs. The business logic would determine which API to use based on the request received.
Both of these approaches have their own pros and cons, and the best option for your application will depend on your specific requirements and goals. It's always a good idea to carefully consider your options and choose the architecture that will best support the needs of your app and your team.