Sridhar Rajagopalan
Sridhar Rajagopalan is a cofounder and StepZen’s CTO and engineering lead. Sridhar was a senior Site Reliability Engineer (SRE) at Google, combining software and systems engineering skills to help build and run large-scale, massively distributed systems.

With GraphQL, you can package and integrate all of your data and APIs behind a well understood and easy-to-use model. As a GraphQL consumer, you can do the things that you want and avoid the things that you do not want to deal with. For example, when consuming a GraphQL API, you write less code to perform frontend functions, fetch less data (and so lower your costs), experience faster load times, avoid version control pain, and much more.

However, one of the really hard things that still needs doing is building and running a server to host your API. Choosing to own and operate that GraphQL service is not trivial. How can the developer get all the goodness of a GraphQL API and leave behind the big hairy problems? How do you get the sweet banana you want without having to adopt, care and feed for the gorilla that’s holding it?

What Could Possibly Go Wrong?

Anant Jhingran
Anant is the founder and CEO of StepZen — a startup with a new approach for simplifying how developers access the data they need to power digital experiences. With a career that spans IBM Fellow, CTO of IBM’s Information Management Division, CTO of Apigee, and product leader at Google Cloud, Anant has spent his career at the forefront of innovation in databases, machine learning, and APIs. At StepZen, Anant is enjoying creating a company that brings his love of these technologies together to simplify, accelerate and scale front-end development.

Why not build and run a server to host your API? Well, there are a number of things that you do not want to deal with.

  • Something that was working yesterday stops working today. Is it because the backend response changed? Are your keys no longer valid? Is the backend down? Is some data element malformed? Did your latest version of the GraphQL endpoint have some incorrect code in it?
  • Something that was performant yesterday is no longer so. Should you add a cache? But now, when do you go to the cache as opposed to the backend? Or did someone drop an index on a backend database that you were depending on?
  • Your GraphQL endpoint needs access control, because the queries are being issued directly from the browser. So now you need to tie in your API keys with GraphQL execution, and deploy a server to authenticate API requests, restrict access to legitimate users, and ensure that malicious GraphQL calls do not reach your backend.
  • You have to balance rate limits between incoming calls and outgoing calls, and you have to still deliver the results in the 800 msec. the GraphQL layer has.
Read More:   Swimm Helps New Dev Hires Stay Afloat with Continuous Documentation – InApps 2022

None of these problems are unsolvable. But there is a lot of code to write, and a lot of code to maintain and improve upon. For every new backend you add, you must add retry logic, error handling logic, caching logic, throttling logic, API key invalidation, response change validation, and a whole lot more. Your code, which started off with some clean JavaScript fetches, quickly morphs into a monstrosity. Worse still, you have to deploy, run and manage all that code.

Strategies for Addressing the Hard Things

What could a service that takes care of all of the hard things of building, managing and running your GraphQL do?

  1. It would monitor the common and uncommon backends and know about response changes, API changes, APIKey invalidity, performance degradations — so that you do not have to. Outside a very small fraction of APIs that only you use, someone else has very likely encountered that problem before you.
  2. It would apply machine learning at scale to optimize and route around errors, as well as to automate structure and protocol translations.
  3. It would leverage cost based optimizations (just like Google’s service leverages website performance in its ranking) and smart caching to do the right tradeoff between performance and accuracy.
  4. It would reduce friction by eliminating API key contracts for common backends, and managing rate limits appropriately.
  5. It would eliminate the need for any server to be run by a developer. Make it so that nothing comes between the browser and the GraphQL server — for protecting keys, for access control, and for mashing and mixing and matching. This is particularly attractive in helping deliver on the promise of modern architectural paradigms, like Jamstack.

Towards a Future as-a-Service

Search was an early and perhaps the most prominent as-a-service model to emerge in the past couple of decades. Databases are still available as software, but the popularity and success of services like Snowflake and BigQuery are showing that as-a-service is gaining considerable traction in the database market. We are seeing the same trend play out in other markets, for example, Infrastructure-as-a-service. So why are these “as-a-service” models winning across technologies? Automation at scale, leveraging machine learning, common runbooks, and economic efficiencies are making a huge difference across the stack. In the world of GraphQL, the same set of principles leads to execution optimization, auto-mapping, caching, and monitoring of thousands of common APIs — all contributing to a more efficient developer experience.

Developers who take on running and managing their own GraphQL servers miss out on these many technological advances that can make their app development faster and more productive.

Feature image via Pixabay.