[RECAP] Apollo Community Meetup - Your New Favorite Rubber Duck: Using AI to Reflect, Review, and Refactor Your APIs

Events and User Groups Community Calendar
, , , ,
1

:apollo_logo_orange: :busts_in_silhouette: [RECAP] Apollo Community Meetup - Your New Favorite Rubber Duck: Using AI to Reflect, Review, and Refactor Your APIs

:date: Meetup Date: Wednesday, May 28, 2025
:studio_microphone: Featured Speakers:

THIS WEEK’S TOPIC

Every developer knows the power of talking through a problem with a rubber duck—explaining your thinking out loud often reveals gaps and sparks insights. Today, AI is becoming the ultimate rubber duck. In this meetup, we’ll explore how LLMs are quietly transforming the way we design, review, and operate APIs and graphs.

The meeting focused on AI , MCP and LLM tools, discussing their applications in development, schema optimization, and code reviews. Participants explored the potential of LLMs for various tasks, including schema design, API integration, and automated code generation. The group also discussed upcoming events, community resources, and ways to share prompts and best practices for AI usage within the GraphQL community.

View Full Transcript

:pushpin: MEETING RESOURCES

:link: Here are some resources that were shared during the talk:

2
3

Thanks for having me on, really interesting conversation!

I’ll leave you with bob’s recommendations;

Alright, Dave. Let’s have a look at this stock schema.

First off, where’s the @contact directive? You’ve linked to the Federation spec, which is a start, but without a @contact directive on your schema, nobody knows who to bother when this thing inevitably breaks. It’s basic hygiene. Define it, import it, and apply it to your schema extension. Otherwise, you’re just publishing anonymous spaghetti.

Now, about this Product type. You’ve defined it, but you haven’t given it a @key. How do you expect the router to identify a Product across subgraphs if you don’t tell it what makes a Product unique? Is id the key? If so, mark it. If not, figure out what is.

The StockInfo type looks like a simple value object, which is fine. No complaints there.

Your Query extensions are straightforward enough. stockInfo and lowStockProducts are clear.

However, there’s a distinct lack of descriptions. For a schema that’s supposed to be a platform, it’s remarkably uncommunicative. Every field, every type, needs a description. Don’t make people guess what nextDelivery means or what threshold is for.

So, to summarize: add the @contact directive, define your Product entity with a @key, and for the love of all that is composable, add some descriptions. You’ll sleep better, and so will I.

Here’s bob if your interested bob-your-federation-assistant.md · GitHub