GraphQL Is Dead

To be honest, GraphQL has never been my thing. I've never enjoyed writing it or consuming it on the client. For me, the tradeoff has never seemed worth it. So you can imagine how amused I was when a post titled "Why, after six years, I'm over GraphQL" landed on Hacker News. Before my comments spark a flame war, let me say that GraphQL has its place, and there are parts I enjoy. I hope you find this slightly GraphQL-themed issue interesting, and feel free to overlook my cynicism.

-- Alexander

Alfred AI: The Ultimate API Assistant

Alfred AI is a cutting-edge, AI-powered assistant designed to revolutionize API documentation, discoverability, and integration. Alfred automates manual workflows, for faster API integrations and a superior developer experience.

Discover Alfred

The API Round-Up

Our monthly round-up of articles, news and updates from APIs You Won't Hate and around the web.

Why, After Six Years, I'm Over GraphQL

This article kicked off my week of giggles. Matt Bessey talks us through his frustrations with GraphQL, including attack service, authorisation, rate limiting, coupling, performance, and more. I can't entirely agree with all the negatives, but this article provides insight into some of the tradeoffs when using GraphQL.

Why, After Eight Years, I Still Like GraphQL Sometimes in the Right Context

This is a solid reply to the first post, putting some of the complaints under scrutiny. Marc-Andre Giroux argues that Graph works best when you persist queries and are building an internal API with multiple clients.

Happy Compromise Between Customization and Cacheability

One of the main issues I have always had with GraphQL is that people seem to think moving API design to the client makes things easier. The truth is that very customizable APIs are almost impossible to optimize. Most of the time, APIs don't need to be as customizable as they are, and you don't need to force strong coupling between an API and front-end design. To help build on this, Phil talks us through making an API customizable but still cacheable.

Enable API Caching

Another mistake people make is mixing catchable and uncacheable data. Fastly walks you through splitting up data, for example, not mixing invoice and payment details. Clients only fetch what they need by creating different endpoints with different capabilities and caching. With good API design, you might not need GraphQL as much.

Make your APIs Discoverable with APIs.json

Phil is back writing another article for Bump. Phil explains how to enhance API discoverability using the APIs.json specification. The specification involves creating a well-known URL (/apis.json or /apis.yaml) containing metadata about the API, which helps various tools and marketplaces locate and interact with your APIs.

Scalar OpenAPI Parser

A new OpenAPI parser from the Scalar team. It aims to be a Swagger and JSON Schema reference resolver. Phil is excited about this one, as it may replace many defunct tools.

APIs You Won't Hate

The latest from the team at API's You Won't Hate.

🎙️ Designing the API for building Voice Assistants, with Nikhil Gupta from Vapi

Mike sat down for an interview with Nikhil Gupta, founder of Vapi, to talk about designing and building a product around Voice AI for developers. They chat about the right type of onboarding for voice assistants, building tools that API developers can test easily, and the future of Voice Assistants.

From Our Community

Articles written and shared in our free Slack community.

7 Deadly Sins of API Security Testing

Dana is back with another killer article, this time on API Security. Dana highlights pitfalls such as poor timing, lack of API inventory, inadequate surveillance, chaotic planning, over-ambition, blame culture, and over-reliance on tools. He stresses early, varied testing, detailed API knowledge, structured planning, iterative testing, collaboration, and thoughtful tool use. Dana also linked his talk if videos are more your thing.

Thanks so much to our members Kin L, Juxt, Vedran C, Alex R, Nolan S, Frank, James D, and Bill D. Your support means the world to us!

Until next time,

Alexander, Phil & Mike