Sanity Studio v3 launches Dec 8th - See it in action at Sanity Product Day →

The Sanity Way

The design rationale for Sanity

The Sanity Way

When building Sanity we spent a lot of time thinking about what a framework needs to look like for designers, developers and editors to effortlessly work with structured data. What would a headless CMS look like when its done exactly right?

  • You should be able to really deliver your content anywhere. So how do we ensure strict semantics so it's actually possible? How do we deal with media when screen sizes aren't known?
  • Strict semantics means compound data structures. Can we make data modelling trivial?
  • Different people have different needs. How do we make the editing environment fully customizable with tooling that people already know and like?
  • How do we make working with layered data structures comfortable and effortless for editors?
  • After GDocs people expect collaborative editing. It's hard, but can we make the back-end and editor real-time? Could we make it easy to extend this to plug-ins that people write themselves?
  • How do we extend all this to a robust, scalable global infrastructure that will merrily weather out any traffic spike?

Two parts of a puzzle

Develop locally –We want to let you use your front-end skills to customise the editing environment. The Content Studio therefore runs on your laptop as a javascript bundle written in React.js. It deploys with a single line in the CLI.

Deploy globally – The Content Studio is backed by a platform as a service with authentication, a real-time database and asset pipelines.

Together, the two allow you to craft better user experiences for editors while allowing you to move into production on a solid, globally edge cached platform.

What we built

Developer Friendly – The data model is described in code and immediately reflects in a comfortable user interface that editors can get to work in. The UI adapts to any data structure you can express. The command line tool enables import and export of data sets and can deploy the editor in a single line of code.

Real-time – As is expected by editors, Sanity is real-time. The Content Studio applies keystrokes and other editing operations as granular patches to the data store. These are immediately broadcast to other editors.

Powerful query language – You can fetch all data needed to render a page through a single query that also traverses references. You can re-project fields to get objects that are perfect for your display logic. You can listen for changes via the real-time API, allowing you to persist queries and stream changes in documents. This is also used to make the editing environment real-time collaborative.

Rich data model – In order to capture content as structure you need a rich data model. In addition to expected fields, Sanity offers polymorphic arrays, compound objects and hard references.

Structured Text – Rich text content has a strict schema and is stored as a data structure. Running text can be interspersed with objects using friendly editing interfaces. Don't store a map as an image – simply allow map-objects as a block in your text and store them as coordinates and a zoom-level.

Customizable editor – You have full freedom to change the editing interface to best suit the needs of the editors. Perhaps you should display data from a third party API to populate some fields? Maybe integrate with a machine learning platform and surface insights in real-time? Sanity is built in React.js and plugins allow you to create and include components that compose or override existing functionality.

Peace of mind – the Sanity platform runs fully monitored on Google Container Engine (GKE).

Capable caching – In addition to using Google's granular edge cache for speedy asset delivery over HTTP2 we also provide a separate edge cache for API calls.

Was this article helpful?