21–30 of 31 posts
How does this compare to https://www.graph.cool/ or https://scaphold.io/ ?
Congrats to the Sanity team on launching! I have a vested interest in this (I work on the open-source data store used internally by Sanity), but I genuinely think Sanity is a game-changer in the CMS space.
Congrats to the Sanity team on launching! I have a vested interest in this (I work on the open-source data store used internally by Sanity), but I genuinely think Sanity is a game-changer in the CMS space.
What data store do you work on?
I'm hoping that there will be documentation on how to self-host the backend soon as a backup.
This feels like a CRUD app builder disguised as a visual programming tool. I generally avoid those things because they are hard to debug or extend. Perhaps this is different because of GraphQL? In this case, I would typically reach for a battle-tested CRUD building framework like Rails that gives you JSON APIs for free. I am not as familiar with GraphQL frameworks, but I suppose that I could find one as well if I rea…
It seems like they have invented a new query language called GROQ that sites on top of GraphQL: https://www.sanity.io/docs/front-ends/what-about-graphql
I went to the docs:
https://www.sanity.io/docs/introduction/why-headless
I still have no idea why you call your product "headless CMS".
It's hard for me to trust services like these that don't provide even a paid self-hosted version. Backend lock-in like Parse, but it probably won't get a community to rewrite it. So good luck if they ever go under.
There's an open source headless CMS here: https://getdirectus.com/
It doesn't have all of the batteries of Sanity and uses normal SQL for data backend, but it's a good way there.
What is a "headless CMS" at first place? why do you assume people even understand what it means? I went to your home page I still had no idea what your product is supposed to do. I went to the docs: https://www.sanity.io/docs/introduction/why-headless I still have no idea why you call your product "headless CMS".
We don't actually like neither the "headless" nor "CMS" part of the vernacular, but it seems to be the least unknown description of our product category around.
The classical CMS provides a way to author your content married to a templating engine that describes how your content gets rendered to HTML. This last part is what is considered the "head" when we speak of a headless CMS. Simplistically a headless CMS is a CMS that provide an api to the content instead of rendering it as html. Then you write the "head" (i.e. front end) in whatever technology you prefer using those apis.
A fair question then would be: what's the big deal? Can't you just stick an api on Wordpress and off you go? That leads to the other, less obvious difference: A good headless CMS is focused on authoring the content as structured data so that it is clear to the presentation layer what each piece of information means. Take this project page from the OMA.eu site:
http://oma.eu/projects/timmerhuis
If you expand the Location, Year and Program parts of the metadata you'll see maps, timelines and charts. These are all rendered by the front-end based on long-lats, lists of milestones and area usage authored by the OMA editors. In their old CMS these would be uploaded as images and html-fragments, but with Sanity it is described as a structure of data-points with a defined meaning. This allows us to use those same data points to provide advanced search functionality (give me buildings widh 20-30% office space and more than 5% retail), and it has also allowed us to generate print-ready books from the exact same dataset that power their web-site.
The big hairy goal of a headless CMS is to disentangle the content from its presentation, and thus make the content reusable across many forms of presentations ultimately making the work spent authoring that content more valuable.