Supper Club × Simen Svale Skogsrud and Espen Hovlandsdal from Sanity

Welcome to syntax.

On this supper club, we have Two awesome guests from Sanity, one of our favorite sponsors over here at Syntax, and we're gonna be talking all things Sanity, we have Simonsfell and Espin Hovlandsfall.

Hovlandsall.

Hovlandsall. Hovlandsall. Yeah. Yeah. Go for it.

Okay. Chris, you can use the best one of those. Okay. Mala.

Yeah. We're we're gonna be talking all things Sanity today in just a little bit about What they have going on over there and and just about how awesome Sanity is overall. My name is Scott Taliski. I'm a dev from Denver. With me, as always, is Wes Bos. Wes, what's up? Oh, not too much. Excited

to chat with the folks from Sanity.

It's it's funny. We've had them sponsor for for so long, but we've never actually had them on the podcast. And now that we've been doing these supper clubs now, it's kinda fun to bring people on and and have them talk about the stuff that we've been trying to talk about For for all these years, why don't you guys give us a quick introduction of of both who you are, and then as well, Why don't you give us a quick rundown of what Sanity is? I'm sure most of the audience knows, but I I'm always interested to hear other people's, quick rundown of what it is.

I I'm Aspen Hovlandstall, as, Scott very correctly pronounced. Very, very nice, Nice one, Scott. I am a, principal developer on the studio team at Sanity, and I've been, been with Sanity for 6 years now.

So So it's been a been a journey, and, I live in Oakland, California currently.

I'm, Simon Sveil. I just given up on I'm pronouncing my last name. It's actually but, like, who cares? So so I'm so so I'm the CTO, and I'm a cofounder, of Sanity.

And Espen is actually the first Developer at Sanity who like, you're the first one who kind of worked full time on Sanity. Right? The 1st person in the universe, actually.

Yeah. Yeah.

Yeah. That's us. Oh, you're the low down on sanity. So as you know, sanity is not a CMS. Like, that's what it is. It isn't. It isn't a CMS. It's It's very important for to us. Now so sanity for us, it was something we created because we used to be an agency. We were frustrated with the kind of content tools we could give it to our customers.

We wanted a not CMS that was, totally customizable where we could build Exactly the kind of content authoring experiences that our customers needed. We wanted to be able to give them, like, awesome ways of working with their content that was kind of specifically suited to them. So we wanted the the CMS, the not CMS, to be open source. But also, we wanted a a hosted back end. We want we didn't wanna deal with all of that Kind of running and scaling a back end.

So we wanted a completely, completely separate, content database that was globally kinda distributed on all of those things. And we wanted to be able to have real time collaboration like Google Doc style collaboration on any kind of kind of data structures. So that's what we made, and, that's what Sanofi is, I guess, in one perspective. Is that fair, Espin? Yeah. I think that's a pretty good summary.

That's awesome. I'm curious, about Like, I think we can all understand the types of stuff that this might be used on a website where you have different pieces of content, and they can be related to each other, and you have, rich media attached to that and and whatnot. Like, you can kinda see that. But I'm curious about, like, other use cases, for Sanity. Like, What are some other stuff that people are using it for? So some people are are using

this to run, Like, is it like, they are using it to run, emergency health care training doll Programs that create contents for emergency health care training goals.

Burger King actually runs part of their Greens on the kind of equipment behind the counter, like, where the kitchen staff works to kind of Mhmm. Operational information for for for that. So they have integrated everything from, like, the DoorDash app and down to the various screens on the people who've actually actually flipped the burgers, are run from the same single Source of truth.

Of course, a lot of people use Sanity to power apps because the one of the things that was important to us is Even though it's, like, excellent for web apps, Sanity always keeps your data in a form that is not there's no HTML. There is nothing kind of special for a specific display technology. We don't even keep your images in a specific crop. We a crop insanity is like, want to keep this part of the image, and I don't want to use want you to use this part of the image. And then we can kinda recrop that image for any form. So as soon as you redesign your website or you use your content elsewhere, That is kinda reshaped or can be reshaped. So so all kinds of stuff. But I think the real power comes out when people are using their content, the same Piece of content in lots of different contexts.

Yeah. I I think that that's good. It's like it's no longer just a website.

Now it's obviously been a website and a mobile app now, but now it could be a website and a mobile app and and, somebody who needs Integrate Burger King signage into it, you know? Like, it's kind of nice to not have you don't start Your data as a website CMS, you start

