Forem: Apollo GraphQL

Meet the Builders: Highlights from the MCP Server Builder Meetup

Amanda — Tue, 08 Jul 2025 16:33:39 +0000

On June 18th, we hosted our very first MCP Server Builder Meetup in San Francisco, bringing together engineers, tinkerers, and early adopters to explore the future of building AI-native developer experiences with Model Context Protocol (MCP).

This was more than just a showcase of cool demos. It marked the launch of a new community of developers building for and with LLMs using MCP servers. The energy in the room made one thing clear: this community is ready to build what's next.

Keep reading for a recap of all the demos with links to the full sessions. Our next events in the series are on July 29th in NYC and July 31st in San Francisco. We hope to see you there. RSVP and subscribe in our Luma calendar.

Jordan Bergero (Block): Building Reliable MCP Servers with Goose & MCP Tool Layering in Square MCP Server

Jordan shared how his team turned an internal hack week project into a production-grade MCP server at Square, which now powers real developer workflows.

Key Highlights:

Introduced Goose: an open source, LLM-agnostic tool for running and testing MCP servers locally in a GUI or terminal experience.
Explained Square’s "layered approach" (discover → plan → execute) to reduce API confusion. This structured layering helps make results predictable and reproducible.
Goose read a raw .txt file of invoice notes, parsed out customer and payment data, called multiple Square API endpoints (customer create, order create, invoice publish), and emailed real invoice all from a single prompt.

Why it matters: An impressive real-world example of turning API chaos into structured tool behavior.

Check out Jordan’s full session on YouTube and connect with them on LinkedIn.

Melissa Herrera (Langflow): Langflow as a Visual MCP Client and Server

Melissa brought the energy and delivered a lightning-fast tour of Langflow, a visual IDE for building agent workflows with drag-and-drop ease.

Key Highlights:

MCP Client & Server: Langflow can act as both an MCP client (calling tools via agent workflows) and a server (exposing your flows as tools), letting you chain, compose, and republish.
Multi-agent architecture: She showcased a resume enhancer app that parsed a resume, queried live job market data via Tavily, and returned improvements all orchestrated across multiple agents.
Tool Reuse: Demonstrated turning any Langflow component into a reusable tool and exporting it as part of a server bundle.

Why it matters: For devs or visual thinkers, Langflow is a developer-friendly launchpad for building composable, LLM-native tools.

Check out Melissa's full session on YouTube and connect with them on LinkedIn.

Lizzie Siegle (Cloudflare): Podcast Generator with Workers + MCP

Lizzie brought some joy (and a surprise) with her talk on building and deploying fun, voice-powered MCP apps on Cloudflare Workers.

Key Highlights:

Serverless podcast generator: Combined Claude, Workers AI, and a Cloudflare D1 SQL database to build a podcast generator that outputs both audio and script content.
End-to-end deployment: Demonstrated how to go from zero to a deployed MCP server using Cloudflare’s click-to-deploy button. Most code was auto-generated, including durable object support.
Tool listing & persistence: Saved generated podcast metadata and audio URLs to SQL, and exposed a tool to query prior results.

Why it matters: Cloudflare’s infra stack is well-suited for lightweight AI applications. If you want a fast way to host, persist, and serve LLM workflows globally, this is a great blueprint.

Check out Lizzie's full session on YouTube and connect with them on LinkedIn.

Tobin South (WorkOS): Securing MCP Servers

Tobin delivered a high-impact talk focused on the security foundations of MCP infrastructure.

Key Highlights:

Highlighted common authentication pitfalls in community-deployed MCP servers and the growing need for OAuth and SSO.
Gave a crash course in OAuth and SSO for MCP, including how to support dynamic client registration properly.
Demoed a secure, OAuth-powered MCP server for ordering custom swag.

Why it matters: If you’re shipping MCP servers to users or enterprises, this talk is your must-watch.

Check out Tobins full session on YouTube and connect with them on LinkedIn.

Michael Watson (Apollo): Token-Efficient MCP Servers with GraphQL

Watson closed the night with a deep dive into how token efficiency and schema-first tooling can make LLM interactions smarter and cheaper.

Key Highlights:

Token bloat audit: Analyzed GitHub's MCP server responses which produced 8.5k+ tokens per tool call caused by duplicate and irrelevant fields.
Selective GraphQL queries: Used GraphQL selection sets to omit unneeded data, reducing token usage by 75% to about 2,000 tokens.
Hot-reloadable tools: Showed how the Apollo MCP server can load tools directly from .graphql files with no build step needed.
Live demo: Used Goose to introspect GitHub’s GraphQL schema and auto-generate a working tool in minutes, then hot-loaded it into the server.

Why it matters: GraphQL-first design gives you clean, typed, and cost-efficient tooling which is a superpower for scaling MCP use.

Check out Watson's full session on YouTube and connect with them on LinkedIn.

What’s Next: Join the MCP Server Builder Community

This was just the beginning. Our mission is to support and grow a community of developers building smarter MCP tools.

Check out our MCP Server

Apollo's own MCP server is open source and we have a full tutorial on Odyssey that will get you up and running building your own tools.

Join future events

We host meetups regularly. Check out our Luma event page to RSVP for the next one in SF, NYC, or virtually.

Get involved

Got something to show? Built a server? Join our talks or share in the Apollo Community.

From REST to GraphQL in minutes with prebuilt Connectors

Amanda — Fri, 13 Jun 2025 15:25:32 +0000

We’ve all been there: vague API docs, an outdated OpenAPI spec, and a half-buried list of endpoints that leave you guessing. With prebuilt REST Connectors, you skip the guesswork. Just download the schema files, run your graph locally, and start querying live data with GraphQL.

In this guide, we’ll use the Space Devs Launch Library 2 in the Connectors Community repo as an example to show how easy it is to integrate a REST API into your graph in minutes and how you can tailor it to meet your needs.

Prerequisites

-Create an Apollo Studio account. This allows you to create and manage your graph, providing the necessary credentials, APOLLO_KEY and APOLLO_GRAPH_REF (more on those later…) which the Apollo Router uses to fetch the supergraph schema and run locally.
-Install and authenticate Rover CLI which we will use for configuring our graph and running Apollo Router locally.

Setup

In your working directory, initialize your schema with:

rover init

Select the option to create a new graph.

Then “Start a graph with one or more REST APIs”.

Next you will name your graph and Rover will generate you a new ID for your graph and APOLLO_KEY. Once your APOLLO_KEY and GRAPH_REF are generated,you can start the router with the command provided, but I would recommend putting these values in an VSCode > settings.json. The configuration below will ensure these environment variables are loaded into any new VSCode terminal windows you open:

{

 "terminal.integrated.profiles.osx": {

   "graphos": {

     "path": "zsh",

     "args": ["-l"],

     "env": {

       "APOLLO_KEY": "<YOUR_KEY>",

       "APOLLO_GRAPH_REF": "<GRAPH_REF>"

     }

   }

 },

 "terminal.integrated.defaultProfile.osx": "graphos"

}

Rover generated a supergraph.yaml file for you. You can delete this.

Using thespacedevs prebuilt connector

