Content Modeling in Hygraph
Every CMS has its own flavor of content modeling with best practices. Here is what sets Hygraph apart from the other CMSs in the space.
What is Content Modeling?Anchor
Content modeling is the concept of teams building the basic structures for each content model. This structure serves as the backbone for your project enabling teams to be able to easily populate the models with content to fill out the project. Experimenting with and building content models will be one of the first steps when starting a new project or migrating content to Hygraph. Thoughtfully built content models that consider all variables and stakeholders will be a good runway for your entire content team to work efficiently and independently. We take an in-depth look at what content modeling is and how to approach it from a headless CMS perspective in several of our Hygraph Academy pieces which can be a good start if you need to brush up on the fundamentals.
What is special about content modeling in Hygraph?Anchor
Hygraph has several features that are unique in the headless CMS space. This is by no means an extensive list of all of the great elements of content modeling but they do highlight some of the features that really set us apart from other headless CMSs. There are also a lot of exciting things on the roadmap, so consider this a snapshot in time. Our team is working to make Hygraph a highly flexible CMS which gives teams control over exactly how they want to view and use their content. In terms of content modeling, the features that will enable this control are sortable relations, remote fields, and a high powered permission system.
Sortable relations enable greater flexibility for the content editors and developers alike. With Hygraph, developers will model the content to build the basic structure of their schema which can manifest itself in a wide range of ways for the project. They will predefine what elements will be important for that model and the order they should appear in their final form. For clarity and simplicity sake, we’ll say that the content model is going to be a blog post. Typically the structure and order is fixed; however, using sortable relations, content editors are able to adjust the final appearance of the related content.
Developers are able to build a model that has a consistent basic structure and content editors are able to make tailored adjustments without affecting the inherent structure of the model. Practically, this means if editors are working on a blog post and want to change the order of how related content appears on the page or even if the related content should appear on the page it is a simple action. Editors and developers are able to quickly build flexible content using sortable relations giving them unparalleled control. For more insights on how to set up sortable relations, developers can check out our user guides on how to implement sortable relations or our documentation on setting up GraphQL Union Types. Our developer advocate, Jamie, explains how to use sortable relations, also called GraphQL Union Types, in the video below.
The management SDK can help teams take a type safe, programmatic approach to schema changes in their project (if you haven’t had a chance to check it out yet, you can read more about the Management SDK here.) In terms of content modeling specifically, the management SDK can help teams get their projects off the ground quickly. An important step in content modeling is trying out the content models in a real workflow before committing to them with real content. The Management SDK when combined with the existing content and mutation APIs makes it easy for developers to programmatically add content to the schema, saving the team's time. Agencies can leverage the Management SDK for content modeling by creating schema templates that can easily be applied to the relevant client projects that follow a similar project, making manual schema work largely unnecessary. For more information on how to implement the Management SDK into your project, check out our full documentation the Management SDK.
Remote fields can be an essential tool to bring content that lives in other services into Hygraph. We call this concept content federation, where you can easily populate content from existing services into Hygraph, enabling you to have the most current information available in a single GraphQL schema while giving teams the flexibility of a headless CMS. Because the content is being populated from an outside system, when changes occur to this external dataset, they are reflected in Hygraph as well. Gone are the days of having to manually make changes to a data set when the data is updated. Teams are able to build projects with always up-to-date content and connect existing systems to build out more complex, automated systems, unlocking a broad set of new use cases. For example, when building an eCommerce site, teams are able to use remote fields to populate inventory data so that your site always displays the most current information for inventory. To implement remote fields, we have several resources that can help developers use this functionality including a blog post on working with remote fields and documentation outlining how to implement them.
Environments can be a very useful tool for teams working to refine their content models or experiment with entirely new approaches to modeling. In creating a separate environment from the master environment, developers are able to adjust the GraphQL Schema without affecting the production implementation. While Environments are intended strictly for schema experimentation (for building editorial workflows, check out Content Stages, it can be very powerful if a project has outgrown its schema or if teams are looking to refine models after they have seen them in production. To implement a new Environment in a project, developers can reference the full Environments documentation here.
High powered permission systemAnchor
At Hygraph, we make it easy to ensure the right people have access to the right data and can perform only the tasks that they should focus on. As of now, we have customizable roles where teams can ensure that team members who only should access a project’s content, cannot access the schema, and even more granularly, some roles should only be able to edit content but not publish it. These granular permissions can help teams set up workflows and ensure that teams can only make the changes that they should be able to. Our permission system makes it easier to ensure that your projects grow easily without fear of accidentally publishing something before it has been reviewed or inadvertently changing the schema. (On the off chance something does happen though, make sure that you have Versioning enabled to be able to quickly rollback to a previous version.) We are diligently working on making our permission system even more powerful so check back often to see how it develops. (Spoiler alert: in the next year, our permissions will become even more granular.)
How do I get the most out of content modeling with Hygraph?Anchor
To get the most out of content modeling using Hygraph, it is important to invest time at the beginning of your project to educate team members on the new approach to content using a headless CMS and how it can benefit them. Taking this time at the beginning of the process will avoid shortcomings later and will help reorient team members on their expectations. Once the entire team that will work with the CMS from start to finish on the product has a better understanding of the benefits of working with a headless CMS, it will make it easier to justify the time it takes to learn how to use a new tool properly.
Another critical exercise is to create a mock content modeling exercise (we outline how to do this in this post about basics of content modeling) and work through the entire process of creating content for a POC or trial project. This project should be a quick exercise where team members discuss how content should be modeled, what their goal for the project is, and then try it out in the CMS. In trying the new workflows in a low stress, low stakes environment, team members who may be familiar with working only with page builders or other CMSs have a chance to understand how the new system works and answer their questions. While this exercise may seem time consuming, it does wonders for getting the creativity flowing and learning more about how the team’s new workflows will function and what adjustments need to be made. Modular, structured content can unlock a lot of doors for growing teams and established players but it can be a big mental leap if you haven’t had previous exposure to it. Giving team members the preparation they need to make that jump is crucial and will lead to fewer headaches (and a happier team in the long run).
Hygraph has a lot of resources for teams on getting started with content modeling or making the switch from WYSIWYG. These resources can be a great place to start or can give some extra pointers on best practices for onboarding a team to Hygraph. If you have more questions or need some guidance, reach out to our developer advocates on our public slack channel or through our customer success team!
Frequently Asked Questions (FAQ)Anchor
What are sortable relations?Anchor
Sortable relations (also called GraphQL Union Types) are relations where developers are able to build a highly flexible basic model and content editors have the power to make changes to the presentation without changing the inherent structure. Teams can to change the order of specific relations of a content entry right from the UI enabling even more flexibility to how content will appear in its final form. For more on sortable relations, check out our guide on Working with GraphQL Union Types.
What are GraphQL Union Types?Anchor
GraphQL Union Types (also known as Sortable Relations) allow for multiple models to be connected using a single relation. Teams can then choose which model to connect on a given content piece and in what order they would like the multiple models to be displayed. For more on GraphQL Union Types, check out our guide on Working with GraphQL Union Types.
What is flexible content?Anchor
Flexible content is content or content models that can be adapted to serve several purposes using high powered features such as GraphQL Union Types to build flexibility into the structure. Flexible content can be content that is easily adapted from the content perspective to make changes or content that has a flexible structure that can be reused in a variety of use cases.
What is modular content?Anchor
Modular content is content that is structurally broken down into smaller units so that they can be used for a variety of use cases across the project. By using relations to break down content into bite sized models, teams are able to maintain brand consistency, avoid extra work, and make adjustments to language that will be used across the project within a single content model. To learn more about the benefits of modular content, take a look at our Academy page on Structured Content.
What is the Management SDK?Anchor
What are remote fields?Anchor
Remote fields enable data to be sourced from an external third-party web service and other Hygraph Fields as arguments via a custom resolver entry point. Remote fields make it easy to enrich Hygraph projects with external data programmatically. For more information on working with them, check out this post on remote fields
What is content federation?Anchor
Content federation is pulling content from several sources programmatically to enrich your Hygraph data. Content federation reduces architecture complexity, removes redundant copies of data, and enriches content programmatically. With content federation, teams are able to leverage their existing services while modernizing their stacks without a large overhaul. For more on content federation, take a look at our content federation blog post.
What are environments?Anchor
Environments are isolated instances of a project. Using environments teams can make changes to the GraphQL schema and test out new content types without breaking production implementation. Environments are intended for schema building and testing and should not be used as part of the editorial workflow. For more on Hygraph environments, check out our documentation on environments here.