Closed SanderDeclerck closed 3 years ago
I think, as we probably will start with a single web-based frontend, a single gateway is well enough to start. This could be refactored later on into multiple gateways when there's a need for that.
In the first phase, this gateway should probably return some static data, so that the front-end can be developed. Interaction with the services can then be added as features get implemented.
The gateway will act as the main access point for the different clients. It will aggregate data from multiple microservices, and send them to the front-end.
There are a few possible strategies:
Bff (backend-for-frontend)
In this scenario, each of the client applications will get its own gateway. This allows for a tailored gateway for each app. Only sending the data needed for each request/screen.
Single gateway for all apps
This is the other end of the spectrum, defining one gateway for all applications. In this scenario, the gateway would need to be more generic and might send data the client does not need.
Hybrid scenario
In this case, all clients looking similar, will get a gateway. Eg: when you would have both a dedicated Android and iOS app, this would result in one gateway for mobile apps, rather than both having their own gateway.