Enhance customer experiences with Apollo GraphOS


<p><a href="https://www.apollographql.com/docs/federation/">Apollo Federation</a> is supported by over <a href="https://www.apollographql.com/docs/federation/building-supergraphs/supported-subgraphs">20 different subgraph libraries across 12 different programming languages</a>. Have you ever wondered how we capture those compatibility results?</p>



<p>In order to ensure those libraries are compatible with the specification, we have a <a href="https://github.com/apollographql/apollo-federation-subgraph-compatibility">testing repository</a> that verifies compatibility against their reference implementations. While it is great to have a testing suite verifying compatibility with the spec, up until recently, compatibility results were only available at the end of the library development lifecycle. Developers first had to implement the spec, release the library, create a reference subgraph implementation in the testing repo and then once the tests are run, they would finally get the compatibility results. We heard your pain and decided to streamline this process.</p>



<p>We are happy to announce that you can now easily run subgraph compatibility tests on your local machine and within your Github CI/CD pipelines! Compatibility test suite is now distributed as an executable <a href="https://www.npmjs.com/package/@apollo/federation-subgraph-compatibility">NPM script</a> and a corresponding <a href="https://github.com/marketplace/actions/apollo-federation-subgraph-compatibility">Github Action</a>!</p>



<p>Read below to see how you can now streamline your subgraph development process.</p>



<h2 class="wp-block-heading"><a href="#implementation-under-test" aria-hidden="true" class="aal_anchor" id="implementation-under-test"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Implementation Under Test</h2>



<p>We first need to create a subgraph that will be used for testing. In order to be able to consistently verify federation features, all subgraphs have to implement the same <a href="https://github.com/apollographql/apollo-federation-subgraph-compatibility/blob/main/COMPATIBILITY.md">reference schema</a>. Compatibility tests will be run against a supergraph which consists of your subgraph implementation, two additional reference subgraphs and <a href="https://github.com/apollographql/router">Apollo Router</a>.</p>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="534" src="https://wp.apollographql.com/wp-content/uploads/2023/01/image-1024x534.png" alt="" class="wp-image-19311" srcset="https://wp.apollographql.com/wp-content/uploads/2023/01/image-1024x534.png 1024w, https://wp.apollographql.com/wp-content/uploads/2023/01/image-300x156.png 300w, https://wp.apollographql.com/wp-content/uploads/2023/01/image-768x400.png 768w, https://wp.apollographql.com/wp-content/uploads/2023/01/image-1200x625.png 1200w, https://wp.apollographql.com/wp-content/uploads/2023/01/image.png 1230w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /><figcaption class="wp-element-caption">Compatibility Test Supergraph</figcaption></figure>



<p>Based on the test results, we will be able to generate a compatibility report.</p>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="506" height="508" src="https://wp.apollographql.com/wp-content/uploads/2023/01/Screen-Shot-2023-01-11-at-4.20.16-PM.png" alt="" class="wp-image-19295" srcset="https://wp.apollographql.com/wp-content/uploads/2023/01/Screen-Shot-2023-01-11-at-4.20.16-PM.png 506w, https://wp.apollographql.com/wp-content/uploads/2023/01/Screen-Shot-2023-01-11-at-4.20.16-PM-300x300.png 300w, https://wp.apollographql.com/wp-content/uploads/2023/01/Screen-Shot-2023-01-11-at-4.20.16-PM-150x150.png 150w" sizes="auto, (max-width: 506px) 100vw, 506px" /><figcaption class="wp-element-caption">Federation Compatibility Results</figcaption></figure>



<p>For additional details about the reference schema and the executed tests, please refer to our <a href="https://github.com/apollographql/apollo-federation-subgraph-compatibility/blob/main/COMPATIBILITY.md">documentation</a>.</p>



<h2 class="wp-block-heading"><a href="#using-npx-to-run-compatibility-tests-locally" aria-hidden="true" class="aal_anchor" id="using-npx-to-run-compatibility-tests-locally"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Using NPX to run compatibility tests locally</h2>



<p>Apollo Federation subgraph compatibility test script is published as an executable <a href="https://www.npmjs.com/package/@apollo/federation-subgraph-compatibility">NPM package</a> and you can easily execute it by using <a href="https://docs.npmjs.com/cli/v7/commands/npx">NPX</a>.</p>



