February 2, 2023
TLDR: Server and Client Example https://github.com/danielm/graphql-example
It a way for a client to talk to a server in a shared language, usually defined via an schema, to query that server for data, or mutate that data remotely.
The core promise is that schema => or we can call it a contract. Here, Backend and frontend teams should agree on that schema, figure out needs and define what the needs of the application are.
As you can see is a layer, or more like a "wall" between the server and the client (backend/frontend); where it doesn't matter what tech stack is your backend or client are using, they are completely independent; all they share is what they want from each other: the schema (a contract)
This is what the client and the server must 'agree' on, it has a very simple syntax... very easy to understand just by reading it.
Internally GraphQL has many built in types and we (of course) can define many more.
So lets pretend we want to develop just another ToDo list:
type Task { // Our type
id: ID!
content: String!
completed: Boolean = false
}
type Query {
tasks: [Task] // a) Give me all Tasks, (an array of Task)
task(id: ID!): Task! // b) Give me one single Taks (by Id) '!' bang means required
}
// a type of payload to recieve when updating a task, note both are optional
input TaskPayload {
content: String,
copmleted: Boolean,
}
// c) and our mutation
type mutation {
update_task(id: ID!, payload: TaskPayload!): Task
}
Here our back-end team will have to implement 3 "resolvers":
It is great when you want a tight integration between both sides of the APIs, but don't want to both implementations mixed.
Many clients like Apollo implement stuff like caching, subscribe to changes, etc. It becomes some sort of state manager, and with the use of useQuery() for TS/JS makes the usage from the back-end extremely easy.
I'm a 32-years old programmer and web developer currently living in Montevideo, Uruguay. I been programming since I was about 15 y.o, and for the past 12 actively working in the area.