kind of a layer back, which is just like you. What do you call it? The content lake? That's where everything goes. Yeah. What what is that content like? Yeah. Yeah. Good question. Like, my thinking, when we when we kind of frame Sanity was, like, I want Sanity to be a place where, like, Every piece of data that I want to present to an audience should be insanity. Like, if my my my my my my stock in my store, My my the president thought, do I have bacon in this specific franchise right now? All kinds of information that I want to present to an end user, to an audience, should be kind of something should be suitable for that. So we thought it's similar to a data lake. Like in analytics and marketing, you have you you feed all of your different piece of information from all of our sources into a data lake so you can ask questions. Anything you wanna analyze, any questions you want to be able to answer, You feed it into the data lake. So we thought, like, this is like that, except it's for content. You want all of your content in one place, and now you're free Free to data. You have one API for all of our content. A lot of teams are always waiting for someone in their organization to build, like, a bespoke API to solve some problem or other. As long as, you get your content into Sanity, kind of all the APIs are there, and every team member knows that API. So that's kind of the idea of the content like

Cool. Well, let's Talk about Sanity Studio 3.

So Sanity Studio is the UI I guess, like, the editing experience, The not just the UI editing experience, but, like, you can see where what other people are doing. And I always thought that was it was kind of neat the way that you've approached that in that, these the Xfinity itself is hosted for you, but the, like, actual, like, editing UI, you have access to the code if you wanna change that.

Do you wanna wanna talk a little bit about that, and then we'll go into, like, what 3 point o is? Yeah. I can talk a little bit about that.

The, the studio has always been a React, single page application, like, even from the very first version.

The reason why we chose React was, of course, that there was a lot of developers that were familiar with it, and we wanted to be able to provide, like, a really easy way to customize the studio.

So have people write these custom input components and tooling that they might need for their, their business, basically. And write that in if, technology that was familiar to them. So we didn't want to, like, go all the way down to something like just Plain old JavaScript, but, React seemed like a good choice.

And I think that power really comes out, over time, has Showed itself over time. So the version 2 was like this framework you you span up like a dev server when you run sanity start. It started like a a that classic stack that you're might be used to, like a webpack dev server.

And you have this, like, single page App running in your browser, you could edit these schema files and all of the custom components that you might have in there, and you saw everything like hot reload.

But, what we've done now with b three that really shows the power of using React is that it's now, We're taking sort of a step back from from, using our own tooling for all of this. So right now, it's really just React components all the way. So you can actually take, like, a a React component called Sanity Studio, and then you can embed that inside of your existing application, using React. So that opens up a lot of doors. It's a lot easier to for people to understand, I think, as well because it's, you can for instance, you can use things like Next. Js, and you can then have a slash studio router slash admin if you wanna go the old, Familiar paradigm of having your app in a page? Mhmm. And, you can then just mount the Sanity studio react component in there, pass it a configuration, which is just JavaScript, and that will it will then Take a look at that and render out the UI, which I think is really powerful and differentiates us quite, significantly from a lot of these other things Because that means that you're basically inside of your own app. You can reuse all of the sort of, react components that you might be using in your website

Inside of your Sanity studio. Oh. It's the exact same code base. Yeah. You know, it was it was fun. When we first had a demo of Sanity for us.

Y'all put us put together a a syntax.

I think it was like a syntax, Just a a project for us where you would import it all of the episodes and everything, but then embedded directly into that content editing experience is, Like, the actual player that we're using from our actual syntax site. And I think that highlights it really nice just, like, Just the ability that you you said you have the ability to use the things that you've already built inside of your editing experience and get to experience that content in a way that's more, I don't know. Feels integrated rather than just to hear some database tables or something about your your application.

And are are you seeing people using that for, like, a live preview or just be able to model what something might, like, render out to on the page. Is that what it is?

Very often, that is, one of the first things that people have done. And so in the past, it was very common for people to use, like, an iframe approach Where, in the TV version 2 of the studio where you have, like, an iframe, and that would render, like, a slash preview version of your website or something.

But the real power, of course, by having the studio integrated into your codebase like this is that you can do it much, more low level. Like, you can actually get the data and just pass it directly down to, like, a React component and then render that in line.

So that's something, that I think we will see much more of going forward.

We just released, at the time of this recording, at least. We just released the the New version, so we're kinda keen to see what people build with it, but I I think that's definitely, like, a big, wow factor once you Once you get all of the components, they're rendered directly into that preview pane. Oh,

one thing I think is amazing with this, The solution is that now, Sanity is just a React library, like you said, Espen. And you can't take Sanity to this. Like, this is used by huge Corporations that would deploy like 700 different studios on Vercel and whatnot. But then also now you can also have this super tiny simple project, like, few files.

Sanity just as 1, like, page on your on your single project with, like, your entire website and also your CMS in one thing. But still your content, like, your kind of data management stuff is still offloaded, so you don't have to think about that. So you can have self everything that you care about changing and everything else is going to be taken care of for you. Yeah. That that's really cool. I'm curious about now you're talking about React components.

