WHAT YOU'LL LEARN
- Features, capabilities and, common use-cases of Webiny’s Headless CMS.
Webiny’s Headless CMS is powered by a GraphQL API. It comes with 3 different API endpoints, and it’s a highly scalable, performant, and cost-effective solution.
Checkout the performance benchmark.
You can use It to power backends for business applications, mobile apps and to manage data for a website, like blogs or eCommerce stores.
Headless CMS is packed with many features that make it a powerful tool anytime you need to quickly create a new API. Let’s explore some of its main features.
Under the term “content model” we refer to an entity that consists of one or more attributes. A typical content model would be a blog post. That content model would contain attributes such as title, slug, featured image, tags, category, and a body.
Each attribute can be of a different type. The included types are:
- a single-line text input or a multi-entry input
- can also be a list of predefined values the user can select
- A integer or a float
- Multi-line text
- Doesn’t support text formatting
- Rich text
- A multi-line rich text field that supports text formatting and inline images
- True or false toggle
- Used for inserting a single file, multiple files, a single image or an image gallery
- Referencing another content model
- Supports both single entries and multiple select
Besides the default built-in attributes, you can expand Webiny with custom plugins that introduce new fields.
Checkout the tutorial on Creating a Webiny Headless CMS address field plugin.
On each of the attributes, you can attach validators. This allows you to define which fields are required and what values, or patterns, of values a field can take.
GraphQL API endpoints
The Headless CMS has 3 APIs which are expanded dynamically every time you create a new content model. Depending on what you want to do, you will use a different endpoint:
- Manage API endpoint
- This is the main endpoint, it gives you access to create, delete, publish, unpublish and many other read and write operations.
- Read API endpoint
- Only has queries to read data. It can only read data that is published.
- Preview API endpoint
- Similarly to the Read API, with the exception that it returns the latest version of the content, regardless if the latest version is published or not.
You can explore the queries and mutations available under each of the APIs inside the Admin Panel by accessing the API Playground from the main menu.
From the security module in the main menu, you can control the access levels for both user groups as well as API tokens.
For the Headless CMS, the security implementation allows you to define access to the content. You can limit access to a particular content model or a content model group. Within that, you can control what operations are allowed. Is it ready-only access, or can the content be manipulated. And then which content is in the scope of that operation, is it only the content the user previously created himself, or all the content. This fine-grain control allows you to fully tweak the access levels to meet your business requirements.
When it comes to API tokens, you can also limit them to a particular endpoint alongside all the above-mentioned options.
All apps inside Webiny are multi-language. The multi-language implementation is done in a way that each language is fully independent in terms of content and content models. This approach is the most flexible in terms of what you can do with it as each language can have a completely different content and structure. The tradeoff is that in some cases there will be some manual coding required say if you are reading an article in German and you want to switch to the same article in English. This switching logic and linking the German and English entry would be up to you to implement.
There are 2 main operations that you can do on the Headless CMS which will define your scale factors. First is the write operation on the Manage API. These operations trigger a lambda function which then writes a record into DynamoDB. As you can imagine, this flow can easily handle thousands of requests per second. The data from DynamoDB is then written in batches into Elasticsearch service via a DynamoDB stream.
The second operation is the read operation, which comes when you interact with the Read or the Preview API. In this case, it’s a Lambda function that interacts with Elasticsearch, there is no DynamoDB.
The only time when Webiny uses DynamoDB to fetch items from the database is when you are requesting a particular item via the primary key.
The data inside the Elasticsearch service is stored so it can be quickly retrieved, no matter if there are filters and sorters applied. This includes also all the linked references. The scale factor here depends on the size of your Elasticsearch instance. This is the only “non-serverless” component Webiny uses so you need to think about sizing in advance.
For an in-depth performance benchmark checkout the performance benchmark.
Here are some key differentiators for when you should consider using Webiny’s Headless CMS:
- Data ownership
- In both the open-source and the enterprise edition, Webiny is self-hosted. So if you need a highly scalable headless CMS solution, but don’t want to spend a lot of resources on managing and scaling infrastructure, Webiny is a great option.
- Headless CMS can be fully tailor-made to your requirements. Being open-source you have full control over the code which you can modify to your needs.
- All of the infrastructure components Webiny uses, besides Elasticsearch, have consumption-based pricing, they scale automatically and require zero maintenance. Serverless in practice lowers infrastructure costs by 60-80% and maintenance costs by 60%.
- With Webiny there is almost no need to reconfigure and redesign your infrastructure as your demand grows or shrinks. It’s a solution that you can use to start serving 100 users a day and the next day scale to handle over 10 million users a day or more.