Ive been working with DatoCMS for a little while now, and Im loving it so far. However, I feel like there might be some room for improvement in how I am setting up my content models. I have got a few complex models that Iām sure could be optimized better, especially when it comes to relationships and field types.
For those of you who have been using DatoCMS for a while, do you have any tips or best practices for optimizing content models? How do you approach setting up relationships between models, and are there any common pitfalls to avoid?
First, aside from the developer documentation (which you linked to), have you also seen our editor user guides? That goes into a lot more detail about modeling: How to DatoCMS ā DatoCMS. You can also take a look at some of our example starter projects, which have one-click quickstarts, to see how theyāre modeled in DatoCMS and how that links to the frontend: Project starters - Free demo projects - Marketplace
Beyond that, weāre happy to suggest some schemas for your individual use case, but I wouldnāt say thereās necessarily a ābestā way to model any given content. It really depends on what youāre modeling and what sorts of lookups you want to be able to do on that content afterward. Half the fun of setting up a new CMS is the trial and errorlucky guesses, I mean, totally measured and reasoned approach to setting up the schema Seriously though, itās usually a bit of significant back and forths before you get it right at first, with more minor changes later on.
It helps to not spend too much time putting in real content right off the bat, but rather, using dummy content (just one or two of each category/model) to make sure the schema makes sense before you start adding all the real stuff.
What are you trying to model? A blog site would be different from a restaurant menu would be different from a parts catalog, for example. Is there a certain project youāve already set up (or want to set up)? Happy to take a look there if you want to share the URL (or just some details) with us?
In general, I would usually start just by brainstorming through the project, and maybe drawing a rough outline / Venn diagram / relationships table on a whiteboard or piece of paper. Letās use a simple product site as an example:
First, what will the user (website visitor) see on the website? Maybe a home page, some blog posts, product and pricing details, an āAbout the teamā section, etc.
Some of those are relatively unique pages that have their own layout and such: The home page, pricing page, about the product. Those can be single-instance models, and may be easier to set up because thereās fewer relationships.
Other content types, like blog posts or āabout usā sections, might be collections of individual units of content. Each individual blog post might be its own āPostā model, for example, linked to one or more āAuthorsā. But the actual āBlogā index page might be its own single-instance model, with a field for a title, a introductory paragraph, and maybe an editor-curated multi-link field to the top 3 featured blog posts. (And your frontend would fetch the rest of them by date, or whatever).
Similarly, the āAuthorsā could be in a āPeopleā model, with a name, profile pic, title, maybe a brief blurb. Those same people could be used as both blog post authors and team members in the āabout usā section.
Then you get to some of the nitty-gritty stuff, like Blocks. A block is just a set of repeatable, reusable fields. For example, you might want a āPricingā block that includes fields like name, description, monthly pricing, annual pricing, etc. Then you can use several of those blocks next to each other to show your different plan types.
Once you have all this set up, youād use a combination of different GraphQL queries and filters to fetch just what you needed on each page of your frontend.
Thatās just a basic example If you have more details youād like to share with us, or a project URL we can take a look at, we can take a deeper look and suggest something more personalized, perhaps?
Seriously though, itās usually a bit of significant back and forths before you get it right at first, with more minor changes later on.
If you have more details youād like to share with us, or a project URL we can take a look at, we can take a deeper look and suggest something more personalized, perhaps?