TL;DR Up until now we’ve focused on making DatoCMS the best tool to manage content for static websites. With the release of our new Content Delivery API we are expanding the context of use of DatoCMS to apps of any kind: server-side, client-side, mobile, VR, smart-watches… well, you get the idea.
Try one of our demos and see how easy it is to use DatoCMS with your favourite framework/language!
A bit of history
DatoCMS was born two years ago — in the most classical scratch-your-own-itch approach — as a tool to solve the need internal to our web-agency of having a simple, agile and cost-effective CMS to manage content for the (static) sites we built for our clients. Being the best possible solution to build static websites has been our top priority since day one.
We never wanted to lock our users into a specific stack, so early on we made available integrations with all the most popular static website generators (Gatsby, Middleman, Jekyll, etc) and continuous integration platforms (Netlify, TravisCI, CircleCI, etc).
It has been a constant surprise realising how many other people actually suffered the same itch we had and see how satisfied they were by the opinionated choices we took when developing DatoCMS.
Today our product is used on a daily basis by thousands of agencies, freelancers and companies of any size to manage the content of static websites, and we’re super-happy to notice the heterogeneity of the stack each one of our clients chose.
“…but why just static websites? :/”
During the last six months, we started noticing a recurring pattern in the questions our potential customers asked us in our support channels. They were all along these lines:
“I understand that DatoCMS is only meant to be used with static websites… why is that, if it’s an API-based CMS?”
“What’s preventing me to use it in the context of a React application, or to manage editorial content of my PHP website with DatoCMS?”
The reality is that we weren’t missing much, in terms of features… our product was more than ready to handle content for pretty much any kind of application. We just had an API that was optimised for static websites, which by their nature need to:
fetch a lot of data (basically ALL the content stored within a project);
and fetch it very infrequently (not for every visit, but only during the build process of the static website).
While other use cases — ie. a web/mobile apps — have almost exactly the opposite requirements:
fetch just the minimum amount of data required to show a specific view (ie. a blog post detail page);
perform the minimum number of HTTP requests to optimise roundtrip times;
fetch this data for EVERY visit the website receives.
Introducing the new Content Delivery API
Today we’re officially releasing our new Content Delivery API to the general public, which is meant to finally solve this problem, and enable the use of DatoCMS for apps and media of any kind.
Our old REST API is still alive and kicking and has been renamed as the Content Management API, however, it is highly recommended that you always use the new Content Delivery API to deliver content to your public-facing web or mobile projects.
CDN
The new APIs serves content via a powerful and robust content delivery network (CDN). Multiple datacenters around the world store a cached copy of your content. When a page request is made, the content is delivered to the user from the nearest server. This greatly accelerates content delivery and reduces latency.
GraphQL
In addition to that, this new API is written in GraphQL, which offers a number of advantages over classic REST APIs:
Strongly typed schema
Many developers have found themselves in situations where they needed to work with deprecated API documentation, lacking proper ways of knowing what operations are supported by an API and how to use them. GraphQL clearly defines the operations supported by the API, including input arguments and possible responses, offering an unfailing contract that specifies the capabilities of an API.
No more over-fetching and under-fetching
Developers often describe the major benefit of GraphQL as the fact that clients can retrieve exactly the data they need from the API. They don’t have to rely on REST endpoints that return predefined and fixed data structures. Instead, the client can dictate the shape of the response objects returned by the API.
Fewer roundtrips
One of the major issues of REST is that, in order to get the data you need, you are forced to call a number of different endpoints. Each API request to pull a resource is a separate HTTP request-response cycle. Fetching complicated data requires multiple round-trips between the client and server to render even a single view. On the contrary, GraphQL enables you to call several related functions without multiple round-trips.
It’s just the beginning
In the next weeks we’ll keep on refining our GraphQL API based on your feedback and use cases, so please participate in the open discussion on our Slack channel. We’re already working on some single-page-application demos in React/Angular/Vue.js, so expect them to be online real soon.
So... yeah, that’s a pretty big shift in perspective for us, and we hope for all of you as well. We REALLY can't wait to see what you guys will create with it 🙂