How Hygraph uses Hygraph III: Content modeling

Building a versatile, scalable and future proof content model and schema design is crucial for your website's data foundation. Before you start, you ideally need to have at least the draft designs of your UI and speak to all stakeholders in the project. You should carefully assess your current and potential future needs. For us this process was a bit less painful, since we already had an existing website and we only needed to improve some areas.

#Content modeling vs. schema design

Content modeling and schema design are very similar concepts, but they serve slightly different purposes. Content modeling is more about the organization of content, defining content types and how they relate to each other. It’s a high level process for content strategy.

Schema design on the other hand, is a lower level process. It defines the precise data structure, field names and types and their relations similar to database design. It focuses more on how the content will be stored and accessed.

#Hygraph components

Hygraph components have been very valuable for us during the development of our schema design.

They significantly simplified the process when we needed reusable templates. You can think of components similar to those in modern web development. They act as reusable templates, allowing you to provide a different content, or a different behavior or look for each instance, much like how the props are used in a UI component.

We created the components and blocks from our design system also in our Hygraph schema. For example, our “Button” component in schema looks like this and it uses the same props as our React component in our design system.

Notice how “variant”, “theme” and “size” fields are enumerations, to pick a value consistently from a predefined set. We can then reuse these components in other components by nesting or in models as fields.

Models are where you store your actual content. They are similar to database tables. You can add fields, create relations between other models etc. If you have blog posts, you would typically create a “Blog Post” model to store your blog posts. You can then decide on the model fields such as title, category, authors and SEO.

#SEO component

Whether you have an eCommerce app, a company website or a personal blog, effective SEO is essential for online visibility. We want to specifically highlight the SEO component we built for the Hygraph website, as it will be particularly valuable for SEO optimizations. We implemented it as a Hygraph component, so that we can add it as a field in any content model we need.

Here’s how our SEO component looks like:

As you can see, it’s a simple yet highly effective component that we incorporate into our content models. We retrieve the SEO data alongside the page data to build an SEO-compliant page. You’re welcome to use this as a foundation for your projects. Naturally, the frontend implementation will vary depending on your chosen library or framework.

#Aligning teams

One of our primary goals was to make sure designers, developers and content editors speak the same language. To begin with, we aligned design and code using the same design system token names both in our Figma designs and codebase.

We continued this approach with components and blocks too. As mentioned in the previous section, we named all components, blocks and their properties the same in designs, in code and in our schema designs in Hygraph. This way when developers are implementing a component or a page, they’d know what properties a component will take or what blocks will be used on a page just by looking at the Figma design.

Similarly, a content editor can easily build the page in Hygraph by selecting the same content blocks as in Figma designs. We have basically adopted all the benefits of the component based approach of modern JavaScript frameworks to Hygraph, thanks to its super versatile data modeling capabilities with basic and modular components support. This has significantly improved the speed at which we release new features and pages, while keeping everything well-organized, easy to scale, and maintain.

#Modular pages

In a marketing department, everything moves very quickly. Oftentimes, content editors want to build and publish new pages quickly. So, we wanted to allow content editors to build and publish landing pages without the need of a developer or a designer.

The solution is, as we call it “Modular Pages”. Modular pages allow content editors to add the prebuilt block components to a page model, add the content and publish when ready.

If we go into implementation details a bit more, here’s how the schema would look like.

A typical website page has sections and each section has one or more block components in it. As you can see, our Page model has a field called “sections” as component field type that accepts multiple “Section” components. Then the “Section” component has a modular component type field called “blocks”. This way we can add multiple sections to a page and each section can contain one or more blocks.

A visual representation of this structure would look like this:

Once you have a schema like this, you can fetch your page data using GraphQL union types and render your page by mapping sections and blocks for each section in your frontend.

#Conclusion

Using all the new Hygraph features along with our design system has made a big difference in how we build our website. It has simplified our workflow, giving our content editors the freedom to create dynamic pages with ease, without compromising the consistency, look and feel. It's been great to see our designers, developers, and content editors all work together more smoothly, speeding up our ability to launch new features and pages.

Looking ahead, we're excited to keep refining our website and sharing more about what we learn along the way. If you're thinking about refreshing your website or creating your own design system, we hope our experience gives you some helpful ideas.