Architecture, Hosting, and Infrastructure

Where is GraphCMS being hosted?

Our servers, Amazon’s AWS and Google Cloud, are deployed on three continents for best performance and reliability (Europe/EU (Ireland, Germany), US East (Virginia), US West (Oregon), Asia (Japan)).

Which databases does GraphCMS use?

AWS Aurora MySQL is used for the Project APIs of your projects and Google PostgreSQL for your Management API.

Is the GraphCMS architecture horizontally scalable?

Yes, we have a modern and scalable architecture based on Kubernetes and scalable databases such as AWS Aurora and Postgres.

Is GraphCMS multi-tenant?

Yes, this is possible with cloning. We support hosting in four regions out of the box (Europe/EU (Ireland, Germany), US East (Virginia), US West (Oregon), Asia (Japan)). More regions are available with dedicated infrastructure.

Is the storage size or the number of entries and records in a GraphCMS project limited?

There are no limits on storage or project entries and records.

What are the GraphCMS latency metrics?

Latency depends on your location, the location of your users, and the complexity of your GraphQL queries. We aim for a latency of maximum 70-100 ms for requests.

How are media assets hosted and delivered with GraphCMS?

Media assets are delivered via our asset management provider Filestack and the content distribution network Fastly (CDN).

Where are my application files (e.g. html and javascript) hosted?

Your application files are entirely in your control. The GraphCMS API is used for delivering content, compatible services like Netlify or Zeit are used for hosting the application files.

Do you have any more information on your plans to open source your software?

We are starting to open source our content management interface (the web application you see when you log into GraphCMS). This will allow our community to build customized editors and extensions. Our goal is to have this code available by Q2 of 2020.

Regarding the open sourcing I think there are a few key things to keep in mind when people ask about it. First off is that *only* the frontend part of our product is going open source. The entire API layer stays closed source with us. This means that it will not be possible to add custom data types, change the API behavior, self-host the backend, implement custom roles, add your own user authorization and so on and so forth.

Core benefits for having the open source web app from the user perspective would be:

  • Customizing web app’s branding and styles (mainly targeted for digital agencies I would say)
  • Allowing people to change how their data is getting previewed within the content table with custom renderers
  • Interface translation
What does GraphCMS use for monitoring & regression testing its GraphQL servers?

We have different testing strategies to avoid regressions. It is a mix of unit testing and integration tests. We also periodically run automated tests against canary deployments before releasing new features, to ensure we don’t introduce regressions. Regarding monitoring we use Istio (Prometheus) for monitoring low level metrics (like resources as CPI, memory, networks throughput etc) + Apollo Engine for our management server, which is used by the web app (e.g. to create a project, create a model etc).

What is your GraphQL caching strategy?

GraphCMS uses the default by id apollo caching strategy for the majority of the webapp. The exception being content queries which can change so dynamically that Urql is used to handle/cache them and invalidate everything when the content data changes.