When I saw the OMA and DS+R logos on your marketing site, I thought no way it's the Architecture firms...prob some niche technology companies in Europe.
But lo and behold, you guys did build their new websites! For the HN crowd, OMA and DS+R are at the top of the field...as a tech analog maybe comparable to Stripe and OpenAI.
I've been diving deep into the finding the right headless CMS and so far have found most either lacking or too expensive (Contentful anyone?). At the moment, hacking away at Netlify's React CMS, but it's a struggle.
Excited to check out your product especially since it's used for architecture firms I love and respect!
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 really wanted that.
I am not really sure what people mean by "CMS" anymore. I have always thought of it as a place for people to create and publish pages. It is confusing to me when people use it to mean a structured database.
Maybe we need a new word.
And for sure, this way of thinking about content isn't new. People have been building bespoke relational databases with custom forms on top since forever. But it has been time consuming and also pretty hard to get totally right. It's free form in data structure, but expensive to change.
Many who haven't needed to structure content in the past need to do so now. Both given content reuse across touchpoints, but also to be able to easily shift your content over to other services as structured data.
So we built Sanity to make this fast and easy while not compromising on the experience for the editor: real-time collaborative work on structured, interlinked data.
BTW – In order to make extending the editing UI clean we've built a system for build-time dependency injection. This gives a non-crufty way to override and compose components: https://www.sanity.io/docs/extending/parts
To provide some background: Your typical modern web application typically revolves around a central CRUD API that you then build apps on top of. You'll typicall have a web app and maybe a native mobile app. But you also need an "admin app" that provides content editing, login, role-based security, and so on.
One option is to use an off-the-shelf CMS. These are almost invariably big, antiquated monoliths that want to be your entire technology stack. Most CMSes not only want to be the system for managing the content, they also want to do the delivery, through some kind of templating system that force you to write your application inside the CMS. I've never met a developer who likes their CMS.
Since CMSes suck so much, companies also very commonly roll their own content management from scratch, which means you spend an awful amount of time writing common stuff unrelated to your core app — database CRUD code, APIs, role-based security, and so on. Rails took off because it was so easy to define your data model and get the CRUD API off the ground. But you still have to do the admin UI; you still have to wire up all those forms, enforce data validation, build complicated things like photo upload and countless other things. And you have to do it all over again for the next app. No admin is reusable.
Sanity turns this upside down; it adopts a "data first" philosophy. First, you get a general-purpose data store for storing your content. It's an advanced document-oriented, transactional data store that comes with live change feeds, strict schema validation, and fine-grained permissions and an expressive query language called GROQ, which is reminiscent of (but different from) GraphQL. This data store replaces your ad-hoc CRUD API.
The second part is the Content Studio. This is a modern, extensible, customizable JavaScript framework that renders a content editing UI on top of the backend data. The UI has been designed from the ground up for the data store, and supports live collaborative, Google Docs-style editing. It's implemented in React.
So with those two building blocks, you get a way to store data and edit it, but Sanity leaves everything else to you. You can use whatever technology stack (Rails, PHP, Django, etc.) to develop your front end apps, as long as you use the data store.
Disclosure: I work on the Sanity open-source data store, called Gradient. However, I'm not directly involved in the Sanity project, so the above is just my personal perspective.
I bother with this "thanks" message because I was ready to write a tirade about the technophile echo chamber of nonsense web widgets that seem to show up on HN regularly; solutions in search of problems that should never exist in the first place. Unfortunately, Sanity's website screams "we got some graphics people together to dress up some code we stole and obfuscated from GitHub," instead of "professional solution to a real problem." They should just replace the whole design with your reply here, in plain text. But then I guess it would be far more difficult to convince the CIO to adopt.
There should be some kind of hidden standard file on all these sites that you can go to, like "sanity.io/ACTUAL.txt" or something. It would just give you the actual story of what's happening, and not use words like "touchpoint," nor have 90s Hollywood garbage flying all over the screen. Again, I understand the purpose of the lightshow, but it usually causes me to immediately close the tab. I only stuck around for this because the problem of CMSes sucking is all too real.
Every greenfield project starts with a data model, but eventually gets encumbered in lots of crazy, bespoke business logic. This happens 6 months to 2 years into a project when some person asks for "one little thing". I'd love to see people who have used this for a while talk about data migrations, constraints, and all the other cruft that ends up happening in software development of CRUD.
This reminds me of Microsoft Sharepoint without all the widgets (which is what I meant when I said "visual") or Salesforce or even Microsoft Access. All of which are fairly difficult to manage, but appeal to a certain kind of customer.
The problem comes in when you have some complex business logic (you need 2 levels of approval on a Tuesday to publish this data)
I'd rather write all that stuff in a popular programming language.
https://www.sanity.io/docs/front-ends/what-about-graphqlBut I would prefer paying a license for the SDK and host the API myself than having to rely on a third party for something so crucial to a business.
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.
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.
I'm hoping that there will be documentation on how to self-host the backend soon as a backup.
Also love your startup / MVP friendly pricing => https://www.sanity.io/pricing as compared to the other most popular headless CMS (you know who they are!).
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.
For complicated rules like your example use case, you can add anything you want to the client-side validation hooks. In fact, almost all data validation currently happens client-side.
It's true that you'd not be able to enforce anything particularly complex if you submit writes directly to the API, but we're planning on supporting webhook-based validation, where you register a webhook that will receive documents for approval. We've successfully used this pattern in past projects. For example, something that isn't easily expressed declaratively is Hacker News' rule that thread comments are only editable a certain amount of time after they're submitted. We, too, prefer this kind of thing to be implemented in code.
Disclosure: I work on the data store, but not on Sanity itself.