Next, navigate to thespacedevs folder in the Connectors Community repo. This Connector is an implementation of the Space Devs Launch Library 2. Download all of the graphql files here and the supergraph.yaml. You can add these to the root of your project folder. Rover generates test schema files and a supergraph. Anything that is duplicated or you do not need can be removed.

Next, open your terminal and run the following.

rover dev --supergraph-config supergraph.yaml

That’s it! Your graph is live at http://localhost:4000. Pop it open in your browser to explore the queries in Apollo Sandbox.

Modifying a prebuilt connector

You can use a prebuilt Connector as is or modify it for your application. For example, I’d like to add more information about what a valid search string looks like for upcoming launches.

In launches.graphql find the upcoming launches query and place this comment above it.

"""
Fetches a list of upcoming launches by agency name. 
Try Starlink, Nasa, or Exa for example.
"""
upcomingLaunches(search: String, limit: Int = 5, offset: Int = 0): LaunchConnection

   @connect(

     source: "llv2"

     http: {

       GET: "/launches/upcoming/?search={$args.search}&limit={$args.limit}&offset={$args.offset}&format=json"

     }
...rest of code

Save your file and you will see your new comment as context in the query builder.

What’s Next?

Once you have the prebuilt Connector ready for your use case now you are ready to integrate it to a client. To continue exploring where to use this Connector, take a look at this tutorial to learn how to replace traditional REST API calls in a React and Next.js application. Or write your very first MCP tool using the Apollo MCP server. There’s even a ready to go example using The Space Devs Api for MCP you can use.

There are many prebuilt Connectors ready to use or extend including Stripe, OpenAI, AWS Lambda, and more. Motivated to build your own Connectors to share with the community? We welcome contributions! Learn how to submit your Connector in the Connectors Community repo.

Simplify Your REST API Logic in React with Connectors for REST APIs and GraphQL

Amanda — Thu, 29 May 2025 20:10:27 +0000

If you’ve built a React or Next.js app that talks to multiple REST APIs, you’ve probably got a file like actions.ts set up as a central spot for fetch calls to public services like the USGS Earthquake API or Nominatim’s reverse geocoder. It works, but the code often ends up repetitive, brittle, and difficult to maintain or scale when different endpoints need to talk to each other.

In this post, we’re going to take that same setup and clean it up with a GraphQL layer powered by Apollo Connectors. Instead of orchestrating data in actions.ts, we’ll define a GraphQL schema that does the work for us. Using a declarative configuration, we’ll unify earthquake and location data in a single query with no need for custom resolvers or custom backend logic. The goal: to make your frontend simpler and your data fetching smarter, without giving up the REST services and patterns you already know.

Prerequisites

Create an Apollo Studio account. This allows you to create and manage your graph, providing the necessary credentials APOLLO_KEY and APOLLO_GRAPH_REF (more on those later…), which the Apollo Router uses to fetch the supergraph schema and run locally.
Install and authenticate Rover CLI, which we will use for configuring our graph and running Apollo Router locally.

Setup

In the directory you want to host your schema in run:

rover init

Follow the prompts in the CLI to create a new project.

Rover will generate a command for you that contains your APOLLO_KEY and GRAPH_REF. You can start the Router with the command provided, but I would recommend putting these values in an VSCode > settings.json.

{
 "terminal.integrated.profiles.osx": {
   "graphos": {
     "path": "zsh",
     "args": ["-l"],
     "env": {
       "APOLLO_KEY": "<YOUR KEY>",
       "APOLLO_GRAPH_REF": "<YOUR GRAPH REF>"
     }
   }
 },
 "terminal.integrated.defaultProfile.osx": "graphos"
}

Next create a file at the root called router.yaml and place this code in it. This is to override CORS errors while working in dev. This is not for use in production.

cors:
 allow_any_origin: true

If you haven’t already open your project in VSCode or your IDE of choice and from the terminal run:

rover dev --router-config router.yaml --supergraph-config supergraph.yaml

Building the Schema

Create a new file called earthquake.graphql and paste the following code.

Note: If you prefer, the completed schema can be found here.

@link(url: "https://specs.apollo.dev/federation/v2.10", import: ["@key"]) # Enable this schema to use Apollo Federation features
@link( # Enable this schema to use Apollo Connectors
   url: "https://specs.apollo.dev/connect/v0.1"
   import: ["@connect", "@source"]
 )
@source(
   name: "usgs"
   http: { baseURL: "https://earthquake.usgs.gov/fdsnws/event/1/" }
 )


type EarthquakeProperties {
 mag: Float
 place: String
 time: Float
 updated: Float
 url: String
 title: String
}


type EarthquakeGeometry {
 #this returns 3 values - lon,lat,depth in km
 coordinates: [Float]
}


type Earthquake {
 id: ID!
 properties: EarthquakeProperties
 geometry: EarthquakeGeometry
 }


type Query {
 recentEarthquakes(limit: Int! lat: String! lon: String! maxRadius: Int!): [Earthquake]
   @connect(
     source: "usgs"
     http: {
       GET: "query?format=geojson&latitude={$args.lat}&longitude={$args.lon}&maxradiuskm={$args.maxRadius}&limit={$args.limit}"
     }
     selection: """
       $.features
      {
       properties{
         mag
         place
         time
         updated
         url
         title
       }
       geometry{
        coordinates
       }
       id
     }

     """
   )
}

The first two directives following @ link are required at the top of any file to enable Connectors and federation. The @ source directive is used to point to our base URL for USGS earthquakes.

Underneath this there are three types: Earthquake, EarthquakeProperties, and EarthquakeGeometry. Here we are defining what we want to make available in our schema. You can build this however you want and include as much of the REST API as is valuable for your application. Here you will also define all the types and what values are nullable.

Finally you will see the query type. In this schema we only have one query, but you can build out as many as you need. For example, while this calls recent earthquakes and takes in four parameters, you may also want to include a query for retrieving one earthquake by Id. What you design in this schema is dependent upon the needs of your application and frontend team. Inside this query, you will see the @connect directive which is where you declare what populates this query and how it will return in the selection set below.

Adding a second REST API

Next, we want to add extended location details for each earthquake using Nominatim. To do this, add in another source directive below the USGS one.

@source(
   name: "location"
   http: {
     baseURL: "https://nominatim.openstreetmap.org/"
     headers: [{ name: "User-Agent", value: "testing" }]
   }
 )

Nominatim requires user-agent headers but the value passed can be anything you want.

Next, in your Earthquake type add a new field “display_name” and the following code:

type Earthquake {
 id: ID!
 properties: EarthquakeProperties
 geometry: EarthquakeGeometry
 display_name: String
 @connect(
   source: "location"
   http: {
     GET: "reverse?lat={$this.geometry.coordinates->slice(1,2)->first}&lon={$this.geometry.coordinates->first}&format=json"
   }
   selection: """
   $.display_name
   """
 )
}

Here we use a Connector for REST to declare that display_name comes from Nominatum. Later in the React app, we’ll cover how you can alias this to what you are using on your frontend. You can also alias here in the schema if you choose. The $this key references the parent Earthquake object.

Your schema is ready, the last thing we need to do before testing it is to update your supergraph.yaml to point to your file. It should look like this:

subgraphs:
 earthquake:
   routing_url: http://localhost:4000
   schema:
     file: earthquake.graphql
federation_version: =2.10.0

To learn about configuring your Router, you can head over to the documentation to see more options especially relevant once you are ready to go to production.

Testing the Query

Head to http://localhost:4000 to create and test the query for your app.

Once you have confirmed that your graph is working as expected, it’s time to move to the React app to see what we need to modify. Leave your local Router running as you will need it to be able to test your application.

Modifying the React App

Clone the repo and install the dependencies, run the project.

Open actions.ts so we can investigate the API calls.

There are two functions here, one to call USGS and a second to then call Nominatim on each returned value. There is also some code here to create the necessary object for our frontend.

export async function searchEarthquakes(
 latitude: number,
 longitude: number,
 maxRadius: number,
 limit = 20
): Promise<Earthquake[]> {
 try {
   // Build USGS Earthquake API URL
   const url = `https://earthquake.usgs.gov/fdsnws/event/1/query?format=geojson&latitude=${latitude}&longitude=${longitude}&maxradius=${maxRadius}&limit=${limit}`;


   // Fetch earthquake data
   const response = await fetch(url);


// rest of code omitted here. . . . .


   return earthquakesWithLocation;
 } catch (error) {
   console.error("Error fetching earthquake data:", error);
   return [];
 }
}

Integrating your GraphQL query doesn’t have to be complicated. If you’re comfortable writing a query and calling fetch, you already know 90% of what you need. Head back to the GraphQL sandbox and click the 3 dots to the right of your query. Then select copy to cURL.

Note: If you would rather follow along with the final version, take a look at this branch.

In actions.ts inside the try/catch block at the top, paste your curl. This is a little difficult to read so if you are in VSCode, this is a good place to use copilot to make this more readable. The end result should look like this.

const query = `
    query RecentEarthquakes($limit: Int!, $lat: String!, $lon: String!, $maxRadius: Int!) {
      recentEarthquakes(limit: $limit, lat: $lat, lon: $lon, maxRadius: $maxRadius) {
        id
        locationDetails: display_name
        properties {
          mag
          place
          time
          updated
          url
          title
        }
        geometry {
          coordinates
        }
      }
    }
  `;


  const variables = {
    limit,
    maxRadius,
    lat: latitude.toString(),
    lon: longitude.toString(),
  };


  const response = await fetch("http://localhost:4000/", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      query,
      variables,
    }),
  });
