I think that there is a world between REST and GraphQL.
For front-end application, there is a need to create something specific for the jobs (presenters). Most of us are not developing a Facebook that has the complexity of displaying lots of variable data.
In most application that I have worked on, we always ended up writing services (note that I'm not using the word REST) that were used to present data for specific parts of the application. Mutation were also tailored to the specific need.
The architecture was usually FE -> Presenters -> Business
Presenters are specific to the view (whether that is web, mobile, or mobile app).
This does not suite all but when the team is taught for defining the contract and making them evolve according to the need.
I don't think microservices, which is the nearest you could come to REST, have ever been suitable for frontend consumption especially for the reason
I think that there is a world between REST and GraphQL.
For front-end application, there is a need to create something specific for the jobs (presenters). Most of us are not developing a Facebook that has the complexity of displaying lots of variable data.
In most application that I have worked on, we always ended up writing services (note that I'm not using the word REST) that were used to present data for specific parts of the application. Mutation were also tailored to the specific need.
The architecture was usually FE -> Presenters -> Business
Presenters are specific to the view (whether that is web, mobile, or mobile app).
This does not suite all but when the team is taught for defining the contract and making them evolve according to the need.
I don't think microservices, which is the nearest you could come to REST, have ever been suitable for frontend consumption especially for the reason
Unleash the trolls :-)
🤔 REST is not microservices, or nearest... Microservices is much more 🙌