| > Am I alone in thinking this is a ridiculous solution to replace traditional REST endpoints? Consider implementing GraphQL over a REST-like API if you tick at least one box of: - Your API has multiple consumers, not just one front-end. - Your backend has a multiple, possibly heterogeneous providers, for example a set of different APIs. - You need to decrease the frontend and backend coordination. - You want to offload complexity or expressivity to the consumer. --- An example of when not to use it IMO: We ruled out GraphQL in a current/new project very early on, even though good libraries, tooling and knowledge was all there. - The coordination is very high and unbureaucratic (small team of full-stack developers). - single backend, single frontend - We are very comfortable with SQL and don't need something to patch over an ORM or other scaffolding. - We are iterating over a specification => the functionality is clear => we can choose where complexity resides. => we decided to keep the frontend simple and optimize on the backend. |