GraphQL is a query language and runtime. The client sends a query (or mutation) that describes exactly what data it wants; the server has a schema (types and fields) and a resolver for each field. The client gets back only the fields it asked for—no over-fetching or under-fetching. Example: `query { user(id: 1) { name, email } }` returns only `name` and `email`, not the whole user object.

vs REST: In REST you have one URL per resource (e.g. GET /users/1 returns a fixed shape). To get users and their orders you might do two requests or a custom endpoint. In GraphQL you send one query: `{ users { id, name, orders { id, total } } }` and the server resolves nested data in one response. The trade-off: GraphQL is more flexible for the client but requires a schema and resolvers on the server; REST is simpler and widely understood.

Mutations are for changes (create, update, delete). The client sends a mutation with variables; the server performs the change and returns specified fields. Same idea as POST/PATCH/DELETE in REST but with a typed, declarative syntax.

Subscriptions are for real-time updates. The client subscribes to an event (e.g. "new message in room X"); the server pushes data over a persistent connection (usually WebSocket). When something happens on the server, it sends an event to all subscribed clients. So GraphQL can cover read (query), write (mutation), and live (subscription) in one API style.

Use GraphQL when: you have many clients (web, mobile) with different data needs; you want to avoid over-fetching and multiple round trips; you want a single schema and strong typing for the API. Use REST when: your API is simple and resource-oriented; your team is small and REST is enough; you want maximum simplicity and tooling (caching, CDNs) that assume REST.

Real-time: GraphQL subscriptions need a transport (WebSocket). If you only need real-time in a few places, you can keep REST and add Server-Sent Events or WebSockets just for those features instead of adopting full GraphQL.

Schema: Design types and fields so clients can ask for what they need in one query; avoid deeply nested or circular structures that make resolvers expensive. N+1 problem: If a query asks for `users { orders { items } }`, a naive resolver might run one query per user and per order, causing many DB round trips. Use DataLoader-style batching or join-heavy queries so one resolver call can fetch many related rows. Monitoring and query analysis help you spot N+1 before it hits production.