stateless servers & structured access to resources ➤ REST is a strict specification - but the concept was wildly interpreted ➤ Rapidly changing requirements on client-side don’t go well with the static nature of REST
need for efficient data loading ➤ Variety of different frontend frameworks and platforms on the client-side ➤ Fast development speed & expectation for rapid feature development
of them need to talk with each other. The client needs to tell the server what data it needs, and the server needs to fulfil this client’s data requirement with actual data. GraphQL steps into the middle of this communication. -Samer Buna
data needs ➤ Client speaks a query language not a coordination of HTTP calls. Tell don’t ask principle ➤ No need to adjust API when product requirements and design change ➤ Faster feedback cycles and product iterations
by clients ➤ Enable evolving API and deprecating unneeded API features ➤ Great opportunities for instrumenting and performance monitoring. ➤ ps: Resolver function to collect data do de shown, instrumentar os resolver provides crucial about bottleneck
system to define capabilities of an API ➤ Built-in API documentation ➤ Easy to create contract test, Schema server as contract between client and server ➤ Frontend and backend can work completely independent from each other