if (!response.ok) {
    throw new Error(`GraphQL API error: ${response.statusText}`);
  }


  const {data} = await response.json();


  const earthquakes = data.recentEarthquakes ?? [];
   console.log(earthquakes)
  return earthquakes;

Here you have your query, the parameters needed from the frontend, and a fetch call to your graph. Notice we are providing an alias to display_name to locationDetails to match our frontends shape.

Let’s clean up the old code.

In the try/catch block you can remove the rest of the code.

// Build USGS Earthquake API URL
   // const url = `https://earthquake.usgs.gov/fdsnws/event/1/query?format=geojson&latitude=${latitude}&longitude=${longitude}&maxradius=${maxRadius}&limit=${limit}`;


   // // Fetch earthquake data
   // const response = await fetch(url);


   // if (!response.ok) {
   //   throw new Error(`USGS API error: ${response.statusText}`);
   // }


   // const data = await response.json();
   // const earthquakes = data.features as Earthquake[];


   // Get location details for each earthquake
   // const earthquakesWithLocation = await Promise.all(
   //   earthquakes.map(async (quake) => {
   //     try {
   //       // Get location details from Nominatim
   //       const locationDetails = await getLocationDetails(
   //         quake.geometry.coordinates[1], // latitude
   //         quake.geometry.coordinates[0] // longitude
   //       );


   //       // Add location details to earthquake properties
   //       return {
   //         ...quake,
   //         locationDetails: locationDetails ?? undefined,
   //       };
   //     } catch (error) {
   //       console.error(
   //         `Error getting location details for earthquake ${quake.id}:`,
   //         error
   //       );
   //       return quake;
   //     }
   //   })
   // );


   // Log the first earthquake with location details for debugging
 //   if (earthquakesWithLocation.length > 0) {
 //     console.log(
 //       "First earthquake with location details:",
 //       JSON.stringify(
 //         {
 //           id: earthquakesWithLocation[0].id,
 //           hasLocationDetails:
 //             !!earthquakesWithLocation[0].locationDetails,
 //           locationDetails:
 //             earthquakesWithLocation[0].locationDetails,
 //         },
 //         null,
 //         2
 //       )
 //     );
 //   }


 //   return earthquakesWithLocation;

You can also remove the entire function call for getLocationDetails. We are now calling exactly what we need in one GraphQL query so we do not need this second function or API call here.

