Why You Should Embed Your Studio

As of version 4.0.0 of SanityPress, the Sanity Studio backend has been embedded within the Next.js frontend architecture.

With this comes many benefits that make the lives of both developers and editors so much easier.

Benefits of an Embedded Studio🔗

A single domain🔗

Most noticeably, you don't have two separate domains for the Next.js frontend and the Sanity backend. Previously, your website may live on mycoolwebsite.com, while your backend lives at mycoolwebsite.sanity.studio.

This approach might be suitable if you use the Studio as a true headless CMS, where your content might be deployed to not just to your website but also to a native app or elsewhere:

"The convenience of co-locating the Studio with your Next.js application is appealing, but it can also influence your content model to be too website-centric [...]"
— from the sanity-io/next-sanity README

That said, embedding the Studio directly into the frontend architecture allows you to have the Studio reside in the same domain as your website—for example, at mycoolwebsite.com/admin (or wherever).

From personal experience, editors have preferred having a single domain for the frontend and backend. Even as a seasoned developer myself managing multiple Sanity studios, it's not infrequent that I've forgotten the names of the *.sanity.studio URLs.

Simpler codebase🔗

Prior to embedding the Studio, the SanityPress codebase was set up as a monorepo with a nextjs/ and sanity/ directory for the frontend and backend code, respectively.

It's visually easy on the eyes to tell which code resides where. However, it ultimately ended up being the better decision to set up Next.js on the root directory and embed the Studio with the <NextStudio> component.

Now that there's a single package.json file, it's easier to share NPM packages across the codebase, as well as updating them. If I need to share the same code between the frontend and backend (like environment variables or small utility functions), that's also hassle-free.

What's the catch?🔗

Let's be honest, there's two small catches.

The Setup Process🔗

The first is easily mitigated, that is, if you use SanityPress. Setting up an Emedded Studio requires some work, but not too much. You can find directions here to set it up yourself, or clone/fork SanityPress where it's all done for you 😉

Increased Deployment Times🔗

The second catch is that is does increase deployment time. SanityPress.dev (deployed on Vercel) took about 1 minute on average with an un-embedded Studio, while with one now takes about 1 minute 50 seconds to 2 minutes.

This might sound bad as the time practically doubled, but considering it's still 2 minutes... I'd be OK with that and so would most of my clients. Plus, deploying the Studio separately with the CLI (i.e. the sanity deploy command), would also take about 20-30 seconds anyway.

With SanityPress, you don't even have to deploy, as time-based revalidation will keep your content up-to-date, refreshing every hour by default (or at any desired frequency).

Conclusion🔗

In the end, it's up to the developer (but ultimately the editor's preferences) whether an Embedded Studio is the best approach.

SanityPress is opinionated in that it does opt in for the Embedded Studio, but for good reason. If you find SanityPress might be a good match for your next project, star and clone the repo on GitHub.

Do you prefer Embedded Studios? Do you have any other benefits/drawbacks? Share your thoughts in the comments below 👇