You have started a Sanity project and have configured your schemas and published some content to the API. You are now ready to make a frontend, an app, or a service that makes use of it. Even though you can use Sanity.io as a general API for all sorts of things, it makes sense in some cases to keep the Sanity Studio close to those services that make use of it. Moreover, if you think of it, the Studio is just another frontend to your Sanity API.

There are probably many ways to approach this, but the pattern we have seen the most is to structure your project in a monorepo. In fact, we do it ourselves with the Studio and the many packages that can be used separate from it. Of course, you should consider pros-and-cons of multi- or monorepos, but for a typical project with a studio, a frontend web- or app project with perhaps a simple service, we think it makes sense. It means that you have version controll over your schemas. Which is a good thing. It also means that you can include the content studio in a Continious Integration flow, integrating it with other apps.

There is little magic to making a monorepo, in essence, it just a simple folder structure:

In this case, dependencies are installed in each separate folder. So you'll have to start the apps and target the folders in your build system. If the project grows and some of your packages is to be published to npm or the like, you can use monorepo managing tools like Lerna, to make it easier to keep track of versioning and to bootstrap.

Since we have written Sanity Studio in React, this structure also allows for sharing UI-components, CSS and so on across projects.

Still not sure how to structure the code in your project? Join our community and ask us!