async function getLocationDetails(
//   latitude: number,
//   longitude: number
// ): Promise<string | null> {
//   try {
//     // Add a small delay to avoid rate limiting
//     await new Promise((resolve) => setTimeout(resolve, 100));


//     const url = `https://nominatim.openstreetmap.org/reverse?format=json&lat=${latitude}&lon=${longitude}`;


//     const response = await fetch(url, {
//       headers: {
//         "User-Agent": "EarthquakeSearchApp/1.0",
//       },
//       // Ensure we don't cache the response
//       cache: "no-store",
//     });


//     if (!response.ok) {
//       console.error(
//         `Nominatim API error: ${response.status} ${response.statusText}`
//       );
//       return null;
//     }


//     const data = await response.json();


//     // Log the response for debugging
//     console.log(
//       `Location details for ${latitude},${longitude}:`,
//       JSON.stringify({ display_name: data.display_name }, null, 2)
//     );


//     return data.display_name ?? null;
//   } catch (error) {
//     console.error("Error getting location details:", error);
//     return null;
//   }
//}

By modifying this file to use our new GraphQL query, we eliminated over 50 lines of redundant code without changing any UI logic. It’s a reminder that simplicity scales and a practical example of how to keep your GraphQL integration dead simple.

Another interesting thing to notice here is that searchByPlace is still intact and using REST. Using Graphql is not all or nothing, you can adopt it in your applications when it makes sense and use it alongside your other REST API calls. This allows you to adopt Graphql slowly without breaking other parts of your application which is especially important if you work with multiple teams.

Save your files and navigate to http://localhost:3000 to see your updates in action.

Wrapping up

While this example uses Apollo Router and Connectors for REST APIs to keep things simple and local, in a production app you’d typically pair this setup with Apollo Client on the frontend. Apollo Client handles caching, state management, and reactive updates, all the things you’d expect in a mature GraphQL application.

But the key point here is GraphQL doesn’t have to be all-or-nothing or hard to adopt. By adding a lightweight GraphQL layer over your existing REST services using Connectors, you can reduce boilerplate, simplify frontend data fetching, and set yourself up for more scalable, maintainable code. And when you’re ready, tools like Apollo Client make it easy to fully integrate this into your application architecture.

To get started building your first Apollo Connector for REST APIs today, check out the documentation or get started with pre-built connectors.

GraphQL is for Backend Engineers

Dylan Anthony — Mon, 05 Feb 2024 22:22:42 +0000

Most articles explaining the benefits of GraphQL focus on advantages for the frontend: things like preventing overfetching, reducing round trips, and iterating faster. But GraphQL provides just as many advantages for backend developers, which is why I choose it by default for new APIs and why you should consider it, too.

Improved communication

The goal of building any API is to enable someone to use it, which requires excellent communication between API producers and consumers. However, the state of the art for REST APIs doesn’t quite live up to this expectation.

On the backend, developers either need to manually document the entire API or rely on auto-generation tools that don’t fully meet their needs. Consumers face the same choice, write code by hand or workaround the bugs in their SDK generator (stated, lovingly, as the maintainer of an OpenAPI client generator). On top of this, these solutions result in inconsistent understandings of the API. Reproducing errors becomes time-consuming and frustrating, which feels like a battle instead of a collaboration. What we need is a shared language to describe how the API works—one that doesn’t add unnecessary layers of abstraction or manual work.

Meet GraphQL, where every team uses the same schema definition language (SDL) to talk about the API. SDL is designed for developers, omitting extraneous details while describing all the essential bits. This serves both as your documentation and a universal language to communicate between teams.

On the backend, developers can write code in their language of choice and have the SDL created for them. Alternatively, they can write the SDL by hand, and generate the required code. Either way, the documentation is always kept in sync with the implementation.

Consumers use this same SDL directly, so there’s no need to maintain a separate documentation website. Instead, they can get information, auto-complete names, and see potential mistakes right in their IDEs. The same request they write in their code can be run by itself for easier debugging, which makes sending snippets to the backend team much more straightforward. With clearer communication, there will be fewer open issues and less wasted time tracking down minor bugs.

Less bikeshedding

Bikeshedding is when you spend time discussing decisions that don’t have a significant impact, and it happens quite a bit with RESTful APIs. To name a few, I have been in bikeshedding meetings about:

Which verb to use? PUT and POST could have a lot of overlap. Maybe you *should*use GET, but the fact that it can’t contain a body is too limiting for the amount of filters you need.
Should this be a query parameter, path parameter, form data, or JSON body? For path parameters, how should we serialize arrays? What about objects?
Do we completely normalize endpoints to reduce duplication, even though that causes slower client performance? Or include the kitchen sink even though that causes slower individual endpoint performance? Maybe a compromise with shallow nested objects containing only the most common parameters or a parameter that allows selecting fields, emulating GraphQL without the type safety.
Which HTTP status code is the right one for each response?
Should relationships be indicated with IDs or URIs?

Hopefully, these discussions will lead to a comprehensive style guide, but the meetings will continue even with those guides. While there will always be some debate around things like naming, GraphQL eliminates entire categories of potential style issues (including all those above) by being simpler. You can spend less time on the little details and more time solving more interesting problems.

Reduce tech debt

Imagine you have a /v1/data endpoint called by all your frontend teams: web, iOS, and Android. You decide that the date field should return UTC instead of localized time, so how do you make that breaking change? It usually looks something like this:

Create a new /v2/data endpoint.
Inform all the client teams that this new endpoint exists and that they should migrate by some date.
Track metrics on /v1/data and send reminders to consumers who haven’t updated.
The deprecation date comes and goes, and you’re still receiving calls to the old endpoint.
You either pull the plug and start breaking things or, more likely, continue to support the /v1/data endpoint indefinitely, creating tech debt with no apparent payoff date.

Now, let’s play through the same scenario with GraphQL. First, you add @deprecated(reason: “use utcDate”) to your old date field and add the new utcDate field. API consumers immediately start seeing warnings in their IDEs and potentially CI/CD about this deprecation since most GraphQL tooling supports it.

As it turns out, the iOS and Android teams weren’t even using the old date field, so no changes are necessary for them!

Someone on the web team notices some squiggly lines in their editor and decides to fix them, following the instructions left in the reason field. Your backend metrics tell you that the date field is no longer in use, and you’re safe to remove it!

Creating less churn and an easier upgrade path for clients makes them more likely to upgrade. If they upgrade faster, you can remove that stale old code faster, too!

GraphQL is for you too

One of the main features of GraphQL is its developer experience. By creating a shared language between teams, reducing complexity, and providing a smoother upgrade path, GraphQL makes building and maintaining APIs more delightful. That’s why, even if your frontend engineers aren’t pushing for it yet, you should start evaluating GraphQL for your tech stack. If you have any questions or disagree with anything I’ve said above, let me know on our Discord server! If you want to be notified of future posts, there’s also a channel for that.

Secure GraphQL Microservices

Dylan Anthony — Wed, 02 Aug 2023 18:17:49 +0000

Federation unlocks superpowers for our queries, enabling us to split up business logic and improve performance with features like @defer. However, these same powers can be abused if placed in the wrong hands, so it’s essential to limit who has access to them.

The threats

Many coordination features of a federated graph rely on an important assumption: clients always query your router—never individual subgraphs. If this assumption is violated and clients query your subgraphs directly, you might expose data and capabilities that you shouldn’t:

The @inaccessible directive enables subgraphs to define schema fields that other subgraphs might need, but that the router shouldn’t expose to clients. If clients can query a subgraph directly, those queries can include @inaccessible fields. And even if you don’t have any sensitive @inaccessible fields in your graph today, you might in the future!
The @requires directive enables a subgraph to define schema fields that depend on entity fields from other subgraphs. Subgraphs rely on the router to resolve this dependency, ensuring that trusted data is provided. But if clients have direct access to subgraph entity resolvers, that data can no longer be trusted.
The @override directive enables a subgraph to take responsibility for a schema field away from another subgraph. With direct subgraph access, clients can still query the original subgraph field, which can result in inconsistent and unexpected behavior.

This is just a small selection of the available features today, and more will be added over time. The key takeaway is that federation is a microservice architecture that expects a single entry point through a controlled router. If subgraphs can be accessed directly, it’s only a matter of time before something unexpected happens, and that unexpected event could be a security breach.

Protecting your subgraphs

Exposing subgraphs publicly opens the door to several attacks. To mitigate them, we prevent anything but our routers from accessing our subgraphs. First, we can protect our subgraphs at the application level by adding an extra layer of authorization on top of whatever user auth may be in place. We can configure our routers to send a header containing a shared secret to each of our subgraphs:

headers:
  subgraphs:
    orders:
      request:
        - insert:
          name: "Router-Authorization"
          value: "${env.ORDERS_SUBGRAPH_SECRET}"
    users:
      request:
        - insert:
          name: "Router-Authorization"
          value: "${env.USERS_SUBGRAPH_SECRET}"

Notice that we use a unique secret per subgraph, following a security best practice called “the principle of least privilege”. If there’s no reason for the orders subgraph to have direct access to the users subgraph, then we should not give it the ability to do so (by sending it valid tokens for another subgraph).

These values come from environment variables, so how you set them will depend on where you’re running your routers. Most secret managers have a way to inject values via an environment variable. For example, in GraphOS, you can set secrets via the UI.

How this looks on the subgraph side depends on your implementation. Here’s an example using FastAPI in Python:

@app.middleware("http")
async def check_router_security(
    request: Request, call_next: Callable[[Request], Awaitable[Response]]
) -> Response:
    router_secret = environ.get("ROUTER_SECRET")
    if router_secret is None:
        return await call_next(request)
    if request.headers.get("Router-Authorization") != router_secret:
        return Response(status_code=HTTPStatus.UNAUTHORIZED)
    return await call_next(request)

Here, we’re setting up the expected token as an environment variable called ROUTER_SECRET in our subgraph. This value would be injected via the secret manager for your hosting platform. If the secret is not set (such as in local development), we turn off this enforcement; you may want to add a more sophisticated method of ensuring this is never turned off in production. If the secret is set, we ensure every request has a matching Router-Authorization header. Requests without a valid header will get a bare response with a 401 Unauthorized code—we don’t send any additional information that clients don’t need, and unauthenticated requesters don’t even need to know that this is a GraphQL server.

We have examples for many languages and frameworks in our subgraph templates, so check them out for more inspiration!

Extra credit: network protections

As an additional step, depending on your hosting environment, you may be able to use network-level protections to prevent any incoming connections to your subgraphs except your routers. This is typically done via firewall rules (such as access control lists). Not all platforms or architectures will have this option, but if you do, we recommend adding it as a “defense in depth”.

Ruling out alternatives

There are a few other solutions to this problem that might seem viable but can cause issues. Let’s go over them!

First, you might be tempted to apply router authorization checks only for federation-specific subgraph fields (_service and _entities ), but there are problems with this approach:

Newer versions of federation might add more subgraph fields in the future, which would introduce new vulnerabilities that special-case checks don’t handle.
This approach doesn’t solve the problem of reaching @inaccessible or @requries fields via a top-level Queryfield (a standard, non-federated query).

Second, you might be tempted to enforce router authorization per field, maybe even automatically for any field that implements a federated directive. However, federation enables any single subgraph to influence the behavior of the entire supergraph. For example, if @inaccessible is applied to a field in any subgraph, it’s expected to be enforced on every subgraph. This means that per-field, per-subgraph enforcement is fundamentally inconsistent and can lead to unexpected data leakage.

Finally, you might consider disabling introspection as a solution—if attackers can’t discover the hidden fields, they can’t use them, right? This is called “security by obscurity” and is widely considered not security at all. A sufficiently determined attacker will eventually guess the names of fields that you don’t want them to find.

The only consistent approach to preventing undesired access to subgraph capabilities is to disable access to subgraphs entirely to any client besides the router.

Get secure

Now that you know the dangers of exposing subgraphs publicly and the best approach to mitigating the threat, there’s nothing left to do but start implementing! Start securing your subgraphs immediately.

Have any questions, comments, or concerns about this post? I’d love to hear about it in our Discord server! That’s also where you’ll be notified of upcoming security-related live streams.

Performance impacts of Apollo Router customizations

Lucas Leadbetter — Mon, 17 Jul 2023 20:14:24 +0000

The Apollo Router features three customization options out of the box to adjust behavior: configuration options, Rhai scripting, and external coprocessing. We refer to these as extensibility options.

Extensibility of the Router is one of its primary strengths and is a critical feature for many organizations large and small. Understanding the performance implications of these options is important as the Router is designed for performance and serves as the entry point to your supergraph. We’re excited to share results with you covering these extensibility options, as well as a public GitHub repository where you can test them yourself.

Before diving into the methodology and detailed results, the high-level results are:

When you’re able to choose, configuration options perform better than Rhai scripts, and Rhai scripts perform better than external coprocessing.
When you must use an external coprocessor for more complex logic, we see about 350μs overhead.
The choice of programming language, complexity of task, network proximity, type of host machine, and other factors will have varying impacts on the real-world performance of your Router and coprocessor, so ensure you consider the best tool for the job, so to speak, and keep the coprocessor as close as possible to the Router. Ideally this would be within the same Pod (if using Kubernetes) or similar for other orchestration systems.

The GitHub repository includes more information about the results, including specific numbers, as well as the ability to run these tests yourself.

Methodology

As with any test, determining how to best isolate the variable you want is critical to ensure you’re not introducing other factors into the results. For the tests we ran, we wanted to isolate the overhead for each extensibility option, not the performance impact of each test we ran.

To help isolate overhead latency, we ensured that we pre-warmed the query plan cache to remove the initial overhead of query planning to the first request (which may have skewed results by adding a request with a higher maximum latency value). We do this by running curl commands after the Router restart with both of the test queries.

We also limited the resources for each running Docker image to use only 1 CPU core and 1GB of RAM as a way to ensure a consistent result from run to run. While this may have impacted some programming language implementations, we wanted to give a level playing field for each test.

With that in mind, we designed three different tests for the extensibility options. This allowed us to show various overheads, as well as showing the impact of not only the complexity, but potential impact of the coprocessor stages.

Setting a static subgraph header, which is supported by all three extensibility options. This was the simplest example available, and helped test the overhead of a SubgraphRequest coprocessor stage. Since this logic is run per-subgraph on both the coprocessor and in Rhai, we wanted to understand the overhead of multiple invocations.
Setting 10 GUID headers on a response, which is supported by only Rhai and external coprocessing. This test was designed to have slightly more complex logic, while also showing something that wasn’t possible with a basic configuration.
Lastly, we tested setting the client awareness headers using claims within a JSON Web Token (JWT) which can only be done in a coprocessor as of writing. This was the most complex logic we tested, and was a way to show how complexity could affect results as well as being an example of something only possible with external coprocessing.

Each of these tests were run against a baseline Router (that is, a basic Router without any configured extensibility options), and a Router with the respective extensibility options configured with coprocessors being implemented in Node.js, Python, Go, Java, and C#. Between each run, we restart the Router and pre-warm the query plan cache.

For every test, we utilized a custom version of Vegeta, a Go-based load testing utility. Our version handles GraphQL errors within the payload and treats them as non-2XX results for the purposes of reporting failures appropriately. Each run was set to 100 requests per second for 60 seconds to adequately load-test the system and provide enough data points for reference.

Results

Overview

Diving into the results, we saw that most workloads benefit by using configuration options over Rhai scripts, and Rhai scripts are better than external coprocessing in terms of overhead.

Rhai performance was excellent across the board, with latency overheads in p95s being around 100μs. This overhead makes it an excellent choice for most customization needs, as it tends to cover most use-cases that can’t traditionally be done with the basic configuration options.

External coprocessing overhead was still excellent at 350μs overhead per stage average across all tests and languages, so for those that need more complex logic (such as the client awareness test showed), it can still be an excellent fit with great performance. With that in mind, there are additional elements here that are worth diving into.

Your runtime/programming language matters, and will affect results depending on the type of customizations you need.

Each language has its strengths and weaknesses, so ensure you pick the right tool for the job when deciding what to use for your coprocessor.

Even more important than runtime, your networking setup is critical to ensuring optimal performance.

Since external coprocessing communicates over HTTP, reducing the latency between your Apollo Router and external coprocessor will ensure optimal performance and reduce overhead. If you are using Kubernetes, for example, running the coprocessor as a container alongside the Router in the same Pod can ensure network proximity.

Ensure you need to use SubgraphRequest/Response stages before using them

The coprocessor overhead is per stage, so if you run a query that hits 5 subgraphs, you’ll end up with 5 invocations of the SubgraphRequest/Response stages for a coprocessor. This overhead can add up quickly, so it is advisable to validate your need to use this stage before utilizing it.

Per-Test Results

Looking at each test individually, we can start to make sense of some of the above information, as well as see the percentage differences from the baseline.

The numbers used were from the most recent test, running on Windows using WSL2, but your latency numbers may vary depending on resources available, CPU, OS, and more. The takeaways themselves should remain the same.

For the static subgraph header test, we added a "coprocessor" header with the value of the type of extensibility (e.g. rhai for Rhai scripts). This leveraged the SubgraphRequest stage for a coprocessor, and we aimed to test the overhead of making multiple requests. For this test, we averaged 1.5 subgraphs per request.

We can start to see that we are running into minute variance issues. In the above chart, we show that both Python and the config option are faster than the baseline- but the raw data shows that they are only 40μs and 10μs difference, respectively. Regardless, the actual overhead was measured around 330μs averaged across all coprocessor types. For specific details on each option, see the full results in the GitHub repository.

In the GUID response headers test, we wanted to add a level of logic that the configuration couldn't provide, as well as test the impact of a very basic looping logic to add dynamically generated GUIDs to the Router's response. To do so, we leveraged the RouterResponse stage for a coprocessor.

Breaking down the numbers, we see clearly that Rhai is far more performant- only 11% higher p95 latency than baseline, or only 10μs in our tests versus the minimum 17% change when using a Go-based coprocessor, and the others being higher.

For our last test, we wanted to test something logically complex as well as something only a coprocessor could do. This test decoded a JWT using an HMAC256 secret, and then used the claims to populate the apollographql-client-name and apollographql-client-version headers to enable client awareness for visibility in Apollo Studio.

This test shows how, while the HTTP overhead itself is minimal, the actual logic is far more important. Introducing complex logic can affect performance in a meaningful way, so using other extensibility options whenever possible will help reduce the overall overhead.

Conclusion

Prefer Router configuration options over other customization options whenever possible.
External coprocessors add, on average, only 350μs of overhead plus the overhead of your logic. This number can change depending on other factors, identified above.
Keep coprocessors as close as possible to the Router to ensure the overhead doesn't become too burdensome.

View the full results and implementation on the public GitHub page.

Don’t Overreact! Introducing Apollo Client’s new @nonreactive directive and useFragment hook

Alessia Bellisario — Thu, 15 Jun 2023 21:23:12 +0000

Efficient React apps are selective in their re-rendering, using a variety of techniques (such as memo) to skip re-rendering unchanged components. With the beta release of Apollo Client 3.8, we’re excited to spotlight a couple of new techniques to help you re-render exactly the components that you need to:

The @nonreactive directive: mark GraphQL query fields and fragments that shouldn’t trigger a re-render if their cached value changes.
The useFragment hook: create a live binding into the Apollo Client cache for a GraphQL fragment. This allows Apollo Client to broadcast specific fragment results to individual React components so child components can re-render without needing to re-render the parent.

Let’s look at how we can use these (both individually and in combination) to keep our app snappy!

(Re-)Rendering Lists

You might have found yourself reaching for memo while building an app with Apollo Client that renders a list. Consider the following example:

const UserFragment = gql`
  fragment UserFragment on User {
    name
  }
`;

const ALL_USERS = gql`
  query AllUsers {
    users {
      id
      ...UserFragment
    }
  }
`;

function UserComponent({ user }) {
  return <li>{user.name}</li>;
};

function UserList() {
  const { data } = useQuery(ALL_USERS);
  return (
    <ul>
      {data?.users.map((user) => (
        <UserComponent key={user.id} user={user} />
      ))}
    </ul>
  );
};

const client = new ApolloClient({
  link,
  cache: new InMemoryCache({
    fragments: createFragmentRegistry(gql`
      ${UserFragment}
    `),
  }),
});

const container = document.getElementById("root");
const root = createRoot(container);

root.render(
  <ApolloProvider client={client}>
    <UserList />
  </ApolloProvider>
);

By registering our UserFragment with Apollo Client’s InMemoryCache via createFragmentRegistry, we can reference it by name inside our queries (as we do here with the ...UserFragment spread in ALL_USERS) without interpolating it directly.

In this example, the UserList component fetches a list of users with Apollo Client’s useQuery hook, then maps over the result to render a UserComponent for each user in the list.

But what happens when a user record is updated in the Apollo Client cache? Because these cached fields are watched by our useQuery invocation, the hook re-runs. This re-renders UserList with the latest values, which in turn recursively re-renders every child component (by default). In other words, if a single user in our list is updated, the vast majority of our UserComponents will re-render even though they haven’t changed!

These unnecessary renders often go unnoticed by end users (and sometimes developers), but recursively re-running application and library code can add up to cause noticeable dips in performance.

To `memo` or not to `memo`?

The React docs provide excellent guidance for this question in the deep dive section “Should you add memo everywhere?” Like many optimizations, memo has a cost: the additional step of comparing old and new props on every render. Although that cost is often outweighed by the benefits, it’s still a cost you should consider.

I encourage you to read that section in its entirety, but here are two criteria from it that can help us determine whether we should optimize with memo (emphasis mine):

Does our component re-render often with the same exact props?
And is its re-rendering logic expensive, causing perceptible lag when it re-renders?

Let’s take a look at an example that extends the UserList code above.

When editing a single user and writing to Apollo Client’s InMemoryCache on every keystroke, we see that the parent component re-renders, along with all of the 2,000 UserComponents in our list. Typing in the input feels sluggish 🐌

Of course, this is a contrived example: there are other ways we might write this code in a real app to work around the problem: using pagination, debouncing cache writes so we aren’t updating the user list on every keystroke, or writing to the cache only after the user presses “Done editing”.

But there are reasons we shouldn’t be satisfied with these “fixes”. First, although rendering fewer users and/or performing fewer cache writes would improve perceived performance, we’d still be re-rendering parent and child components unnecessarily every time a user updates. Reducing the number of renders is a good place to start, but the dynamic nature of lists—iterating over N users, where N is usually known only at runtime—can make this tricky.

Maybe at first we don’t think we’re handling enough data to really need pagination, only to later notice performance has degraded when our ALL_USERS query returns more users than expected (been there 🙋🏻‍♀️). Or maybe our UserComponent starts out with a simple implementation that does minimal work on each render, but as our app grows it either becomes more complex or renders more complex children of its own.

I hope by now I’ve convinced you this is a problem worth solving! But is memo the answer?

Using the criteria from the React docs, our UserComponent is a good candidate for memoization: all other users in the list are re-rendering with the same exact props ✅, and each component is simulating expensive rendering logic, causing the DOM to perceptibly lag when applying updates to 2,000+ nodes on every keystroke ✅.

Sure enough, after wrapping UserComponent in memo, we can see the lag disappear:

Fun fact: even though objects, arrays and functions normally need to be memoized/cached when passing them as props to memoized React components (so they pass React’s Object.is same value equality check when determining whether the child needs to re-render), we don’t have to memoize the user objects we’re passing into our UserComponents. This is because Apollo Client’s normalized cache has already done the work to ensure the user objects we get from the cache are referentially stable 🎉

Rendering `memo` unnecessary

The lag is gone, but our work isn’t done. Notice that the parent component is still re-rendering on every keystroke, because our useQuery call is watching for changes on all users. We’re still re-rendering the parent, but now React is able to skip re-rendering all unchanged child components.

Re-rendering the parent has its own drawbacks: in a larger application, we’d also have to remember to wrap every other child of UserList in memo when needed (see the criteria above, rinse and repeat). And memo‘s comparison of all of those props still comes with a cost—one we’d like to avoid altogether.

Our Apollo Client team saw an opportunity here. We wondered: what if a parent component could ignore updates to certain fields on the selection set it’s watching in the cache? And what if each child component could react to updates for a single cache entity, without being prompted to re-render by its parent?

Enter `@nonreactive` and `useFragment`

Together, this new directive and hook unlock a pattern for rendering lists that selectively re-render individual list items by default—no memo required.

You can apply the @nonreactive directive to fields or fragments on the parent component’s query, and you can use it with or without Apollo Client’s React bindings (for example, in queries passed to client.watchQuery).

In our demo app, the AllUsers query becomes:

query AllUsers {
  users {
    id
    ...UserFragment @nonreactive
  }
}

Note: The parent component should receive updates for the id field (or whatever the equivalent cache key is for an entity), so we intentionally don’t apply @nonreactive to the id field here. This ensures that the parent does update when items are added or removed from the list.

Now, when cache updates arrive and Apollo Client is comparing the previous result with incoming data for a selection set to determine whether to update, it can avoid comparing fields that exist on subtrees of the @nonreactive fragment altogether. Less work for Apollo Client, and less work for React as a result.

Instead of passing each user object into UserComponent and wrapping it with memo, child components can use the id and fragment document to receive cache updates directly for each user in the list:

function UserComponent({ id }) {
  const { data: user } = useFragment({
    fragment: UserFragment,
    from: {
      __typename: "User",
      id,
    },
  });

  return <li>{user.name}</li>;
});

