4

The company I work for wants to move from their current CMS (very expensive and developed and maintained by an external company) to a new one, possibly open source or for a lower price.

My colleagues and I are looking at headless CMS and the options on the table, for now, push us to 2 possible solutions: strapi and graphcms

They are both API first CMS, so you create your models with the interface and they expose content through graphql

The problem we see here is that we find it quite hard to apply business logic, for example,

if an article before being published needs to be approved by some superuser or admin, or blocking a subset of the articles only to registered users

We are thinking of using one of these providers and setting up our webserver in front of it that will handle business logic, and external users' log in.

The problem with this setup is that we are adding one round trip to each request.

user <-> webserver <-> headless cms

The user asks for content to the webserver, the webserver retrieves it from the headless scams and runs all sort of authorization/validation checks and in the case gives it back to the user

This also means that we will need to write all of ours graphql queries twice, one for the user exposed frontend and a second version for contacting the headless CMS.

This also feels like we are going to use (whatever the CMSwe choose) as just a container and the value-added, in the end, possibly is just a friendly UI for writing articles/pages/whatsoever

Is our approach to headless CMS wrong?

Improve this question
7
  • Have you considered a server side solution like Gatsby or next ?
    – Esben Skov Pedersen
    Commented Nov 7, 2019 at 17:23
  • They are the presentation layer. We were thinking of using nextjs/react for it, but it seems that with business logic in place an api first headless cms is not the right solution?
    – nicecatch
    Commented Nov 7, 2019 at 17:27
  • It will solve all your auth and deployment issues because it will all be fetched at build time and all that remains is to deploy a bunch of flat files(for gatsby at least). You just need some kind of auto deploy that triggers on changes in cms
    – Esben Skov Pedersen
    Commented Nov 8, 2019 at 5:22
  • How do I handle my business logic, that should be server side, with a static website generator like gatsby?
    – nicecatch
    Commented Nov 8, 2019 at 9:37
  • 1
    Note that, you don't want the client-side application attached to the headless cms API either. It's not convenient given the experience (you are replacing the existing one). Expose your own graphQL API, made on purpose and adapted to your specific domain and needs. This way the next time you change the cms, it takes you to change the adapters between the middleware and the cms, not every single client-side app.
    – Laiv
    Commented Jun 30, 2021 at 15:30

2 Answers 2

Reset to default
2

You're not over-complicating it, this is how headless CMS work once you go from sales pitch to use. Their APIs are not aware of your user model, their rate limits (in case of SaaS) are too low, and the data model that is convenient for content editing is usually not convenient for data retrieval.

Bite the bullet and create your dedicated backend service. Make it cache the data that it collects from the CMS. You can make it a short-lived cache if you serve a lot of traffic or change content often, or you can flush it in response to changes in the CMS. Return the content in a format that will be useful to your frontend. GraphQL is an option if you really like it, but try not to just re-export the CMS data model.

You might find that you can "hide" other data sources behind this new service. You might want some bells and whistles that can tell you (for example) what pages have requested a certain piece of content so you know which caches to flush, or where an editor can preview their changes. But having that layer is the first step.

Improve this answer
1

I don't think Gatsby is the answer to your problems, it sounds like you might want to put an extra layer between your headless CMS and custom webserver that would handle all this extra logic like authorization and so on.

It's extra work but if you have a lot of auxiliary logic and don't want to just consume the CMS API which would be open to the public this is probably the way to go

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.