0

I am looking at the advantages of a headless CMS for our static website: managed database, beautiful admin interface w/ complex type definition, presentation layer (i.e. Graph API), asset management and optimisation, to name the most important.

However, our website's content is fairly dynamic: new places are added fairly often, and their intrinsic details (such as address and opening hours) are checked and updated every day, via a cron script. We would also benefit from various analytics on our database, which would be fairly hard to implement via the headless CMS' read API.

Thus, my question is, would a headless CMS be suitable in this situation? If not, would it make sense to have both a "main" database and a headless CMS, synced from the main database, containing only user-facing information? How would one approach this?

There is always the option for implementing everything ourselves; however, I feel this is quite a "regular" workflow and we shouldn't be reinventing the wheel.

linkyndy
  • 17,038
  • 20
  • 114
  • 194

1 Answers1

1

Yes, a headless CMS applies to this type of use case.

It seems that what you are building is somewhat similar to what I described in the Flotiq storelocator tutorial - so you might want to have a look.

In your question you mention 2 important things which have to be called out:

  1. Analytics
  2. Separate databases.

Analytics

It's not a feature that is typically offered in a headless CMS. You will probably need to connect a dedicated analytical engine and so you should be looking for a headless CMS that will make it easy to consume the content in another system. For example - Flotiq does it by exposing all of your content via an OpenAPI compatible API (and GraphQL if you can consume it).

Separate databases

If the main reason to have it is the "fairly dynamic" nature of your content - then I don't think you need it. In many cases people are pairing their headless CMS with static site generators (e.g. Gatsby) and they should also support incremental updates, without the need to rebuild the entire website (which might seem like a problem if your site is large, however from practice I know that rebuilding an entire site with 35k+ pages in Gatsby and Flotiq can take less than 5 minutes).

If, on the other hand, you're considering a separate database because of the need to provide the content to other systems - then you have a couple of options:

  1. Set up automation between your headless CMS and the 2nd data source, most (if not all) headless CMS would have a webhooks feature that will allow you to send events to other systems when data changes.
  2. Skip the 2nd database and choose a headless CMS that has an API that can be used to easily share the content, with the wide proliferation of OpenAPI in enterprise systems - it seems that Flotiq would be a good choice.
  3. Use tools like Zapier or Power Platform to setup a data integration between your systems.

Disclaimer - as you might've guessed - I work with Flotiq.

andrzejwp
  • 922
  • 4
  • 11
  • Thank you for your detailed answer. It does feel like you're describing the same decisions (or compromises) I outlined in my question. Having the CMS' database as the source of truth, or having a sync system set up are both fairly big compromises, and I would love to learn how others have approached this problem in the real world, with some concrete projects. By the way, with "fairly dynamic" I meant often-changing data, usually fetched from external services on a regular basis (such as opening hours for places). – linkyndy Jan 17 '22 at 11:43
  • Why do you consider having the data in the CMS as a compromise? – andrzejwp Jan 17 '22 at 13:17
  • Because serving it for various clients is just one use-case. The other being analytics, more complex integrations with backend scripts etc. – linkyndy Jan 17 '22 at 23:16
  • Yes, but I believe with any kind of database you would use - you will still need to write some custom logic / scripts on the backend. The difference is - instead of connecting directly to the DB - you would be working with the CMS API. For the analytics part - depending on what kind of calculations you would be making - you could either operate on the real data (e.g. using GraphQL API of the cms), on a copy of the data stored in a different DB (if - for some reason - it's easier to work with) OR work on aggregated data (e.g. sent via webhooks). [continued] – andrzejwp Jan 18 '22 at 11:19
  • Again - you would see similar patterns in the more "traditional" systems. I might be able to provide some examples if you can describe your analytics and backend scripting use cases in a bit more detail :) – andrzejwp Jan 18 '22 at 11:23
  • I see the presentational layer (i.e. the static website built from the headless CMS' data) just as a part of a bigger data store, thus it feels strange at least to have the main data source inside it. Running a cron based on a query and updating meta information (such as opening hours) doesn't feel it belongs to a data store linked to the presentational layer. That is my main concern. – linkyndy Jan 18 '22 at 14:07
  • But if you think about it differently - that the headless CMS is *just* the data store, not much more than a database, then maybe it will make more sense? The entire idea of headless CMSs is to separate the content (data) from the presentation layer, and thanks to that - to reuse and utilise that content where it would be otherwise impossible. So - don't necessarily think that the data is linked to the presentation, not with a pure headless CMS. – andrzejwp Jan 18 '22 at 17:14
  • That's a fair point. Thanks for your input! I will leave this open for a bit more, see other perspectives as well. – linkyndy Jan 19 '22 at 19:41