Any component watching for changes for a specific user via useFragment will re-render on its own when data changes. It no longer needs to wait for a parent to trigger a re-render by passing it fresh data via props!

Finally, our parent component no longer re-renders at all when updating users—only when users are added or removed. This gives us predictable behavior and performance, whether our list is 10, 100, or 1,000 users long! And we achieved all of this without memo. (You definitely should still use memo as needed to solve other performance issues, per the guidance in the docs!)

View the full CodeSandbox demo here. You can try out both @nonreactive and useFragment in our latest 3.8 beta via npm i @apollo/client@beta and view the documentation for both @nonreactive and useFragment for more information. We’d love to hear what you think!

My Favorite Resources for Learning GraphQL

Ceora Ford — Thu, 17 Mar 2022 18:25:11 +0000

I recently held a Twitter Space where I discussed how I learned GraphQL during my first few months as a developer advocate here at Apollo. I went over the strategies I used which can be really helpful regardless of what language, framework, or tool you’re learning on the job. If you're interested in checking out the recording, I’ll leave a link at the end of this article.

For now, I want to focus more on what I used to learn GraphQL. So here’s a quick list of my favorite resources for learning GraphQL. This list includes courses, videos, tutorials, and more. So no matter your preferred medium for educational content, you’ll find something that fits your style.