So what what's the let's say I'm building a rack component that, lists out a list of pizzas, And that data is insanity, and I wanna put it into my React application. Does does any of this new Sanity 3 point o Self help with that or am I still choosing my data fetching, caching, Grok or GraphQL or any of that. Am I still choosing all of that those decisions myself in my React app? You are choosing that yourself. I think it's very important for us to Try to maintain that sort of headless,

experience. I mean, we don't really like that term as much, but we do wanna think it's important that our content Should be, like, totally agnostic to whether where you actually want to use that content, and so we don't wanna be per like, super prescriptive on whether you wanna use GraphQL or, Grok or any technology really. Gatsby has its own, like, source plug in to fetch data from Sanity. So it's, like, It's up to you how you wanna fetch it.

I'm sure we will provide a bunch of tooling over time to make it easier, to use, in different frameworks, we already have, like, a preview kit for Next. Js, for instance.

But, for the most part, we we wanna leave that up to the user, in terms of How you want to render that.

But I could definitely see us, providing some kind of data binding libraries down the down the line for React specifically since it's so Key to sort of the sanity experience in the studio. It kinda ties really well together, I think. Totally. What so, Grok,

What can you explain to the audience? What is Grok and, maybe a little bit of why why, You all landed on Grok, essentially. How did that happen?

We were, of course, looking at GraphQL at the time.

We really like GraphQL, but our view on GraphQL was that GraphQL is actually a language for implementing controlled APIs. It's like when you wanna lock down your API, that's where like, it replaces rest. It's just a huge improvement on rest.

What it isn't really good at, is like general curious. Like, I don't know what's the shape of my data. I don't know, like, there doesn't have an API yet. Like, how do I Describe how I want to fetch all of this data.

So Grok is kind of designed as kind of it's it's like SQL when When, when GraphQL is like rest for the future, let's say that. So so in a sense, it's general query language for JSON. And the way we designed it was it was Optimized to be great at powering GraphQL API. So it's kind of great at being the kind of thing behind the GraphQL API. So, actually, our own GraphQL APIs are just kind of translations from GraphQL to Grok, and then it just passes it down to the content page. Yeah. I I thought like, the 1st time I saw Grok, I was like,

Oh, like like, what are they doing making another like, we have GraphQL, but then, like, I I got into it. I thought, oh, okay. This this actually makes sense is that You might not necessarily know the paths that you want. And then the one thing that really made it click for me is the Grok webhooks, Which is you can basically say, I want like, when somebody buys something or, when an image is updated or or literally, you can describe any state with the the query.

And then when That query matches what you want. It will fire a webhook, and then you can rebuild your site or send a notification or or whatever. So I thought that was That was really cool that, you could do that inside of of Sanity. Did you all notice any bit of pushback

On the grok front from people who are wanting to pick up Sanity, was that ever a, concern you had? We knew it was going to be a controversial, So, decision, like, we wanted definitely, like, just to be able to say we're using GraphQL. We know everyone would be asking because, at that time, everyone knew GraphQL was the next big thing, but also very few people knew actually what it was, in any detail.

So so so that were kind of a a challenge.

I kind of knew like, I we worked a lot to not make rock, to put it that way. Like, we really didn't want to make rock. It just felt completely necessary.

So I'm actually more surprised.

So I was actually more surprised about the lack of resistance. Like, I I see people are more about Grok than maybe even I am, because I feel like, people really like that it's It's open ended. It's fast. It it what what happens is a lot of the knowledge about the information you need and how it's supposed to be put together Ends up in your in your front end, in your specific client, which is kinda nice because now instead of having loads and loads of different APIs made for your different apps, the noise is Actually, in the app, that's kind of amazing and cool and makes lets people work fast. But also it's problematic problematic because it makes you not have controlled APIs. If your data changes, your API Slightly changes. So, actually, I want to move in a direction where we use Grok to power graph GraphQL kind of proxy APIs. And then those can be kind of Stable and controlled. But I think for most projects, it turns out Grok is better than I expected.

It's super suitable. Even for huge companies are using it for for a lot of stuff. So Yep. Nope.

Surprisingly successful.

I think it's super interesting how, like, how how we just expected everyone to to sort of have that, that that reaction to it. Like, what it that that you just described was, whereas like, what is this new query language? And I I think it's so fascinating to see how many of our customers are actually never reaching for, GraphQL or any other thing. Like, once they once they take a look at Grok and start using it, you really just Start to love it because it's so easy to describe what you're actually looking for.

And once you just understands the sort of, like, Couple of, couple of things like filtering and project projecting, you can then reuse that for any query. And it's really easy to To, like, take that knowledge and then just play around with the query until you get just what you want. And, yeah, it's so nice to be able to, like, write a query that Just like maps over an array and picks out that 1 property that you want and then aggregates that into, like, a single string or something.

