I’m using Strapi + VueJs for making a static website more dynamic for a NGO and it works like a charm !
The only issue I had so far is that the admin form customizations seem to be stored in the database instead of application files, so it’s not possible to replicate them easily between environments
I think a lot of people are missing the point of a tool like Strapi.
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.
>> CMS experience for non-technical teams: marketing, product, content, etc. 2. Graphql api to avoid lock-in
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.
why would a "non-technical" team pick this product over something more universally hostable and well known, with established plugin ecosystem and developers on tap, like Wordpress?
so the choice of wordpress or nodejs or whatever is a developer driven decision. However, the non-technical team will want a brilliant CMS experience.
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.
> To be fair, you can achieve that in Wordpress as well
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.
While I agree some of these plugins do start to feel hacky, WordPress Core has evolved quite a bit from being just a blog. Custom post types are not even new, but come to mind.
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
When I say "anything other than a blog", I do mean "blog" in a broad sense. A "publishing platform" may be a better term but is rather vague.
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".
Because the web is moving away from pure content or shop pages to more holistic interactive experiences where you need to integrate content into complex flows that are more application than website. Plus you might want to reuse said content on mobile apps too. There it really pays off to have your content separated as structured data that you can query for.
Is that meant as satire or what? Structured content that an end-user can edit, query, share, comprehend, design, etc. is what you have with markup languages, and have had since over 30 years (SGML/HTML/XML). A "headless" CMS is just an API server eg. a tool for JS developers; you could use any JSON or GraphQL API wrapping tool you want (PostgREST, say), or code one yourself in a few lines of code. So I have to say "headless CMS" is really a pure marketing term, and IMHO utter pointless, as the difficulty and most of the work in a CMS product comes from a front-end (or architectural match, really) that end users can meaningfully interact with and set up dynamic sites, redactional workflows, dynamic user content, theming, analytics+banners, asset management/pipelines, etc., etc. with.
> as the difficulty and most of the work in a CMS product comes from a front-end (or architectural match, really) that end users can meaningfully interact with and set up dynamic sites, redactional workflows, dynamic user content, theming, analytics+banners, asset management/pipelines, etc., etc. with
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.
Never used Strapi so take this with a grain of salt
- 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.
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.
I'm surprised by the number of non-dev people that can create and edit YAML files on Github/Gitlab once you guide them around the interface.
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.
This is very, very true. I have worked on some mega enterprise CMS projects with huge marketing and content teams. A lot of heavyweight products try to be your all-in-one solution for publishing, marketing, analytics, whatever. It makes for a great sales demo, but the reality is that only a handful of people will put their hands on the console and all the decision-makers are working over email or just listening to their teams. If you know you'll only really have a handful of content operators, it's way cheaper to train them to edit JSON/YAML/MD then it is to integrate an enterprise software product.
I gave this a spin a while back and the experience was really really not great. I created a new content type and tried to name one of the fields "ID," not knowing that an ID field is automatically added to any content type. Instead of throwing a helpful error, that not only crashed the running server but also made it impossible to restart the server until I manually deleted the offending auto-generated JS file for the type. A minor quibble, perhaps, but the first impression stuck and I haven't touched it since.
I suggest you separate the data entry and schema design screens into two pages.
I think there are alot of people out there who want to give users a great admin gui but not necessarily give them control of the schema.
It's difficult to differentiate the products in CMS market. I use Contentful (which launched in HN 7-8 years ago) currently. Developer productivity is a solved problem already. Hitting a few buttons and getting an API is nice. Every other CMS has Rest and GraphQL APIs, nice docs for devs, etc.
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.
Kentico Kontent was actually designed to bridge the gap between developer and business user needs.
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.
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.
Isn't strapi what you're asking for in the last sentence? Easy to create decent backend in no time, and for non-technical teams it looks like final product from day one...
A nice UI for entering content into forms is about 10% of a what a scaled content production team needs to get work done and 0% of what a digital marketing team needs. All that being said, Strapi can still be a really good product to fill a big part of the framework without locking yourself in. There are giant enterprisey CMS products like AEM or SiteCore that are all-in-one publishing and marketing platforms but they ludicrously expensive and complicated and not great quality either.
So, it's like parse.com ( if anyone remembers it) but for content.
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
We tried strapi late last year but found some big deficiencies that made the editing experience subpar. Simple things like being able to order a list of foreign keys, you cannot do and makes it hard for using this for content management - not sure if this has been fixed yet. The editor was very buggy too.
Tried this out. It's a GUI tool for creating CRUD apis with authentication and authorization. It does the job but it's pretty clunky and heavy for what it is. You could probably get similar or better results with Postgres, PostgREST, and some GUI tool for Postgres like Postico.
We switched from Ghost to Strapi + Gatsby.js when we were facing limitations regarding i18n in Ghost. It works pretty well! Spinning up Strapi is a breeze when using a PaaS like Heroku.
This is a similar use case. I evaluated a bunch of free headless CMS and I really wanted to like Ghost, they even mentioned it's i18n ready, but it wasn't, at least not what I expected like having localized pages. Switched to Strapi following the video they had in the landing page (not the new one landing page, which I feel it lacks in "show don't tell", and it was a breeze, it just works. On my case I'm using Strapi + 11ty + Netlify.
is this a completely new version? I remember ghost and strapi blowing up in the node.js community couple of years ago with the promise of replacing WordPress, but haven't really heard of strapi since then. Now i see it supports not only Mongo DB, but postgres, mysql/mariadb and sqlite and that's very interesting. Did you replace the traditional node.js orm with a graphql server?
Am i missing something else? Why should i still use strapi today?
Yes, the first stable version of Strapi has been released a couple of weeks ago. There are new features available like the Media Library, webhooks and Dynamic Zones to make Custom Types on the fly. 2 different ORM are used: Moogoose (MongoDB) and Bookshelf (Postgres, MySQL, SQLite) and there is a plugin for GraphQL.
Strapi is a very promising piece of tech that enables great productivity and helps us with the data required for building sites using static website generators.
I wonder why I've got downvoted. It might sound like and advertisement but it's actually true.
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.
I'm currently feeling the pain of missing localization support and I'm considering building a service to add and automate it. DM @handheld on Twitter if you'd like to weigh in on features.
I'm using Strapi & 11ty too. I have 'pages' and 'posts' with properties 'content' and 'locale'. That's how I manage i18n. That's for the main content. For small strings used in other parts of the UI I'm using json files with i18n strings that 11ty injects into the views.
I've been testing it foir the past weeks, for my own portfolio. It has been an nice experience but the docs are not updated. I've been running into several walls because of this and my resources are searching for solution on the internet, which very often are described in issues on the Github repo. That's my only negative until now.
Hello! We are doing our best to keep every assets updated.
We are going fast and we are still a small team.
In next months we will structure the documentation team to make sure we have one person 100% focus on the docs.
I've been using airtable to give a bit of dynamic content to an otherwise static site. The API has some limitations, though, like not being able to directly upload images.
As I prefer to self host anyway, might this be a viable alternative?
How are the training resources for editors using Strapi? One selling point of the more commonly used CMSs is that you can hire editors that already know it and there are companies that can help you train editors.
From my experience you have to do that anyway if you have a custom data model.
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.
True. Depending on the deployment scenario there could be some additional factors. For example, take a static site that runs on netlify. There is a hook on headless CMS save that triggers a build. The build is usually quick, but its not instant (like Wordpress for example).
Didn’t Python zope did it in 1990’s era. Looks like we are going back where we define content type (archetypes in zope/plone) and generate forms and content based on it.
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.
Plone is really heavy duty in comparison to Strapi. Plone is what you use if you want a CMS for an enterprise. Strapi is what you use if you want a very lightweight CMS and you find even something like wordpress too heavy.