1. What is GraphQL YouTube Video

If you don’t know much about GraphQL or what problems it solves, this is a great video to start with. It covers the fundamentals of how GraphQL works and how developers benefit from using it.

2. GraphQL Odyssey Course

This is the main course I relied on when I was first learning GraphQL. This is free and it includes tons of great information and interactive coding exercises. And once you finish all 5 modules, you get a certificate!

3. GraphQL Is for Everyone Workshop

I was able to attend this workshop shortly after joining Apollo and it was amazing! This workshop is led by Eve Porcello and I love the way she teaches. All the information is delivered in a fun and approachable style. This is a great workshop to attend especially if you’re completely new to GraphQL.

4. GraphQL Email Newsletter

This email newsletter is also created by Eve Porcello. It’s an easy, low-stakes way to learn more about GraphQL. I’m a huge fan of Eve’s teaching style and this email course is just as great as everything else she creates.

5. Full Stack GraphQL Tutorial

This Full Stack GraphQL tutorial is a great way to start building with GraphQL. I’m a huge proponent of project-based learning. But it can be intimidating to start a project with a new language all on your own. So this is a great way to have a guided learning experience as you begin working with GraphQL.

6. Everything I Learned in My 1st Year as a SWE: GraphQL Article

I really enjoyed this article because hearing the perspective of another GraphQL newbie really resonated with me. It was nice to read about parts of Camila’s learning journey that mirrored my own. It also helped me to recognize areas of confusion that I, as a developer advocate and GraphQL educator, could help fill.

