It's a good answer, especially if you haven't built a self service, easy to deploy self hosted product. It's code for "yes but this is expensive and we'll likely have to do a lot of consulting to make it work".
Self hosting is a reasonable enterprise feature. Support is a difficult thing to build a business off of. It's fine if you don't want to pay for some kind of SaaS, but that's possibly the only way to build any kind of sustainable software business for developers.
Our new architecture allows much more flexibility on the deployments, so just speak to us about your favorite setting. However, it is quite complex and we rather focus on delivering a high quality cloud infrastructure that works for everyone. I can understand your perspective but our mantra is to remain a SaaS company, which means to be able to focus on ONE code base. This allows us on delivering a higher quality product in the long run so all users can benefit from it.
Craft CMS is designed for deployment on your own servers. It does not offer a hosted version as yet, but has just as strong a headless mode with full graphql support with craftql.
Exactly. Or drastically changes their pricing model (see: Contentful).
I understand the benefits of all of these individual services, but I also miss the days of the only service I had to worry about when I handed off a client site was hosting.
Now it's often the headless CMS hosting (i.e. Contentful, GraphCMS), actual hosting (Netlify), CDN, Image CDN, Search (i.e. Algolia). So many places for things to break. So many separate charges.
I also love headless CMS's but much prefer self-hosted ones. Directus has been a favorite to experiment with so far.
I definitely can understand this point of view! But this is actually the case for all SaaS's out there. I would even say that this is also the case for open source projects if there aren't maintained anymore and the costs for trying this yourself are too high.
One benefit of the nature of a headless CMS though, is that there can't really be a vendor lock-in on your content.
If there was a commitment to open source if the service was being shut down, I would sign up.
Content is a much larger problem than many realize u til they are dragged into projects that run late, grow too big, and need too many signoffs to be ready.
as a client, I would rather be paying a hosting company specializing in one area 24x7 rather than a dev maintaining the database on and off basis. there is nothing more infuriating than not being able to get a hold of the dev when your site is offline for whatever reasons.
Perhaps your CMS serves multiple front ends: a website, or a mobile app.
> Why would I want a CMS based on GraphQL?
The way I see it, the CMS is not based on GraphQL, it's just a CMS that you can query with GraphQL. I haven't used GraphQL at all, but it seems like it could be useful for working within a system where you need to bring data from many different REST endpoints together. Usually I would have to hand code something like this myself on the backend, but with GraphQL it seems like once you have it all set up, you can get data from multiple APIs, while specifying the schema of your response on the client instead of on the backend.
> What is wrong, with plain old HTML?
Nothing, if you can build what you want to build with "plain HTML" then do it.
It's describing the CMS, not the API. It's not so familiar to software engineer types, but is pretty well understood in publishing / Drupal / WordPress space.
So you're supposed to put test/markdown and images in it and basic structure like title/date/author? What about data oriented systems instead of content oriented?
I'm not sure I understand your questions. I haven't used GraphCMS so I don't know if they let you store HTML, but some CMS do, and yes that makes it harder to reuse your content in a context other than the web. I don't know, but I assume that you could probably make GraphCMS store HTML if you wanted to. The question of "can the CMS store HTML" seems orthogonal to the question of "Is it headless?" or "Does it have a GraphQL or REST API?"
Nothing is wrong with plain old HTML. Going headless gives you frontend freedom. It means integrating your content on any platform you like: web, mobile, smartwatch, fridges and toasters (if they are smart enough). It's interesting that we mostly see people using a headless CMS just for web.
Why?
Because they can pick the frontend stack they like! React, react-static, Gatsby, vue, nextJS etc.
You can pick the stack you like most. It is much easier to find a react developer than someone who knows how to write good drupal templates.
Why GraphQL? Because it's awesome! I can highly encourage you to just try out a GraphQL API and see yourself. It is designed for fetching related data efficiently and it will give you a huge boost in development productivity, which means lower development costs and faster time to market.
A Headless CMS means you define all of the frontend interpretation of the content. Basically a GUI for your database.
If you have lots of queries happening behind the scenes whenever someone makes a request that seems basic- like how Facebook gets a list of comments on a post, plus the friends who made them, and a list of different reactions to each comment, and other stuff that rapidly creates a complex graph- then GraphQL simplifies. The REST way involves all of those extra calls, GraphQL gets everything in one request.
Not specific to GraphQL, but plain old HTML doesn't work when other non-technical people are managing the content of the site. They need a GUI, and hence the need for CMS's in general.
We will soon start open sourcing our content management interface, so users have the opportunity to customize the CMS UI to their needs. Most of our customers just want us to take care of the hosting.
> We will soon start open sourcing our content management interface, so users have the opportunity to customize the CMS UI to their needs.
"We're going to open source the interface" is a disingenuous answer to the question. Documenting an interface isn't open source. If your plan is "proprietary SaaS", just own it.
GraphCMS is the only CMS that exclusively offers GraphQL. Other CMSs have since entered the space to offer GraphQL technology, but they still try to maintain both REST and GraphQL APIs which will lead to some maintenance issues in the future. An example of this is that the other CMSs aren’t able to offer a “mutation” API for their CMS through GraphQL. With our CMS you can query the data and change it through the same powerful interface. This opens the door to a wide range of tooling and custom workflow enhancements. Additionally, because we only offer GraphQL, we are able to be more agile with changes to the technology.
In the future, our focus will shift even more to content based BaaS as we will support end user authentication. We are also preparing a new suite of workflow tools that will make managing large datasets a breeze.
Agreed! I'd much rather have a GraphQL-based headless CMS to the WordPress backends I usually work with, but everything I have seen is a hosted service rather than something I could download and host on my own. Usually isn't cheap, either. It's been a real turn-off for me.
It's really, really hard to build an open source (free) product that makes any money. GitLab works because it's a very complex product that a few really large companies are willing to spend hundreds of thousands of dollars on it. I can't imagine that being true of a CMS.
That being said, different genres of software have "known" price points. For source control, it's expensive. For analytics, it's expensive. For blogs, it does seem like the open source model is the only one that's really taken off... Wordpress and Ghost both use the model, and (for better or worse) anchored the price point of blogging software somewhere between free and $10/mo. Makes it hard for any incumbents, which is probably why WordPress still is so popular.
WP is extremely modifiable. I think it would be trivial* to turn WP into a headless CMS. I made a proof of concept some years ago and it was great because you could still use plugins to transform the content. Alas, feeding-my-family realities prevented me to pursuit that project.
I'm not a fan of pricing with operation limits. 100k API calls per month? What happens in a DoS situation? If it's self-hosted I can blacklist and keep the app running for other users. For a surge in traffic, I can spin up other containers and scale. With managed hosting, my bill can go through the roof, or the the entire app gets shut down.
Not sure if I communicated what I meant. I think if I was going to set up something using a headless CMS, I would integrate it with a project like React Static. When a user publishes something in the CMS, it would trigger a build of the generator that would result in putting some files out in S3 or something equivalent.
That way if you see a traffic spike or a DDoS attack, it's directed only towards static files on S3 and you can let Amazon take care of it. I don't want to be too critical of how people have things set up because I'm sure they have their reasons, but that said I don't think a page request on your site should map directly to an API request to the CMS.
Directus is always at the top of self-hosted CMS lists, but one of the reasons I avoid it and other PHP self-hosted headless CMS solutions is due to the difficulties(tech debt) of automating dev environments and CI/CD pipelines across different distros and OSes.
I would have possibly given Directus a spin if it didn't have hard dependencies on the following PHP system extensions: curl, gd, finfo, pdo_mysql and mbstring. Not to go too off topic, but I wish PHP extensions could be installed via Composer and Packagist (similar to how NPM handles native modules).
The problem you're describing is precisely why containers are so popular. You can install and deploy any app even if it doesn't provide user-level installation choices (such as php native extensions)
TLDR; It allows you to bring content to any platform.
It allows you to build content databases in an easy and visual manner. Once you have your content in GraphCMS, you are able to fetch it in an elegant way by using GraphQL. The target platforms that consume the content can be anything: web, mobile, alexa skills or just business partners you want to share digital content with so that they can put it on the target platform of their choice.
It's about the language front-to-back. The language that builds the CMS is also the language that you build your sites with! So you keep the overhead low on various technologies being used. Yes, GraphQL users are the primary people drawn to the app, but that's sort of true for any platform?
Looks great, excited to try it out. Just skimming through the Documentation, is there any way to specify the Schema through an API? My use case that I want to define my schema somewhere, and have something which "syncs" the it with GraphCMS, is this possible?
You could use the management API for this. It's basically the same API the content management interface also speaks to. You can open up the API explorer and switch to the management API in the top bar and play around with it!
Is GraphCMS a Graphcool service? I see their style of sorting and filtering in your API. If so, what's your experience with Graphcool, and what value does GraphCMS add?
the former GraphCMS was built on top of Graphcool, with the new system, we also move to Graphcool's new product, Prisma, which is a setting we enjoy a lot. Prisma runs at the core for CRUD and then we add an additional API layer to it to add the features we think make sense in a CMS context.
The value add depends on perspective. If you are looking for a tool to build a content database, then GraphCMS brings definitely a lot to the table. While you get the content management interface and tools, we add just enough opinion to the APIs that makes sense in a context of building a content database.
Graphcool is also not actively maintained anymore as the team is now focusing on Prisma.
The Demo-API on the landing page is from the former stack. We will soon add a new example to showcase all the new API utils.
Graphql is not a product pitch. I don't care. Even your product page just shows an editor that looks like a WordPress article. Why do I need graphql to pull an article from a remote api to my local cache? Your front page is just reasons why graphql is good. Maybe so, but I'm sizing you up for a cms api for my business, not a library. Technology itself is not a product
GraphQL is fun on the frontend. On the backend, there is a gazillion things that need to be considered. You can build a powerful GraphQL backend via the GraphCMS UI.
So we leave you with the fun part.
This has proven very valuable to our users that don't want to implement the backend part of things, while getting a content management interface for editors.
Pretty cool, but I can't help but feel really soon that browsers will just implement a similar rich default GraphQL and there will be some CSS concept for it when there is no full app code loaded.
This is not an answer. Talk to sales?
I don't mind paying for support. I'm not a fan of paying for enterprise features. I would never want a dependency to something which is not free.