<pre class="wp-block-prismatic-blocks"><code class="language-shell-session">npx @apollo/federation-subgraph-compatibility --help</code></pre>



<p>When running the script, you have two options in how you can run and manage your test processes&nbsp; &#8211; you can either use <a href="https://pm2.keymetrics.io/">PM2</a> or <a href="https://docs.docker.com/compose/">Docker Compose</a>. If your subgraph is already running, you just need to specify the target endpoint:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-shell-session">npx @apollo/federation-subgraph-compatibility pm2 --endpoint http://localhost:8080/graphql</code></pre>



<p>Otherwise, you can provide a PM2 ecosystem file or Docker Compose file that specifies how to start your application.<br>See our <a href="https://www.npmjs.com/package/@apollo/federation-subgraph-compatibility">script documentation</a> for additional usage information.</p>



<h2 class="wp-block-heading"><a href="#integrating-github-action-to-your-ci-cd-pipeline" aria-hidden="true" class="aal_anchor" id="integrating-github-action-to-your-ci-cd-pipeline"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Integrating Github Action to your CI/CD pipeline</h2>



<p>For your convenience, compatibility tests are also packaged as a <a href="https://github.com/features/actions">Github Action</a>! <a href="https://github.com/apollographql/federation-subgraph-compatibility">apollographql/federation-subgraph-compatibility</a> action uses Docker Compose to run your compatibility tests. Simply add the following step to your workflow file:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-yaml">- uses: apollographql/federation-subgraph-compatibility@v1
  with:
    # [Required] Docker Compose file to start up the subgraph
    compose: &#039;path/to/docker-compose.yaml&#039;
    # [Required] Path to the GraphQL schema file
    schema: &#039;path/to/schema.graphql&#039;
    # GraphQL endpoint path, defaults to &#039;&#039; (empty)
    path: &#039;&#039;
    # GraphQL endpoint HTTP port, defaults to 4001
    port: 4001
    # Turn on debug mode with extra log info
    debug: false
    # Github Token / PAT for submitting PR comments
    token: &#039;&#039;
    # Boolean flag to indicate whether any failing test should fail the script
    failOnWarning: false
    # Boolean flag to indicate whether any failing required functionality test should fail the script
    failOnRequired: false</code></pre>



<p>By default, action will post compatibility results to your job summary and also upload them as a workflow artifact. If you configure action with a Github Token that has PR write permissions, compatibility test action will also be able to post results as comments on your PRs. You can see an example integration in <a href="https://github.com/apollographql/federation-jvm">apollographql/federation-jvm</a> repository (<a href="https://github.com/apollographql/federation-jvm/pull/285#issuecomment-1374047449">example comment</a>).</p>



<p>Please refer to our <a href="https://github.com/marketplace/actions/apollo-federation-subgraph-compatibility">Github Action documentation</a> for additional details.</p>



<h2 class="wp-block-heading"><a href="#updating-subgraph-compatibility-results" aria-hidden="true" class="aal_anchor" id="updating-subgraph-compatibility-results"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Updating Subgraph Compatibility Results</h2>



<p><a href="https://github.com/apollographql/apollo-federation-subgraph-compatibility">@apollographql/apollo-federation-subgraph-compatibility</a> is the source of truth for all the subgraph compatibility results that are displayed on our <a href="https://www.apollographql.com/docs/federation/building-supergraphs/supported-subgraphs">supported subgraphs</a> documentation page. Since we need to be able to reproduce and verify the results, we can only report on the subgraph implementations that are included in the repository.</p>



<p>Once you are happy with the compatibility results, please open up a PR with the same example implementation against our testing repository. Make sure to check out our <a href="https://github.com/apollographql/apollo-federation-subgraph-compatibility/blob/main/SUBGRAPH_GUIDE.md">subgraph contributor guide</a> for additional details. After your PR gets merged, your compatibility results will be displayed on our website.</p>



<h2 class="wp-block-heading"><a href="#conclusion" aria-hidden="true" class="aal_anchor" id="conclusion"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Conclusion</h2>



<p>Apollo Federation Subgraph Compatibility tests allow us to consistently verify Federation support in a target implementation. With the introduction of an executable NPM script and a Github Action we hope to simplify and streamline the development process for all subgraph authors.</p>



