Squidex appears to be a polished application, but I am unclear on wether it addresses our particular use case. I read through the documentation and looked through code samples and I can’t find where Squidex discusses consuming its content from a static page.
Our specific use case is to replace the built-in CMS system in NopCommerce which is very limited. While it is written in Asp.net Core MVC, it is over engineered in a lot of areas and needlessly extends and overrides classes, making it difficult to integrate it with other CMS platforms. Consequently, the simplest way is to use it’s content management to create base pages and inject content by calling a WebApi returning HTML chunks or loading static HTML pages from a file. I was hoping Squidex provided either of these facilities.
The client examples I’ve seem entail creating another dynamic site for the sole purpose of presenting the content via various platforms. Frankly, this doesn’t appear to be useful as it creates three new problems instead of one. We would have to manage NopCommerce, the Squidex App and the client app in the form of NopCommerce MVC pages or a standalone MVC web app. Moreover, the structure of the data would require ongoing modification of the client app if the content structure changes.
The goal of a CMS is liberate content creation from being a costly and timely technical activity. Perhaps, Squidex is intended to be a highly configurable CMS intended to integrate with other applications than a standalone product on its own. Am I correct here?
Hello,
what I say is very likely true for every Headless CMS. Headless CMS come from the experience that developers made with traditional CMS. When you have a simple website a CMS can handle everything just fine and you don’t need to integrate content. When you have more complex scenarios it becomes difficult. In one of my previous positions I was working for a company like Expedia. We had the search and booking engine and a CMS for landing pages and bringing some content to both systems was a nightmare.
So a Headless CMS tries to solve this problem by providing a system that is easier to integrate. I think the term headless CMS is really bad, but it has its tradition. I prefer to call it content hub, because the main responsibility is to distribute the content. Either by Pull Mechanisms (REST, GRAPHQL) or Push (Rules, Webhooks …). Squidex cannot live alone because it needs at least a frontend. Whether it is a static page or a SPA or so does not really matter. The only difference is when the HTML is created. I guess there are headless CMS systems out there who create HTML snippets but so far Squidex does not do it. In general I think that you have to always adapt your client application when the content changes, because you have at least to update your styling. Of course you can just ignore additional properties when they are not relevant for you.
How you integrate Squidex depends on the application. Lets say you are travel agency. Then hotels are a very essential content type for you. So you would manage that in Squidex so that you can distribute it to the various platforms and then you query the hotels for your landing page where they might look totally different than in your booking process. With GraphQL you can decide which properties you need. For example even the descriptions can be difficult because for your landing pages you need some Google-Friendly descriptions with a lot of keywords and in the booking process you want to have something that works as a good summary for your users.