My Betty Blocks
My Betty Blocks
Betty Blocks Data API
In this article
Welcome to the documentation of Betty Blocks’ Data API, explaining what it is, why we created it, what it offers you as a builder and how to use it. For each subject discussed, this article will direct to articles diving deeper into it.
Robert van Boesschoten
Last updated: 29-04-2020
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 and executing Login events, you’re entirely in charge of forming your response, collecting 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 too be honest, not that fast. You could also use the 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, which is what we’re all about!
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, `https://api.example.com/users` sends back an overview of all users, while `https://api.example.com/user/3` gives you a single object where its id equals 3. Nice and all, but it doesn’t offer us a way of defining which data of a user we want to return (although some REST API’s do in a tiresome manner).
Now if we could work with a way that ignores the endpoint structure, and just lets us define what data we want, be it users, invoices, products, or whatever. That’s where GraphQL (and in our case the Data API) comes in! Forget about memorizing 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. More on that later!
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 read/collect data (in the form of Queries), and perform a login to authenticate your following requests (in the form of Mutations).
This ties in to the question above. We created the 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 an article that covers that part here!
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!
In this article