<p>Apollo Federation is also constantly evolving! By introducing versioned artifacts, we can now more easily update or introduce new tests to verify new features. Make sure to follow our compatibility testing repository Github releases for latest test updates to the test harness!</p>



<p>We are also open for feedback so please <a href="https://community.apollographql.com/">start a discussion</a>, join our <a href="https://discord.com/invite/graphos">Discord server</a> or raise an issue (<a href="https://github.com/apollographql/apollo-federation-subgraph-compatibility/issues">NPM script</a>, <a href="https://github.com/apollographql/federation-subgraph-compatibility/issues">GH action</a>) for any new features you would like to see!</p>


New Apollo Federation spec compliance tools for GraphQL Server maintainers


<p>How do you debug or optimize a request as it travels through all the layers of your stack: from the client, through the Apollo Gateway, through your subgraph services, all the way to your databases?</p>



<p>First, you need visibility into what your code is doing during that request, regardless of how that work is distributed across machines. Fortunately, this is easier than ever with a Cloud-Native Computing Foundation project called <a href="https://opentelemetry.io/">OpenTelemetry</a>!</p>



<p>As of version 0.31.1, <a href="https://www.apollographql.com/docs/federation/api/apollo-gateway">@apollo/gateway</a> natively supports OpenTelemetry as part of a complete picture of the performance and reliability of a federated GraphQL request. You can find <a href="https://www.apollographql.com/docs/federation/opentelemetry/">the documentation here</a>.</p>



<p>In this article, I’ll cover some OpenTelemetry basics, talk about the new support for OpenTelemetry in Apollo Gateway, and explain how Apollo Studio and OpenTelemetry work together to give you a complete picture of your graph.</p>



<h2 class="wp-block-heading"><a href="#what-is-opentelemetry" aria-hidden="true" class="aal_anchor" id="what-is-opentelemetry"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>What is OpenTelemetry?</h2>



<p>OpenTelemetry (or OTel) is “an observability framework for cloud-native software”. It is a collection of libraries, systems, and applications for instrumenting, collecting, and exporting information about workloads that span multiple applications.</p>



<p>A unit of work in OTel is a “span”. You can wrap a function call in a span, recording its duration and other metadata. You can also install instrumentation that automatically hooks into modules and functions, like the <a href="https://www.npmjs.com/package/@opentelemetry/instrumentation-http">HTTP instrumentation</a> for Node.js.</p>



<p>A collection of related spans is called a “trace”. In a single system, a trace is very similar to a stack trace. But what makes OpenTelemetry (and its predecessors, OpenTracing and OpenCensus) powerful is the ability to correlate spans across systems. It does this by propagating trace identifiers in remote calls. When making HTTP requests, for example, OTel instrumentation adds trace IDs as HTTP headers.</p>



<p>Once you have a trace, you can aggregate them in a “collector” and efficiently send them to your observability tools with an “exporter”.</p>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="605" src="https://wp.apollographql.com/wp-content/uploads/2021/07/OpenTelemetryApolloFederation-1024x605.png" alt="" class="wp-image-8203" srcset="https://wp.apollographql.com/wp-content/uploads/2021/07/OpenTelemetryApolloFederation-1024x605.png 1024w, https://wp.apollographql.com/wp-content/uploads/2021/07/OpenTelemetryApolloFederation-300x177.png 300w, https://wp.apollographql.com/wp-content/uploads/2021/07/OpenTelemetryApolloFederation-768x454.png 768w, https://wp.apollographql.com/wp-content/uploads/2021/07/OpenTelemetryApolloFederation.png 1144w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /><figcaption>A diagram of a request flowing through a federated GraphQL architecture with OpenTelemetry and Apollo traces published to an OTel collector and Apollo Studio, respectively.</figcaption></figure>



<p>There’s obviously a lot more to OpenTelemetry (<a href="https://opentelemetry.io/docs/concepts/what-is-opentelemetry/">see the docs!</a>), but that covers it in the context of Apollo Federation.</p>



<h2 class="wp-block-heading"><a href="#opentelemetry-in-apollo-server-and-apollo-gateway" aria-hidden="true" class="aal_anchor" id="opentelemetry-in-apollo-server-and-apollo-gateway"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>OpenTelemetry in Apollo Server and Apollo Gateway</h2>



