<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>GraphQL on</title><link>/tags/graphql/</link><description>Recent content in GraphQL on</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 07 Dec 2024 00:00:00 +0000</lastBuildDate><atom:link href="/tags/graphql/index.xml" rel="self" type="application/rss+xml"/><item><title>Lesson 3: GraphQL in Go — gqlgen, resolvers, and DataLoader for N+1</title><link>/post/fundamentals/graphql-go/</link><pubDate>Sat, 07 Dec 2024 00:00:00 +0000</pubDate><guid>/post/fundamentals/graphql-go/</guid><description>&lt;p&gt;Go is not the most common language for GraphQL tutorials. Most of the ecosystem documentation assumes you&amp;rsquo;re working in JavaScript or TypeScript, and a lot of the tooling is designed around Node&amp;rsquo;s event loop model. But Go is an excellent choice for a GraphQL server — statically typed, fast, and with gqlgen you get one of the cleanest schema-first GraphQL implementations I&amp;rsquo;ve used in any language.&lt;/p&gt;
&lt;p&gt;This lesson is about making it work in production: generating a working server from a schema, implementing resolvers correctly, and fixing the N+1 problem with DataLoader before it shows up in your latency graphs.&lt;/p&gt;</description></item><item><title>Lesson 2: Schema Design — Types, queries, mutations, and subscriptions</title><link>/post/fundamentals/graphql-schema/</link><pubDate>Sun, 08 Sep 2024 00:00:00 +0000</pubDate><guid>/post/fundamentals/graphql-schema/</guid><description>&lt;p&gt;The schema is the most important artifact in any GraphQL API. It is simultaneously the contract between your client and server, the documentation for every engineer who works with the API, and the boundary that forces you to think clearly about your domain before writing any implementation code. A well-designed schema makes everything easier. A poorly designed schema compounds every mistake downstream.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;ve seen both. The experience of inheriting a badly designed GraphQL schema — full of inconsistent naming, misused types, nullable fields everywhere because someone wasn&amp;rsquo;t sure — is one of the more persistent forms of technical debt I&amp;rsquo;ve encountered. Unlike a poorly written function, a bad schema is public-facing. You can&amp;rsquo;t just refactor it; you have to version and deprecate carefully.&lt;/p&gt;</description></item><item><title>Lesson 1: GraphQL vs REST — When GraphQL wins and when it doesn't</title><link>/post/fundamentals/graphql-vs-rest/</link><pubDate>Thu, 06 Jun 2024 00:00:00 +0000</pubDate><guid>/post/fundamentals/graphql-vs-rest/</guid><description>&lt;p&gt;I spent about six months being wrong about GraphQL. My first exposure to it was a rewrite pitch from a frontend engineer who was tired of making five REST calls to assemble one screen. &amp;ldquo;GraphQL solves this,&amp;rdquo; they said, and the demo looked compelling. A single query, exactly the fields you need, one round trip. I was sold before thinking carefully about what we were buying.&lt;/p&gt;
&lt;p&gt;The rewrite happened. It took eight months instead of four. Some of the problems we were trying to solve got better. Others got worse. Looking back, the mistake wasn&amp;rsquo;t choosing GraphQL — it was not being rigorous about where GraphQL actually wins and where it doesn&amp;rsquo;t before committing.&lt;/p&gt;</description></item></channel></rss>