Strapi – Open-source Node.js Headless CMS
strapi.io
strapi.io
It's now 2x red flags for me. Bye.
1. CMS experience for non-technical teams: marketing, product, content, etc. 2. Graphql api to avoid lock-in. Tomorrow you can take your data to AWS Appsync, etc 3. Ownership of the data: Contentful, Prismic, etc are great - but Strapi allows you to own the data. Even in its simplest form, its a sqlite file you can check in to git.
Do non technical teams know or care about Graphql Api ? As someone who works for non-technical teams-- they only care about getting their job work done with the least amount of friction. These teams end up on Wordpress for the simple reason that they can to to themeforest, pick a theme and say this is what they want their site to look like.
If you can convince the tech team to build your entire infrastructure on Wordpress/php...then great, go for it. But most likely the rest of your app is built in different languages.
So a "headless CMS" like Strapi gives a brilliant CMS experience and exposes the content as a graphql api. To be fair, you can achieve that in Wordpress as well - https://www.wpgraphql.com/. But I suspect that most engineering will be happier to touch a reactjs based product versus a PHP based.
Yes, you can. But it feels, acts and works exactly like the thing it is: a hack held together with ducttape and prayers.
This is not a diss to WordPress or to the wpgraphql community: they do great work. But comes from experience at running a WP hosting company (and solving all sorts of WP issues). WP was designed as a blogging tool. This shows, because everything you make it do that is not blogging is clumsy and hackish at best, and very insecure/unstable/buggy at worst. The further you go from "a blog" the worst this gets.
Turning WP into a headless API-backend is such a thing: WP was never designed for this and it shows.
I'm surprised to hear someone who has run a WP hosting company say that using WP for anything other than a blog is "clumsy and hackish at best". I've also run a WP hosting company and would suggest otherwise
Here's what WP is particularly bad at:
* Anything "user generated" where "users" are not part of a trusted group of editors. Even the feature "comments" that has been in WP since the very start breaks down very quickly and is extremely tough to manage, tune, or moderate.
* Anything that is highly dynamical, such as popularity counters, voting, threads (see above) or any other UGC (see above) breaks immediately with any kind of load b/c all performance optimisation in WP evolves around caching. Which is a good strategy for a publishing platform.
* Anything that has workflows or requires state for visitors. e-commerce, payments, sign-in, etc. Hampered by the limited abilities to tune performance (see above) but mostly hampered because WP has no framework or tooling built in to manage "state", build "state machines" and so on. Other than "just cram it in cookies", but that is no state-management. I've seen WP cookies nearing 0.1MB being passed over the line for every request "the site is getting slow, I hear", said the client. Well.... sure!
* Anything that requires async processing. Tucking wp-cli into a cron-job works but is clumsy and fragile. Spawning workers, jobs, events or anything else is lacking in tooling. You probably don't need this, but when you do, WP is your enemy.
So, sure, WP is really neat when you have a known, or dedicated team of publishers and authors that write stuff, which is then read by visitors. For this model (which I call "the blog") it is very well attuned, especially if you keep it at those generics. Especially when such teams work on many different such "editorial sites" at once: the familiarity of WP then helps a lot.
But in most other cases there are either far better suited publishing platforms attuned for your exact needs and niche. Or there are frameworks that let you build such an attuned system far easier than through "WordPress Development".
Sounds to me like you already made a good case for why those products exist.
Sure, you could also call HTML structured content, but using HTML for expressing the semantics of the content instead of the presentation has always been a bit of a pain. Plus you wouldn't really want to use HTML as a format to share this kind of data with for example mobile applications.
You could use XML, but I'd say that's basically the same as JSON with a fixed schema but with more angle brackets, which is pretty much what those headless CMSs return.
Then on top you need the devs to build the server, and to maintain the DB, to add a querying API, to add SDKs and tooling that enable smooth integrations with the new API, the workflows on top of the pure content, a UI that is intuitive to the people maintaining the content, security audits, scalability for when more parts of the company want to use your tooling etc etc.
Following your reasoning you could also say "Payment provider" is a marketing term for something that is just a DB that needs to sync with some banking APIs and AWS is just APIs in front of some DBs and VMs and analytics solutions are just a JS SDK on top of some DB.
Fundamentally everything we build is just some kind of frontend or abstraction on top of a DB. I don't see how that makes it in any way pointless.
so you can move from AWS AppSync to Strapi to Graphcms without changing your code. As long as an infrastructure implements the Graphql api standard, your code will work without changes.
1. Define a schema in an admin panel.
2. Get a free REST or GraphQL API for CRUD operations and a nice role based UI to manage the data.
- Hasura doesn't provide an admin interface. It's just supposed to be a backend, not a CMS.
- Strapi doesn't have a mechanism for sending events to the client, although it seems GraphQL subscriptions are in their roadmap.
- Strapi doesn't seem to have a way to do aggregations. The only aggregation I see is "count", and it seems that is there for pagination, which makes sense for their intended audience.
- While Strapi has simple filters, you can't do more complicated logic by using "and" and "or". You have to write a custom query using the ORM they use. Hasura allows clients to make such queries with no changes to the backend.
There is overlap between their functionality, but they are clearly meant for two different audiences / types of project.
In the end we rolled our own in Rails was much quicker and simpler than these off the shelf tools.
As a not-backend person I have been enjoying Strapi but maybe I should investigate something like rails.
Repeating fields, in order to construct content as we wanted it to look. We needed to be able to determine if we have the latest information without having to go through all database rows.
If it does what you need to do out of the box then stick with it, but for us, we needed to do more complex stuff.
Sometimes, they mess up the indentation, or insert a quote in a non quoted value, but the PR turns red and someone more expert can correct the issue in a few seconds.
They can even be impressed by some functionalities (whoa, reviews ! whoa, I can make a draft PR !)
Github is the cheapest headless CMS, try it first.
https://headlesscms.org/projects/webiny
EDIT: there's also other headless cms solutions like Netlify CMS, see the list: https://headlesscms.org
What most CMS products miss is; in real world, a company spends a lot of energy on not just building software, but also operating with the tools they build. I haven't heard any love story about people who write content. Developers build their stuff quicker, editorial teams look at a screen that look completely irrelevant to their work. People hate their jobs and may quite because of the horrible UX experience CMS products deliver.
This is my feedback. As a developer, I'm not looking for another Schema-to-GraphQL generator. There are too many of those. Good ones and shady ones. Nobody would miss anything if somebody decided not to build another CMS competing with the existing ones today with slight differences.
The bigger challenge is to build something not just developers, but non-technical teams love.
It uses headless CMS architecture, but it enhances it to support an entire content lifecycle - from planning to production, delivery, personalization and optimization.
It comes with collaboration capabilities, such as comments, suggestions, tasks, etc.
You can learn more at https://kontent.ai
Full disclosure: I work for Kentico.
It’s a Yii framework app that supports a good CD workflow and does rest or graph APIs pretty easily, and supports a flexible content model. Our authors like the live preview, text/image editor and how the content builder fits the content without any hacks. It reduces their uncertainty about what they’re doing.
I would probably try if they have localisation support, CDN integration and search functionality.
It may be very trivial for developers to host static content but for non-tech guys who might want to change the content frequently, this is good.
Few years back I worked on a mobile app which will show some training material ( basically text ) to user but the content is updated every week, along with other functionalities. Content team used to share Excel sheets to organise content that needs to be shown that week. It was "fastest and clean" way at that time. If they had to change something, they would share another sheet with corrections. It created a big rift when we asked them to add another field in that excel sheet for additional content. Having something like this would have solved those issues.
Decoupling content with presentation is always a good idea
Ended up just using wagtail.
Am i missing something else? Why should i still use strapi today?
We use Strapi in production alongside Eleventy, a simple static website generator.
One thing we've been missing with Strapi however is the possibility to localize content. I know the issue was raised but I'm not aware of any roadmap and we needed to hack our way around this limitation.
As I prefer to self host anyway, might this be a viable alternative?
Usually the administrators who are defining a CMS model are also the developers consuming it.
Editors need to get trained in the CRUD interface of that model: the UI and the implications for the frontend.
This is completely orthogonal to the CMS or whether it is headless or not.
Strapi has an interface and semantics that are very clean and conservative, I assume for this reason.
It being headless removes complexity and allows it to be more minimal and focused than a vanilla Wordpress installation, which can definitely help in that regard.
If you look at the docs of Strapi you see that this is the case for Strapi as well.
Still plone does it much better than any of this headless CMS, why don’t people look at it for design inspiration rather than reinvent the wheels and do much worse job.
It feels like Java implemented in Python.