<p>Apollo Server has always supported OpenTelemetry via the <a href="https://www.npmjs.com/package/@opentelemetry/instrumentation-graphql">@opentelemetry/instrumentation-graphql</a> library, which instruments the underlying <a href="https://www.npmjs.com/package/graphql">graphql.js</a> library.</p>



<p>However, Apollo Gateway doesn’t use graphql.js to execute a GraphQL request; instead, it executes a “query plan”, coordinating smaller requests to your subgraph services and assembling them into a single response. The Gateway executor has a few phases:</p>



<ul class="wp-block-list"><li>Validation</li><li>Planning</li><li>Execution</li><li>Fetching</li><li>Postprocessing</li></ul>



<p>Apollo Gateway now instruments these phases as spans in an OTel trace. Combined with HTTP instrumentation, which propagates the trace ID as headers in requests to subgraphs, we can now connect the gateway query planning and execution to the actual GraphQL field resolution work in your subgraph services.</p>



<p>Check out our <a href="https://www.apollographql.com/docs/federation/opentelemetry/#1-install-required-libraries">documentation on setting up OpenTelemetry</a> in your Apollo Gateway and Apollo Server apps.</p>



<p>Even if you’re using GraphQL framework other than Apollo Server or a language other than JavaScript, you can still use OTel to instrument your application. There are OTel instrumentation libraries for many other languages and frameworks, and <a href="https://opentelemetry.io/registry/?s=graphql&amp;component=&amp;language=">GraphQL-specific OTel support</a> is small but growing.</p>



<h2 class="wp-block-heading"><a href="#opentelemetry-in-your-infrastructure" aria-hidden="true" class="aal_anchor" id="opentelemetry-in-your-infrastructure"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>OpenTelemetry in your Infrastructure</h2>



<p>Instrumenting a request is cool, but it’s not very useful on its own. You can export traces into many different systems to view, inspect, or search traces.</p>



<p>The open-source projects Zipkin and Prometheus both support OpenTelemetry. Here’s an example of a federated GraphQL request in Zipkin.</p>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="567" src="https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-23-at-9.55.49-AM-1024x567.png" alt="" class="wp-image-8205" srcset="https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-23-at-9.55.49-AM-1024x567.png 1024w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-23-at-9.55.49-AM-300x166.png 300w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-23-at-9.55.49-AM-768x425.png 768w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-23-at-9.55.49-AM-1536x850.png 1536w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-23-at-9.55.49-AM-2048x1134.png 2048w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-23-at-9.55.49-AM-1200x664.png 1200w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-23-at-9.55.49-AM-1980x1096.png 1980w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /><figcaption>A screenshot of a trace in the Zipkin web UI, showing spans for the gateway and multiple subgraphs.</figcaption></figure>



<p>The OpenTelemetry project has a number of exporters for various Application Performance Monitoring (APM) tools, including SaaS products like Datadog and Honeycomb, or cloud provider solutions like AWS X-Ray. You can find a complete list in the <a href="https://opentelemetry.io/registry/?s=&amp;component=exporter&amp;language=">OpenTelemetry Registry</a>.</p>



<h2 class="wp-block-heading"><a href="#opentelemetry-doesnt-replace-apollo-tracing" aria-hidden="true" class="aal_anchor" id="opentelemetry-doesnt-replace-apollo-tracing"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>OpenTelemetry doesn’t replace Apollo Tracing</h2>



<p>OpenTelemetry is great at recording what happened, but it doesn’t tell you much about what <em>could</em> happen. Apollo Studio uses the declarative nature of GraphQL to help you catch potential errors before they happen. Consider this GraphQL operation:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-graphql">query ProductsPage($categoryId: ID!) {
  products(category: $categoryId) {
    nodes {
      sku
      price
      reviews { # could return null
        nodes {
          id
          body
          rating
          author {
            name
            photoUrl 
          }
        }
      }
    }
  }
}</code></pre>



<p>If the <code>Product.reviews</code> field returns null, then the GraphQL executor won’t run resolvers for any of the fields nested inside that selection like <code>Review.id</code>, <code>Review.body</code>, or <code>Author.name</code>. OTel instrumentation won’t record any spans, so you’ll have no data about those fields.</p>



<p>However, if you remove or change the <code>Author.name</code> field, you could break all the clients that include that field in their operations.</p>