I guess, it's a lot faster than writing a

totally new field inside of a GraphQL API that then does that operation for you. You could just ride it straight into the query. So it's it's it's super nice. It was kind of shocking to us, like, when we saw the kind of queries that Sorry. Coming in very early on. People basically replacing half the of their kind of like, all of the code that was, like, fetching data and baking it, preparing it for rendering was kind of basically replaced replaced with 1 single huge query. So we realized, like, okay. We have to optimize this thing to do, like, huge queries, because people just wanna do 1 single query.

So yep. Yeah. I mean, it's almost problematic, I would say, that people end up with these. Like, they they wanna put everything into 1 Grokery. They they wanna, Like, replace their entire back ends, but you would just want to get the query, and then that's very hard to optimize, I would say. Yeah. Totally. That's the same problem in GraphQL. Do you do you find people

outside of Sanity using Grok at all?

Has it, like, caught on anywhere outside of your own tools? No. So it's important for us to say that we it's open source in terms of the the specification is open source. There's an open source JavaScript implementation of this.

We so we we won't say it's proprietary. It's not like although it kind of is because it's only us running it. I kind of it's interesting to see now that other CMSs are getting, like, feature requests to add Grok support. It's pretty hard to to support those. So so that might take some time. So What what are your thoughts about GraphQL? Because when GraphQL came out,

that was it. Everyone's the next thing, everything. And here we are, probably 6, 7, 8 years later.

Is is GraphQL still it? Like, is that the best way to to query data and to use in a website? Or, should we go back to rest, or is there something else?

I have a lot of opinions on this. I think, GraphQL is, I think GraphQL is a really powerful, way to build APIs, but it does require you to understand the sort of The pros and cons of GraphQL. Like, I don't think people, really think too much about changing data over time and the stability of GraphQL APIs Because people think that it's very easy to, I can just add a new field, or I can just change the the The way this field is, returning this data, but then you're breaking sort of the the contract for that API.

And I think If you just have a single consumer of that API, that's fine.

But in a lot of, ways, it's not what was intended for. It was meant To be like that that stable thing that could evolve over time.

But I do think it has a lot of tooling that rest Sort of lacks, or at least traditionally, it's it has been a lot more fragmented.

There's, like, tooling, of course, for rests, but it's so fragmented. It's, it's, like, 5, 6, 7 different tooling, alternatives for what GraphQL provides built in. So just having, like, A single way to document an API, a single way to mark a field as deprecated, being able to to ask The GraphQL API, well, not the API, but, like, there is a built into the tooling, like a way to check for, For breaking changes between 2 versions of a GraphQL schema, things like that is super super powerful with GraphQL and something that I always miss when I go back to rest.

But there is a certain, like, there is, of course, every once in a while, this, like, This feeling of GraphQL being a little bit of a pain in the ass to to sometimes operate a GraphQL Yeah. I I will say, especially if you're building, this for external consumers, it's hard to know, where to draw the line because it's You can build these arbitrarily deep nested complex, operations. Like, say, the GitHub API where you have Repositories and users and favorites, and you can go all the way down on these things, which will provide A lot of flexibility, but it also, is, like, impossible to scale, basically, because you're fetching basically All the data that's in this other service.

And it so I think it's like it leaves a lot of power up to the consumer, which Can be good, but it can also be very complicated for the person who's gonna scale this to actually be able to do that. Yeah. Because you don't know if you're running expensive queries on the client side. You're just telling,

give me this, give me that. Yeah. Yeah. And computing,

You kinda want a a computer cost upfront if you wanna block that. Like, GitHub, we probably has some limits.

I'm not Sure. On the details, but, like, if you have x amounts of nodes that you're fetching, it can, like, potentially block that off. But you kinda wanna know that Before you go out and fetch all of these things. Right? So it's it's complicated to write an API that has that sort of logic built in. But do you remember back in the days where we fired up, like, a 120 different queries and joined everything on the client side. That was also quite expensive for everyone. So I guess that's true. It's a it's kind of a step forward still.

Yeah.

No. I think that's the, the alternative They often see is these pitfalls where people, fall into these, component based rendering, cycles.

So with GraphQL, it's I think it's easier for developers to sort of think more holistically about what data you wanna fetch up front and then do the query, Pass it down to the different components on the page.

Whereas when you have these very, like, fragment or, fine grained, API endpoints and rest, It often leads to fetching data and, like, leaf nodes, basically.

It might be a bit of a pain.

Let's talk about workflows as well. This is kind of another cool thing that I like in Insanity is, it's not always just Somebody edits text and hits save and then and then hits publish when when they're ready to go. But Organizations are much more complicated than that, and there needs to be multiple hands