Author: Michael Watson, Developer Relations Manager, Apollo GraphQL
Bio: Michael Watson, head of developer relations at Apollo, boasts over 5 years in GraphQL and community engagement. A fervent graph architect, he’s aided numerous enterprises in optimizing their self-service developer portals with GraphQL, particularly for federated architectures.

Innovation drives the success of the platforms and products we build. Enabling your developers to contribute to your platform in a self-service way efficiently is paramount. Developer efficiency initiatives have emerged as a significant trend in the tech industry, aiming to help developers focus on what they’re building, not how to integrate things.

The Evolution of Developer Efficiency Initiatives

As organizations scale, developing features and functionalities becomes more challenging. Navigating these challenges can lead to teams working around obstacles in a silo. The emergence of new platforms like mobile and IoT started to shine a light on these silos as new teams tried to integrate a feature from a website to the new platform. These projects grew in complexity and scale to the point of slowing down developers. Developers were often bogged down by repetitive tasks, inefficient processes, and a need for proper tools, leading to decreased productivity and morale.

As a result, developer efficiency initiatives began to gain traction. Infrastructure teams began to standardize how teams deployed applications and simplified how they created new services. Kubernetes became widespread in standardizing deployments, and DevOps practices began implementing automation tools and improving collaboration for application teams.

We now see the emergence of Platform Engineering start up with the goal of creating self-service developer portals enabling devs to focus on the thing they’re building, not how to integrate with everything else. Cloud Native projects like Backstage, an OSS developer portal, have grown in popularity, similar to how Kubernetes grew. Many of these platform teams focus on how developers can discover and integrate APIs and services built internally. But is discoverability the problem? Or is that the developer experience for implementing the right service is just bad 😖

GraphQL – A Great Developer Experience (DX) for Everyone

GraphQL has always been known for the great developer experience it provides to frontend developers because they can easily get whatever they need from a self-documenting /graphql endpoint. But what about API developers? If you search “GraphQL vs REST”, you’ll find various opinions on what should be used to create APIs. Most platform teams try not to have an opinion on what should be used, instead leaving those decisions to the application teams. In this case, though, every platform team should standardize around GraphQL.

Most platform teams include supporting core APIs that everyone in the organization uses. The teams setup templates that help devs create new services that can utilize these core APIs and provide extensive documentation on how the core APIs can be used. Eventually, the platform team starts getting support tickets that typically show up in two common forms:

1. We need you to add this new field/entity to this APIs response to power our new applications feature
2. The core API isn’t working as expected – our new service is calling multiple endpoints in a way the platform team didn’t expect (please don’t do that 😄)

These requests should be self-service for those teams and they can with GraphQL microservices. GraphQL Federation enables teams to build multiple GraphQL microservices and compose them into a single graph. Frontend teams get the same great DX and backend teams get a great DX for creating new GraphQL APIs.

Platform teams create core GraphQL microservices that expose the domains of the business just like they do today with REST. New GraphQL services can be created that extend the platform teams’ core APIs using metadata in their schema. Adding that new field or entity doesn’t require opening  a support ticket, and these new services are no longer calling the core APIs with some handwritten backend-for-frontend (BFF) code. A graph router can understand all of the GraphQL microservices and generate an intelligent query plan that is optimized based on the incoming request. Everything just works 🙌

Conclusion

Innovation drives success in our products and when developers are more efficient, they can innovate faster. Remember, glue code is not innovation! Self-service developer platforms are big right now, and the standards we pick for the platform will ultimately impact every developer. Picking GraphQL as one of those standards creates a great self-service DX for everyone, backend teams included! A great example is Netflix’s API Team moving from Falcor to Federated GraphQL and migrating the iOS/Android applications with zero downtime 🤩.

Using GraphQL for your self-service developer portal can help your business be more efficient and ship features faster. All while making developers happy and reducing burnout. Work smarter, not harder!

To learn more about Kubernetes and the cloud native ecosystem, join us at KubeCon + CloudNativeCon Europe in Paris from March 19-22.