<p>We designed <a href="https://www.apollographql.com/docs/federation/metrics/">Apollo Federated Tracing</a> to collect field usage regardless of what actually happens (or doesn’t happen!) in your services. Our tracing data powers the <a href="https://www.apollographql.com/docs/studio/schema-checks/">Schema Checks</a> feature, alerting you of potentially breaking changes and giving you confidence as you evolve your API.</p>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="638" src="https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.53.37-AM-1024x638.png" alt="" class="wp-image-8207" srcset="https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.53.37-AM-1024x638.png 1024w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.53.37-AM-300x187.png 300w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.53.37-AM-768x478.png 768w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.53.37-AM-1536x957.png 1536w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.53.37-AM-2048x1276.png 2048w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.53.37-AM-1200x748.png 1200w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.53.37-AM-1980x1233.png 1980w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /><figcaption>A screenshot of a failed check in Apollo Studio.</figcaption></figure>



<p>Apollo Studio also knows schema-related information like the <code>@deprecated</code> directive, so we can help you understand how clients are using deprecated fields.</p>



<figure class="wp-block-image size-large is-resized"><img loading="lazy" decoding="async" src="https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.50.03-AM-1024x210.png" alt="" class="wp-image-8209" width="610" height="125" srcset="https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.50.03-AM-1024x210.png 1024w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.50.03-AM-300x62.png 300w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.50.03-AM-768x158.png 768w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.50.03-AM-1536x316.png 1536w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.50.03-AM-1200x247.png 1200w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.50.03-AM.png 1732w" sizes="auto, (max-width: 610px) 100vw, 610px" /><figcaption>A screenshot of deprecation information in Apollo Studio.</figcaption></figure>



<p>It’s possible to cross-reference OTel traces and Apollo Studio traces by customizing the <a href="https://www.apollographql.com/docs/apollo-server/api/plugin/usage-reporting/">Usage Reporting plugin</a> in Apollo Server. By passing header values in trace sent to Studio that align with attributes on your OTel spans, you can jump between Studio and your OTel observability tooling to get a complete picture of a request.</p>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="572" src="https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.52.54-AM-1024x572.png" alt="" class="wp-image-8211" srcset="https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.52.54-AM-1024x572.png 1024w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.52.54-AM-300x168.png 300w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.52.54-AM-768x429.png 768w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.52.54-AM-1536x858.png 1536w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.52.54-AM-2048x1144.png 2048w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.52.54-AM-1200x670.png 1200w, https://wp.apollographql.com/wp-content/uploads/2021/07/Screen-Shot-2021-07-22-at-10.52.54-AM-1980x1106.png 1980w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /><figcaption>A screenshot of a trace in Apollo Studio with metadata you can use to associate this request with an OpenTelemetry trace.</figcaption></figure>



<h2 class="wp-block-heading"><a href="#wrapping-up" aria-hidden="true" class="aal_anchor" id="wrapping-up"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Wrapping Up</h2>



<p>OpenTelemetry is a fantastic open-source project and we’re excited to participate in the growing ecosystem. Combined with Apollo Studio, OpenTelemetry gives you a clear picture of your running systems, helping you debug, optimize, and evolve your federated graphs.</p>



<p>Check out the <a href="https://opentelemetry.io/docs/">OpenTelemetry documentation</a> and our <a href="https://www.apollographql.com/docs/federation/opentelemetry/">documentation on instrumenting federated graphs</a>.</p>


Introducing Open Telemetry for Apollo Federation


<p><em>(Editor’s note — the concepts in this post are accurate, but some the code samples don’t demonstrate new usage patterns. After reading, consult the&nbsp;</em><a href="http://dev.apollodata.com/tools/graphql-tools/mocking.html" target="_blank" rel="noreferrer noopener"><em>graphql-tools docs</em></a><em>&nbsp;to see how to use mocking today.)</em></p>



<p>Do you think mocking your backend is always a tedious task? If you do, reading this article will probably change your mind…</p>



<p>Mocking is the practice of creating a fake version of a component, so that you can develop and test other parts of your application independently. Mocking your backend is a great way to quickly build a prototype of your frontend and lets you test your frontend without starting up any servers. API mocking is so useful that&nbsp;<a href="https://www.google.com/?ion=1&amp;espv=2#q=mock+rest+api" target="_blank" rel="noreferrer noopener">a quick Google search</a>&nbsp;will turn up dozens of expensive products and services that promise to help you.</p>



