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 to be done is building and running a server to host your API. Choosing to own and operate that GraphQL service is not trivial.

Software as a Service (SaaS) is a hot topic. As the adoption of cloud computing increases, it is largely developers who are driving a shift to cloud and SaaS as solutions to their day-to-day operational issues. From evangelizing iterative design-develop-deploy and agile development methodologies to championing DevOps as a solution to the need for speed in deployments, they are driving the adoption of cloud and SaaS in companies big and small.

But what are developers considering when deciding if they should run their GraphQL API or leverage a SaaS service? Questions they ask include:

• Can I effectively monitor backends and know about response changes, API changes, API key invalidity, performance degradations?
• Can I scale to optimize my applications and route around errors?
• How effectively and efficiently can I handle structure and protocol translations?
• Do I know how to design caching and make the best tradeoffs between performance and accuracy?
• Can I handle API keys, access control, and managing rate limits and SLAs effectively?
• Can I write and maintain the code for every additional backend that requires new retry logic, error handling logic, caching logic, throttling logic, API key invalidation, response change validation?

In Why You Shouldn’t Host Your Own GraphQL API, originally published on The New Stack, we explored some considerations that developers should keep in mind when deciding between hosting their GraphQL API or choosing a service to do so. See the full article here.