7. Getting Started with GraphQL Article

This is an article that’s quite similar to this one. It includes an explanation of what GraphQL is and additional resources for learning. Shruti is a pillar in the GraphQL community so I’m sure you’ll find something useful in that article.

8. GraphQL Glossary

I have to include this glossary because it was so helpful for me! I used it as a handy reference along with my courses and tutorials so I could easily check my understanding of unfamiliar terminology.

Conclusion

If you have any recommendations for GraphQL learning resources, please feel free to leave them in the comments below. Like I said, these are resources that I personally used and enjoyed. I’m sure that there are so many more out there.

If you’re interested in actual learning tips, you can listen to the recording of the Twitter Space. I plan on doing more Spaces about GraphQL, developer advocacy, and working at Apollo. So let me know if you have any suggestions. Thanks for reading💜

Behind the Scenes of Our "What is GraphQL" Video

Ceora Ford — Tue, 08 Mar 2022 16:01:18 +0000

Everyone has their own learning style. Some people prefer to read educational content. There are some developers who like to skip the reading and go straight to building and breaking things. Lots of people really enjoy video content. Then there are people like me who switch between all learning styles and content forms depending on the subject.

The developer experience team at Apollo realized we wanted to focus more on creating video content. It’s our job to create educational content that will appeal to developers and we want that to include videos. We recently released our first of many YouTube videos called What is GraphQL.

It took a lot of hard work from the whole team. I wanted to talk about the process we went through to create and release this video. Our process is going to change and evolve over time. We’ll probably look at this first behind-the-scenes view and marvel at how much we’ve improved!

So let’s pull the curtain back a bit and go over how we went about creating this video!

Coming up with ideas

Of course, everyone on the team had a ton of ideas for our videos. GraphQL is such a broad topic and there are so many creative things you can do with videos. To narrow down our focus, we had to think about a few things.

Videos can be hard to update and edit post-release. Apollo and GraphQL (and just tech in general) are constantly changing. It’s inevitable that some content will become deprecated in the long run. So for our more polished, high-effort videos, we decided to stick with concepts that are relatively constant and stable.

What is GraphQL fits this really well! The fundamental features of GraphQL probably won't change any time soon. Plus, what better way to kick off our new video initiative than starting from the very foundation of everything!

After deciding on what our first video would be about, we went on to write out our script.

Creating the script

Scripting is not easy. It reminds me of what it’s like to write a talk or an article. Coming up with the script and storyline for the video was a painstaking process. We wanted to be sure that our video was technically sound and worded just right. So we edited and edited and edited some more.

Of course, at one point and time, we had to stop ourselves. We weren’t aiming for perfection. We wanted something that would be really good and useful to the community. So after we finalized the script, our video team came up with some creative concepts to help us really get our ideas across.

