Clarification on the necessity of the /schemas folder in a Next.js and Sanity.io integration.

Hi everyone! I’m starting a job next week using Sanity + Next.js, so I’ve started spiking ahead of time and teaching myself about Sanity as a headless CMS. I followed User’s tutorial here , which was great at showing the basics of building and deploying a Sanity Studio schema, the Presence API, the content lake, etc. Then for the frontend, User selected a Next.js blog template and deployed it on Vercel. She didn’t go into too much detail about tailoring and customization, as this was in the final 2 minutes of the video, just encouraged us to select a blog based template and play around with it.
I selected
this template, and tweaked some of the interface and content type definitions for Post and Author to match the naming conventions we had in the tutorial (or vice versa in some cases), so when it was connected to my headless Sanity Studio and deployed, everything would be apples to apples. Everything showed up correctly after this. Now I see there is also a

/schemas

folder inside the Next.js template with it’s own content type definitions for Post and Author, and a couple of presentational components that pull from this schema’s content types instead of the deployed Sanity schema that the project links to. Aside from redirecting those content type definitions to ones that come in from the Sanity Studio repo, is this

/schemas

folder with the duplicate schema definitions necessary to keep on the frontend? It looks like it’s packaged in as an embedded studio for Sanity Studio functionality out of the box without a corresponding sanity.io deployment.

My question is this: where I already have the second repo with my headless CMS deployed, is this necessary to keep

/schemas

on the frontend, or can I rip it out? I’m leaning towards ripping it out, as another tutorial mentions creating a

client.ts

file which will fetch from the content lake, and does not have a

/schemas

folder in the front end. I’m pretty certain it’s not needed but am I missing something? I can’t seem to find a straight answer online as to whether or not this is redundant in a headless deployed CMS scenario.

Hey . Your question boils down to a particular difference in implementing Sanity v2 vs v3 on Next.js. Previously, you needed to have a studio folder with all your Sanity implementations, and deploy from that folder/start the dev studio directly from there.On Sanity v3, on the other hand, much better support was added, and the convention became to have your
schemas folder directly in the root of your project, with the studio becoming available through a Next.js route instead of a separate deploy, such that your Next.js website's URL would be e.g. example.com , while your Studio would be at e.g. example.com/studio .Note that both v2 and v3 use
next-sanity as a helper in between, and v3 requires sanity (and your sanity-related packages) to be installed in your Next.js package.Now, while both approaches are available and possible, the latter requires less code living in your project, is more concise and relies on Next.js to display pages, "as it should be".
While some consider it a matter of opinion, I would say the latter is by far the most preferrable method, for reasons such as one deploy for both website and studio, separation of concerns, organisation, etc.
Hope that helps answer your question and please
refer to the next-sanity documentation to learn more about the new approach.

Thanks , that does help. So I do need to keep the

/schemas

folder, as it is of value, and my deployed schema should be replicated in there in addition to in the second repo?

The template definitely is following the v3 convention, but I feel like there are two sources of truth here for the schema instead of a single source of truth. If I update the schema it has to be done in two places - in my original deployment and in my frontend repo. Is that normal?

That's likely a mismatch between installed dependencies. This guide will have the newer setup if you want to install it separately and compare.

I would explain the differences in depth, but since you are new to all this, it will be of little use to you right now. It would be better if you just forgot the old way existed for now, haha

Haha alright, let me check out the guide you linked and get back to you if I have more questions. 🙂

Okay, I can see the benefits of using the embedded studio from the guide, but I still don’t understand what this means for my other repo with the deployed schema that I built from User’s tutorial - is this just redundant now? Should the embedded studio be my single source of truth, because as the guide suggests, having this natively built into Next means we can use Next-specific features like user authentication?

That's correct. The deployed studio becomes redundant if you host it within your website

Okay, that makes sense. Sorry for being a bit repetitive there with the follow up questions, that closes the loop mentally and confirms that I did have a redundancy (although my initial rationale for getting rid of it would have been backwards to the convention - the links helped sort that out!). Thank you again! 😃

Of course!