<p>Sadly, I think none of the solutions out there makes it as easy as it should be. As it turns out, that’s because they’ve been trying to do it with the wrong technology!</p>



<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="950" height="724" src="https://apollographql.wpengine.com/wp-content/uploads/2020/03/1_2YJYBlt6h-eSkFdpgBZJTw.jpg" alt="" class="wp-image-164" srcset="https://wp.apollographql.com/wp-content/uploads/2020/03/1_2YJYBlt6h-eSkFdpgBZJTw.jpg 950w, https://wp.apollographql.com/wp-content/uploads/2020/03/1_2YJYBlt6h-eSkFdpgBZJTw-300x229.jpg 300w, https://wp.apollographql.com/wp-content/uploads/2020/03/1_2YJYBlt6h-eSkFdpgBZJTw-768x585.jpg 768w" sizes="auto, (max-width: 950px) 100vw, 950px" /><figcaption>Mocking your backend doesn’t have to be rocket science!</figcaption></figure>



<p>Last week on&nbsp;<a href="https://medium.com/apollo-stack" target="_blank" rel="noreferrer noopener">Building Apollo</a>&nbsp;I wrote about the set of tools that will eventually make up&nbsp;<a href="https://medium.com/apollo-stack/the-apollo-server-bc68762e93b" target="_blank" rel="noreferrer noopener">Apollo Server</a>. Mocking is the first thing we can demo, and I hope you’ll enjoy it!</p>



<hr class="wp-block-separator"/>



<h2 class="wp-block-heading" id="2495"><a href="#why-mock" aria-hidden="true" class="aal_anchor" id="why-mock"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Why mock?</h2>



<p>Mocking the data a backend would return is very useful for two main reasons:</p>



<ol class="wp-block-list"><li>It lets you start developing a frontend feature when you don’t have a working backend for it yet. This is critical for projects where the frontend and backend components are often developed in parallel.</li><li>It lets you run tests locally without connecting to a real backend, which is much faster and safer. As your codebase grows and your app becomes more complex, starting up all of the server infrastructure just to run some tests isn’t feasible.</li></ol>



<p>If mocking your backend API has such clear benefits, why doesn’t everyone do it? I think it often seems like too much trouble to be worth it.</p>



<h3 class="wp-block-heading" id="d4bc"><a href="#why-is-mocking-backends-hard" aria-hidden="true" class="aal_anchor" id="why-is-mocking-backends-hard"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Why is mocking backends hard?</h3>



<p>Let’s say your backend is some REST API that is called over http from the browser. You have someone working on the backend, and someone else working on the frontend.&nbsp;The backend code actually determines the shape of the data returned for each REST endpoint, but mocking has to be done in the frontend code.&nbsp;That means the mocking code will break every time the backend changes, unless both are changed at the same time. What’s worse, if you’re doing your frontend testing against a mock backend that is not up to date with your backend, your tests may pass, but your code won’t work. Rather than having to keep more dependencies up to date, the easy option is to just not mock the REST API, or have the backend be in charge of mocking itself, just so it’s all in one place. That may be easier, but it will also slow you down.</p>



<p>The other reason I often hear for why people don’t mock the backend in their project is because it takes time to set up: first you have to include extra logic in your data fetching layer that lets you turn mocking on and off, and second you have to actually describe what that mock data should like. For any non-trivial API that requires a lot of tedious work.</p>



<p>Both of these reasons for why mocking backends is hard are actually due to the same underlying reason: there is no standard REST API description in machine-consumable format and contains all the information necessary for mocking and can be used by both the backend and the frontend. There are some API description standards, like Swagger, but they don’t contain all of the information you need, are cumbersome to write and maintain. Unless you want to pay a lot of money for a service or a product — and maybe even then — mocking is a lot of work.</p>



<p>Actually, I should say mocking&nbsp;<em>was</em>&nbsp;a lot of work, because something is about to change the way with think of APIs. That something is called GraphQL.</p>



<hr class="wp-block-separator"/>



<h2 class="wp-block-heading" id="8742"><a href="#mocking-is-easy-with-a-type-system" aria-hidden="true" class="aal_anchor" id="mocking-is-easy-with-a-type-system"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Mocking is easy with a type system!</h2>



