GraphQL in a microservices environment

GraphQL in a microservices environment — module 4AGQL, Supinfo.
Three days to go from the limits of REST in a microservices architecture to a GraphQL-native fullstack application: a first Apollo server, a complete backend with mutations, a React frontend, then an assessed project in pairs.
| Format | 3 days · lectures, progressive exercises and a fullstack project in pairs |
| Level | Master’s year 1 — Grande École programme |
| Class | Tours, PGE 2025-2026 |
| Tools | Node.js, Apollo Server 4, Apollo Sandbox, Apollo Client, React |
Day 1 — Introduction to GraphQL and first backend steps
The module opens with a guided discussion on the limits of REST in a microservices context: over-fetching, inconsistent naming across services, a growing number of endpoints, the impact on network performance. GraphQL is introduced from these frustrations, voiced by the students themselves, as a structured answer to these problems.
A theoretical overview: its origins at Facebook in 2012, open source since 2015, governance by the GraphQL Foundation. Then the core concepts — schema, types, resolvers, queries, mutations —, an honest look at its pros and cons, and the ecosystem (Apollo, Offix, Graphback).
In practice: a first GraphQL server in Node.js with Apollo Server 4 in standalone mode, a schema written in SDL, the first resolvers, exploring Apollo Sandbox, and exercises on simple queries.
Day 2 — Advanced backend: types, arguments, mutations
Going deeper into the backend: scalar and custom types, named arguments, default values, relationships between types, while building a small user API with in-memory data.
Mutations, and how their execution differs from queries: queries run in parallel, mutations in series. Subscriptions for real time over WebSocket. A series of progressive exercises covers the full CRUD cycle, followed by a look at REST and GraphQL living side by side in the same project.
On the frontend: integrating Apollo Client into a React application, first components consuming the API, handling loading and error states.
Day 3 — Fullstack project: SchooInc
A day dedicated to the assessed project, done in pairs: a GraphQL-native school management application, with an API split into several microservices and a frontend in React, Vue or Angular.
- Users: full CRUD, student and teacher roles.
- Authentication: stateless, with JWT.
- Grades: role-based access control.
- Classes: aggregate calculations — median, minimum, maximum.
- Professional requirements: tests on core features, code security, documentation and an installation README.
Assessment
The project is assessed through a graded oral presentation, covering the technical choices, the quality of the code and the students’ ability to defend their architecture.