Show HN: GraphCMS – A GraphQL-based Headless CMS
graphcms.com
graphcms.com
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.
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.
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.
One benefit of the nature of a headless CMS though, is that there can't really be a vendor lock-in on your content.
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.
Why would I want a "Headless" CMS?
Why would I want a CMS based on GraphQL?
What is wrong, with plain old HTML?
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.
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.
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.
What do you mean by this?
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'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.
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.
Perhaps one of these would serve your needs:
Their software ecosystem is mature as well, as they've been around for a while.
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.
* Of course with "trivial" I meant possible.
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.
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).
curl -O https://github.com/directus/directus-docker/blob/master/docker-compose.yml
docker-compose upIt 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.
Though obviously GraphCMS is different (technology-wise and business-wise it seems).
(fyi: the documentation is not released, yet)
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.
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.