Welcome to the documentation of Betty Blocks’ Data API, explaining what it is, why we created it, what it offers for you as a builder and how to use it.

The Data API is developed as additional technique on top of existing features to provide a faster, more efficient and more versatile way of collecting and serving data. Focussing primarily on reading data, mutating data, and executing login events, you’re entirely in charge of forming your response, collecting or mutating only the data you need.

Previously, to access data from your Betty Blocks application outside of the Back Office, you’d need to write your custom endpoints using Liquid. Liquid is a templating language to render variables, and to be honest, not that fast. You could also use the Betty Blocks REST API, but this doesn’t offer that much flexibility.

With GraphQL as the backbone of our new Data API, developers can easily set up custom requests. Besides that, it’s blazing fast! The Platform's Page Builder uses the Data API by default.

The idea behind REST API’s is that they work in a structured way by offering a set of endpoints, each with its own payload to send back after executing a request. For example, an api called https://api.example.com/users for returning an overview of all users, or an api https://api.example.com/user/3 that results in a single object where its id equals 3.

However, we can improve the process by working in a way that ignores the endpoint structure, and just lets us define what data we want, be it users, invoices, products, or whatever. This is where GraphQL (and in our case the Data API) comes into use. It removes the need to memorize an ever-growing list of endpoints, each with own rules. Using GraphQL, there’s just one endpoint to remember and accepts all your requests in the form of a Query. What makes this even easier, GraphQL tooling offers an overview of all possible queries while building it, so you know immediately what you’ll need to do.

We already covered this a bit in the part above, but to really look into the exact advantages, we’ll need to look at the parts of the platform you’re going to use this. It also depends on your user profile; are you a starting Citizen Developer tinkering with some basic stuff, or a seasoned Pro-Coder looking for that extra edge to lift your application to the next level? Keep reading to find your answers.

The Data API is used as a technique to collect data (in the form of Queries), to mutate data, and to handle authentication events for login purposes (in the form of Mutations).

This ties in to the question above. We created the Data API to serve data for the Page Builder, so that’s where the majority of options are available. Whether it’s the default component set you’re using, or you’re building your own components through the CLI, the Data API collects your data.

This means collecting data through variables (as you may know from the previous UI Builder and in custom endpoints) is no longer the way to do this. Each component using data for its content executes a client-side request to collect data, as opposed to a serverside request when rendering the variable. This is what makes the new setup faster and more efficient, both platform-wise, as experienced by users.

As we’ve mentioned before, GraphQL tooling offers a clear overview of all possible queries for your data. One of these tools is called the GraphQL Playground. Instead of getting into that here, we created this article that covers that part here!

This article also covers some of the limits that apply to data API queries, so give it a careful read.

With the information given here, you have a basic understanding of the Data API and it’s time to start working with it! Take a look at the other articles covering the subjects and start querying!

➝ Next article: Getting started with the Data API