<p>GraphQL makes mocking easy, because it makes you define a type system for your backend. That type system can be shared between your backend and your frontend, and it contains all the information necessary to make mocking incredibly fast and convenient. You literally have no more excuse not to use mocking in development or testing.</p>



<p>If you don’t know about GraphQL yet, I recommend that you first read&nbsp;<a href="https://medium.com/apollo-stack/the-basics-of-graphql-in-5-links-9e1dc4cac055" target="_blank" rel="noreferrer noopener">an Intro to GraphQL</a>, otherwise the rest of this post might seem a bit like magic.</p>



<p>Here’s how easy it is to start mocking your backend for <strong>any</strong> valid GraphQL query with one of the GraphQL-tools we’ve built for Apollo:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-javascript">// &gt; npm install graphql-tools
import { mockServer } from &#039;graphql-tools&#039;;
import schema from &#039;./mySchema.graphql&#039;;

const myMockServer = mockServer(schema);
myMockServer.query(`{
  allUsers: {
    id
    name
  }
}`);

// returns
// {
//   data: {
//     allUsers:[
//       { id: &#039;ee5ae76d-9b91-4270-a007-fad2054e2e75&#039;, name: &#039;lorem ipsum&#039; },
//       { id: &#039;ca5c182b-99a8-4391-b4b4-4a20bd7cb13a&#039;, name: &#039;quis ut&#039; }
//     ]
//   }
// }</code></pre>



<p>Every GraphQL server needs a schema, so it’s not extra code you need to write just for mocking. And the query is the one your component uses for fetching data, so that’s also not code you write just for mocking. Not counting the import statement, it only took us one line of code to mock the entire backend!</p>



<p>Put that in contrast to most REST APIs out there, where mocking means parsing a URL and returning data in a custom shape for each endpoint. It takes dozens of lines to mock a single endpoint that returns some realistic-looking data. With GraphQL, the shape is encoded in the query, and together with the schema we have enough information to mock the server with a single line of code.</p>



<p>Did I mention that this one line is all you need to return mock data for any valid GraphQL query you could send? Not just&nbsp;<strong>some</strong>&nbsp;valid query,&nbsp;<strong>any</strong>&nbsp;valid query! Pretty cool, right?</p>



<hr class="wp-block-separator"/>



<h2 class="wp-block-heading" id="6842"><a href="#customizing-mock-data" aria-hidden="true" class="aal_anchor" id="customizing-mock-data"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Customizing mock data</h2>



<p>In the example above, the mock server will return completely random IDs and strings every time you query it. When you’ve just started building your app and only want to see if your UI code actually displays something, that’s probably good enough, but as you start to fine-tune your layout, or want to use the mock server to test your component’s logic, you’ll probably need more realistic data.</p>



<p>Luckily, it barely takes any more effort, because customization of mock data is really where the Apollo mocking tool shines. You can customize virtually everything about the mock data that it returns. It lets you do all of the following and more:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-javascript">// customize mocking per type (i.e. Integer, Float, String)
mockServer(schema, {
  Int: () =&gt; 6,
  Float: () =&gt; 22.1,
  String: () =&gt; &#039;Hello&#039;,
});

// customize mocking per field in the schema (i.e. for Person.name and Person.age)
mockServer(schema, {
  Person: () =&gt; ({
    name: casual.name,
    age: () =&gt; casual.integer(0,120),
  })
});

// mock lists of specific or random length( and lists of lists of lists …)
mockServer(schema, {
  Person: () =&gt; {
    // a list of length between 2 and 6
    friends: () =&gt; new MockList([2,6]),
    // a list of three lists of two items: [[1, 1], [2, 2], [3, 3]]
    listOfLists: () =&gt; new MockList(3, () =&gt; new MockList(2)),
  },
});

// customize mocking of a field or type based on the query arguments
mockServer(schema, {
  Person: () =&gt; {
    // the number of friends in the list now depends on numPages
    paginatedFriends: (o, { numPages }) =&gt; new MockList(numPages * PAGE_SIZE),
  },
});

// You can also disable mocking for specific fields, pass through to the backend, etc.</code></pre>



<p>For each type and each field you can provide a function that will be called on to generate mock data. Mock functions on fields have precedence over mock functions on types, but they work together really nicely: The field mock functions only need to describe the properties of the objects that matter to them, type mock functions will fill in the rest.</p>



