TL;DR
In this episode of The Good Thing, Stefan and Jens examine Apollo’s original GraphQL Federation principles, where new features like connectors contradict them. They explain the role of demand-driven schemas in keeping APIs flexible, critique claims about a developer job crisis, and debate how AI coding tools are raising the bar for engineers instead of replacing them.
Apollo Federation Principles and Connectors
Early in the episode, Stefan and Jens revisit Apollo’s “Principled GraphQL.” Jens highlights that while the document promoted a unified graph and abstract schemas, Apollo’s newer connectors put implementation details directly into the schema.
We should not mix the schema with implementation details. With connectors, that’s exactly what happens.
They argue this shift undercuts the original manifesto and complicates schema design for frontend developers.
Demand-Driven Schemas
Jens explains that GraphQL’s strength lies in demand-driven schemas, where the contract reflects what consumers need rather than backend structures. By mixing REST-specific directives into the schema, connectors risk turning the graph into a thin wrapper over existing APIs.
Wasn’t the whole point of GraphQL that we follow what the frontend needs, not what the backend has?
The hosts contrast this with Cosmo’s approach, which compiles subgraph schemas into gRPC plugins, leaving no special directives in the schema tied to backend details.
How Connectors Reintroduce the N+1 Problem in GraphQL
Looking deeper, Jens points out how connectors reintroduce the N+1 problem. By mapping entities directly to REST endpoints without batching, each query can trigger hundreds of calls.
If we fetch this entity 100 times, we’ll make 100 REST API calls. There’s no batching, no data loader.
They compare this to plugin-based federation, where batching is handled through the generated RPC in the router’s plugin.
AI Overreach and Creativity
The conversation shifts when Stefan recalls a friend who used AI to summarize a 50-page article instead of reading it. He sees this as proof of people outsourcing thinking to machines.
You’re missing the whole point. The article was about not letting AI dull your creative edge.
Jens adds that large language models generate code well but lack reasoning. Without solid architecture skills, developers risk being replaced by tools that only automate low-level work.
Learn to Code, AI, and the Developer Job Crisis
The hosts critique a Futurism article claiming computer science graduates face high unemployment and that “learn to code” has backfired. Stefan cites statistics in the piece about unemployment rising to around 9 percent for recent graduates. Jens dismisses the narrative, arguing that AI isn’t eliminating jobs but pushing expectations higher.
AI is raising the bar. If you’re a good developer, nothing has really changed.
They trace recent layoffs back to the over-hiring boom during zero interest rate years, not to AI itself.
Closing Thoughts
The episode closes with Stefan and Jens reflecting on software engineering’s complexity. Tools like Cursor and LLMs can automate simple tasks, but real value still comes from collaboration, architecture, and delivering features across teams.
Software engineering is more about solution design than writing lines of code.
This episode was directed by Jacob Javor. Transcript lightly edited for clarity and flow.