Next, we assigned lines to different team members. We wanted this video to reflect the people who make up the developer experience team at Apollo. If you’ve watched the video, you probably noticed how we switch up between narrators to do this. All of this was written into the script and gave each of us a chance to rehearse our individual lines so we could be prepared for the next step.

Filming our video

Now onto filming. We got our fancy cameras and fancy lighting and started filming. And then we were done!

If you’ve ever filmed any kind of scripted video content, you know it wasn’t that simple. We had to learn how to properly set up all our fancy video equipment. After we figured that out, we had to get everything in just the right spot. This took a lot of adjusting. We had to make sure our microphones, lights, and camera angles were in the right place to give us the results we wanted.

Now we press record... and suddenly I can’t remember any of my lines. Remembering what I had to say was much harder than I expected. Once I could finally remember without messing up, I had to say my lines in a bunch of different ways to convey the tone we were going for. I had to make sure to look directly at the camera and smile.

We eventually got enough good takes to wrap up filming. Each of my team members who are featured in the video went through a similar process. Once each of us finished recording, our video team expertly stitched everything together, adding in amazing graphics and effects.

What’s next?

At the end of this process, we were able to release our video to the world! And the results have been amazing!! I'm incredibly proud of our team and I'm glad to see our hard work paying off.

Now we’re working on our next video. We’re already planning ahead for future concepts by gathering ideas and writing scripts. We would love to hear from you if you have any suggestions! Feel free to leave them in the comments below.

Keep an eye out for our next video and in (the most non-cliche way possible) subscribe to the Apollo GraphQL YouTube Channel so you'll know when it drops!! Thanks for reading.

⚡ Add a GraphQL Server to a RESTful Express.js API in 2 Minutes

Khalil Stemmler — Thu, 09 Jan 2020 18:47:04 +0000

⚡ Add a GraphQL Server to a RESTful Express.js API in 2 Minutes

You can get a lot done in 2 minutes, like microwaving popcorn, sending a text message, eating a cupcake, and hooking up a GraphQL server.

Yup. If you have an old Express.js RESTful API lying around or you're interested in incrementally adopting GraphQL, we only need 2 minutes to hook it up with a fresh new GraphQL Server.

Ready? Set. Go!

Let's say that your server looked something like the following.

import express from 'express';
import { apiRouter } from './router';

const app = express();
const port = process.env.PORT || 5000;

// Existing routes for our Express.js app
app.use('/api/v1', apiRouter);

app.listen(port, () => console.log(`[App]: Listening on port ${port}`))

At the root of your project, npm install apollo-server-express as a dependency.

npm install apollo-server-express --save

Go to where your Express app is defined and import ApolloServer and gql from apollo-server-express.

import { ApolloServer, gql } from 'apollo-server-express'

Next, create an instance of an ApolloServer with the simplest possible GraphQL type definitions and resolvers.

const server = new ApolloServer({
  typeDefs: gql`
    type Query {
      hello: String
    }
  `,
  resolvers: {
    Query: {
      hello: () => 'Hello world!',
    },
  }
})

Lastly, use ApolloServer's applyMiddleware method to pass in our Express.js server.

server.applyMiddleware({ app })

Boom. That's it!

Your code should look something like this.

import express from 'express';
import { v1Router } from './api/v1';
import { ApolloServer, gql } from 'apollo-server-express'

const app = express();
const port = process.env.PORT || 5000;

const server = new ApolloServer({
  typeDefs: gql`
    type Query {
      hello: String
    }
  `,
  resolvers: {
    Query: {
      hello: () => 'Hello world!',
    },
  }
})

server.applyMiddleware({ app })

app.use('/api/v1', v1Router);

app.listen(port, () => {
  console.log(`[App]: Listening on port ${port}`)
})

If you navigate to localhost:5000/graphql, you should be able to see your GraphQL schema in the GraphQL playground.

Note: If you want to change the URL that the GraphQL endpoint sits at from /graphql to something else, you can pass in a path option to server.applyMiddleware() with the URL you want, like path: '/specialUrl'. Check out the docs for full API usage.

How simple was that? Is your popcorn finished? 😉

Summary

Here's what we did.

Install apollo-server-express
Create a new ApolloServer
Connect your GraphQL Server with server.applyMiddleware

I personally really love the fact that Apollo Server is non-intrusive and can be tacked on any project as an alternative way to communicate between services and applications.

Where to go from here

If you're new to Apollo and GraphQL, a great way to learn is to actually build something in real life. For that reason, I highly recommend checking out the Apollo Fullstack Tutorial (you can also learn in TypeScript now 🔥).

I'm Khalil Stemmler, a Developer Advocate at Apollo GraphQL. I teach advanced TypeScript, GraphQL, and Node.js best practices for large-scale applications. Feel free to ping me on Twitter if you need help with anything Apollo, TypeScript, or architecture-related. Cheers 🤠

Forem: Apollo GraphQL

Meet the Builders: Highlights from the MCP Server Builder Meetup

Jordan Bergero (Block): Building Reliable MCP Servers with Goose & MCP Tool Layering in Square MCP Server

Melissa Herrera (Langflow): Langflow as a Visual MCP Client and Server

Lizzie Siegle (Cloudflare): Podcast Generator with Workers + MCP

Tobin South (WorkOS): Securing MCP Servers

Michael Watson (Apollo): Token-Efficient MCP Servers with GraphQL

What’s Next: Join the MCP Server Builder Community

From REST to GraphQL in minutes with prebuilt Connectors

Prerequisites

Setup

Using thespacedevs prebuilt connector

Modifying a prebuilt connector

What’s Next?

Simplify Your REST API Logic in React with Connectors for REST APIs and GraphQL

Prerequisites

Setup

Building the Schema

Adding a second REST API

Testing the Query

Modifying the React App

Wrapping up

GraphQL is for Backend Engineers

Improved communication

Less bikeshedding

Reduce tech debt

GraphQL is for you too

Secure GraphQL Microservices

The threats

Protecting your subgraphs

Extra credit: network protections

Ruling out alternatives

Get secure

Performance impacts of Apollo Router customizations

Methodology

Results

Overview

Per-Test Results

Conclusion

Don’t Overreact! Introducing Apollo Client’s new @nonreactive directive and useFragment hook

(Re-)Rendering Lists

To memo or not to memo?

Rendering memo unnecessary

Enter @nonreactive and useFragment

My Favorite Resources for Learning GraphQL

1. What is GraphQL YouTube Video

2. GraphQL Odyssey Course

3. GraphQL Is for Everyone Workshop

4. GraphQL Email Newsletter

5. Full Stack GraphQL Tutorial

6. Everything I Learned in My 1st Year as a SWE: GraphQL Article

7. Getting Started with GraphQL Article

8. GraphQL Glossary

Conclusion

Behind the Scenes of Our "What is GraphQL" Video

Coming up with ideas

Creating the script

Filming our video

What’s next?

⚡ Add a GraphQL Server to a RESTful Express.js API in 2 Minutes

⚡ Add a GraphQL Server to a RESTful Express.js API in 2 Minutes

Summary

Where to go from here

To `memo` or not to `memo`?

Rendering `memo` unnecessary

Enter `@nonreactive` and `useFragment`