<p>The mock functions are actually just GraphQL resolve functions in disguise. What that means is that your mocking can do anything that you could do inside a GraphQL resolve function. If you wanted, you could write your entire backend with it. I’m not saying you should, but you could.</p>



<p>I think the real power of this tool is that while it allows almost arbitrarily complex customization, you can get started really quickly and increase the sophistication of your mocks in tiny steps whenever you need it. Each step is so simple that it will feel like a breeze.</p>



<p>But enough talking, here’s a complete example:</p>



<pre class="wp-block-prismatic-blocks"><code class="language-javascript">import { mockServer, MockList } from &#039;graphql-tools&#039;;
import casual from &#039;casual-browserify&#039;;

// The GraphQL schema. Described in more detail here: 
// https://medium.com/apollo-stack/the-apollo-server-bc68762e93b
const schema = `
  type User {
    id: ID!
    name: String
    lists: [List]
  }
  type List {
    id: ID!
    name: String
    owner: User
    incomplete_count: Int
    tasks(completed: Boolean): [Task]
  }
  type Task {
    id: ID!
    text: String
    completed: Boolean
    list: List
  }
  type RootQuery {
    user(id: ID): User
  }
  schema {
    query: RootQuery
  }
`;

// Mock functions are defined per type and return an
// object with some or all of the fields of that type.
// If a field on the object is a function, that function
// will be used to resolve the field if the query requests it.
const server = mockServer(schema, {
  RootQuery: () =&gt; ({
    user: (o, { id }) =&gt; ({ id }),
  }),
  List: () =&gt; ({
    name: () =&gt; casual.word,
    tasks: () =&gt; new MockList(4, (o, { completed }) =&gt; ({ completed })),
  }),
  Task: () =&gt; ({ text: casual.words(10) }),
  User: () =&gt; ({ name: casual.name }),
});

mockServer.query(`
query tasksForUser{
  user(id: 6) {
    id
    name
    lists {
      name
      completeTasks: tasks(completed: true) {
        completed
        text
      }
      incompleteTasks: tasks(completed: false) {
        completed
        text
      }
      anyTasks: tasks {
        completed
        text
      }
    }
  }
}`);</code></pre>



<h2 class="wp-block-heading" id="d3e2"><a href="#live-demo-try-it-yourself" aria-hidden="true" class="aal_anchor" id="live-demo-try-it-yourself"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Live demo + try it yourself</h2>



<p>To see the example in action and see what output it generates, head over to the&nbsp;<a href="http://apollostack.github.io/mock-demo/" target="_blank" rel="noreferrer noopener">live demo</a>&nbsp;and click the “play” button a couple of times!</p>



<p>If you want to fiddle around with the example, you can do that — it’s all on GitHub:&nbsp;<a href="https://github.com/apollostack/mock-demo" target="_blank" rel="noreferrer noopener">apollostack/mock-demo</a>. If you’re curious about how it works or want to see what other tools we’re building for GraphQL, then head over to&nbsp;<a href="https://github.com/apollostack/graphql-tools" target="_blank" rel="noreferrer noopener">apollostack/graphql-tools</a>.</p>



<p>Pretty cool, right? All of that becomes possible by using a type system. And that’s only just the beginning — we‘re working on bridging the gap between mocking and the real thing so that your mock server can gradually turn into your real server as you add more functionality to it.</p>



<hr class="wp-block-separator"/>



<p>If you’ve liked this post, you might also be interested in the other posts on&nbsp;<a href="https://medium.com/apollo-stack" target="_blank" rel="noreferrer noopener">Building Apollo</a>, written by&nbsp;<a href="https://medium.com/u/803918030a60?source=post_page-----692feda6e9cd----------------------" target="_blank" rel="noreferrer noopener">Sashko</a>&nbsp;and myself. We’re publishing two posts every week, about the stuff we’re working on or thinking about.</p>


Backend

New Apollo Federation spec compliance tools for GraphQL Server maintainers

Introducing Open Telemetry for Apollo Federation

Mocking your server with just one line of code

Backend

New Apollo Federation spec compliance tools for GraphQL Server maintainers

Introducing Open Telemetry for Apollo Federation

Mocking your server with just one line of code

Stay in our orbit