Microservices and GraphQL — a topic I’m excited about. I’ve been building distributed systems and REST is falling short for what I need on the mobile side. GraphQL is gaining traction and I wanted to share what I’ve learned.
Here are the concepts I covered. If you prefer to see the slides directly, here they are.
Divide and Conquer
The core principle behind microservices is simple: divide and conquer. Instead of building a monolithic application that does everything, we break the system into smaller, focused services. Each microservice does one thing and does it well — a philosophy I inherited from the Unix tradition and that has served me well for scalable, maintainable architectures.
What Is a Microservice?
To me, a microservice is a self-contained unit of functionality that meets several characteristics I value:
- Does one thing well — focused on a single business capability
- Is autonomous — identified by a unique URL, operates independently
- Is isolated — I can modify, test, and deploy it without impacting other parts of the solution
- Is elastic — can be scaled independently (vertically or horizontally)
- Is resilient — fault tolerant and highly available
- Is responsive — responds to requests in a reasonable amount of time
- Is message oriented — relies on asynchronous message-passing to establish boundaries between components
- Is programmable — exposes APIs; applications are composed from multiple microservices
- Is automated — its lifecycle (dev, build, test, staging, production) is managed through automation
Are They the Silver Bullet? No.
Whenever I talk about microservices, someone asks if they’re the solution for everything. No. They’re a powerful pattern, but they come with trade-offs. I showed this table in the talk:
| Pros | Cons |
|---|---|
| Scalable | Network latency increases with message interchange |
| Reduce deployment costs | Deployment and testing complexity grows with the number of service interactions |
| Can be developed by a small team | Too fine-grained services may create more overhead than utility |
| Team only needs to know the service’s business logic | Message formats, restrictions, and interaction knowledge are required |
| Continuous deployment | Versioning is critical due to interactions with older service versions |
| Use the technology you prefer | Transactional operations across many services increase logic complexity |
GraphQL: Why It Won Me Over
GraphQL was created by Facebook in 2012, driven by the mobile team. It’s a query language for communication between clients and servers — a complete alternative to REST. (Note: it’s not like SQL; it’s a typed API language, not a database query language.)
What I liked most from the start: the client defines what it receives. No more over-fetching or multiple requests per view.
REST vs GraphQL
| REST | GraphQL |
|---|---|
| It’s a convention | It’s a typed language |
| Server exposes resources | Client defines what it receives |
| Often sends more data than needed | Only necessary data is sent |
| Multiple requests per view | One request per view |
| Documentation separate from development | Documented by definition |
| Multiple endpoints | Single endpoint: /graphql |
Core Concepts
- Schema — Defines the structure of your API
- Types — Strong typing for queries and responses
- Queries — Read operations
- Mutations — Write operations
- Resolvers — Functions that resolve each field in the schema
If you want to play with a real example, the Star Wars API (SWAPI) is great to explore.
Resources I Use
GraphQL
- GraphQL Specification
- GraphQL.js
- GraphQL SWAPI
- GraphQL Documentation — Apollo Launchpad has been shut down
- Graphene (Python)
- Apollo Client
- Awesome GraphQL
Microservices & Docker
- Divide and Conquer – The Microservice Approach
- Docker Load Balancer Demo — a project of mine I used in the demo
- Docker
- Docker Compose
Recommended Talk
- Por qué API REST está muerto y debemos usar APIs GraphQL — José María Rodríguez Hurtado (Spanish)
Let’s keep building.