Latest / The MonkCast / Juan Cruz Viotti on JSON Schema, the Invisible Infrastructure Powering APIs and LLMs
Transcript
- speaker-0: Hello everyone and welcome to Red Monk Conversations. My name is Rachel Stevens and I am deeply excited today to have Juan Cruz Viatti with me. One of the best parts about my job is that I get to talk with people who are deeply passionate about their technology of choice. And when I first talked with Juan, I was so excited to have him come on and just share his excitement about a technology that I personally had not given a ton of thought to before. So we're gonna dive a lot into JSON schema today, but before that, Juan, can you please give us just a quick introduction to who you are and what you're doing? speaker-1: Yeah, sure. Well hello everybody and thank you again for having me, Rachel. And I'm Juan. I'm a I'm the founder of Source Meta. It's a company fully dedicated to JSON Schema. I'm a member of the JSON Schema Technical Steering Committee and that's the organization that manages the standard. And I have a lot of experience using JSON schema at scale and even at research when I was at the University of Oxford. So I have been very deep, I think, in the rabbit hole and I found some really cool stuff. speaker-0: Very cool. And we're excited to dive into all of that. But before we do it's like when you first talked to me, I didn't even realize that there was a JSON schema technical steering committee. Like, what is this committee? What do you do? Where where do you meet in like a secret layer somewhere? Like speaker-1: Yeah, good question. So Jason Schema, it's a standard schema language. It is used to describe the structure, the meaning, and the constraints ⁓ of data, of information. And it's one of those things that it is like so important, so pervasive everywhere in society. And I think we can get into touch in into some of that later, while still at the same time being quite unknown. And I think what you are expressing is what we tend to hear quite a lot, is that that thing that it's covering so many things. But nobody knows because hopefully it's because it just works, right? But yes, there is a Jason Schema technical sitting committee. We even have a yearly conference in Paris in December. So if you go wanna come hang out in there, we have an entire track of talks around Jason Schema. And we also have a pretty big online community as well as Slack channel, monthly open community working meetings, office hours, a whole thing. speaker-0: Game for a trip to Paris, so mark me down for December. All right. But like as you mentioned, like this is a technology I think that has largely kind of flown under the radar. ⁓ for a lot of people, they haven't paid attention to it. But the technology is, I don't know, roughly 20 years old at this point. Where are people like, where could they be seeing this technology if they knew to look for it? speaker-1: There go, looking for it. Yeah, so if you're working in the API space, it's extremely hard to not come across JSON schema, though funnily enough you might not even realize that you're coming across JSON schema. I think that's ⁓ the irony of all of these. If you're working, for example, with open API, the open API specification, which is so widely used in the world, it builds on top of JSON schema. So when you're using an open API spec, when you're writing an open API spec and you're defining the endpoints and you're defining the HTTP headers and you're defining the query parameters, you're actually using JSON schema within the OpenAPI specification. This is the same usually if you are using async API, similar API specification for the event-driven world. And more prominently now though, if you are using MCP, as as a lot of people are actually doing now in the in the AI world, MCP is also totally built on JSON schema. When you're defining tools on MCP, you are def actually defining them with JSON schema. So It's actually everywhere and AI is one of the most interesting aspects of it. I think AI is one of the major adulters of Jason Schema turns out. speaker-0: Very interesting. And so a a major driver of usage of the technology, but people maybe don't realize that the technology is under the cover. speaker-1: Yes, exactly. And I think that tends to happen with more like infrastructure tooling, right? And infrastructure languages in the world. It's usually powering all of the cool things that that we do in modern society, but we never actually realize it's there. And I think Jason's scheme is a perfect example of that. speaker-0: Yeah. So is is it fair to call open API like a wrapper around JSON schema or is it like an abstraction line or speaker-1: Yeah, well and I think you're touching on the on the right thing. We we like to think about it that way is that Open API it's a rapid format that lets you use JSON schema to describe APIs. So when you are defining your API spec, you are defining the endpoints using JSON schema as a language, but then the actual content and the data, which is which is the important part of the API spec, you do it with JSON schema. And and interestingly enough, We've done a an analysis at some at some point in Source Meta. We have we analyzed a big data set of open source open API specifications and we found out that in I think over like seventy percent of the content of a big open API spec, it's the JSON scheme aspect. So that's what tends to dominate in any production use case, right? It's like the ratio is pretty high. speaker-0: Gotcha. And so I I think when we talked previously, your your kind of general view of the world was that we as an industry are sometimes operating at not the correct layer. So rather than adjusting the JSON schema, we're adjusting things in open API specs. Talk to me just about what you see as those like the differences between those layers and what is kind of the the structural thing that is preventing engineering organizations from having a schema first work. speaker-1: Yeah, awesome. So and and I think an example would make that even more clear. So take the average big enterprise. These at at that scale, for example, your favorite pub public sector, you know, government or whatever, most of them actually use JSON schema quite a lot. They these these kind of like big institutions, they are gonna be ⁓ developing and managing a lot of APIs, like usually in the thousand, right? I think there was a study very recently that found out that like over fifty percent of companies with ten thousand employees or more have at least 1000 APIs with a lot of endpoints to actually manage. Right? So in that context, I mean think about you might be developing so many APIs by totally different teams potentially in different places and in different offices with different managers and different objectives. Right? You have this entire ecosystem of APIs. What we see is that people try to apply, I mean, to manage that that that chaos potential chaos and like extain the complexity of such a thing. They try to apply API governance and we've probably seen, you know, how much of a fuss API governance has been. But what we see with Source Meta and the problem that we're trying to solve is that when people approach API governance, they usually apply it at the open API level and get stuck there. They never go one level below. And what tends to happen in in consequence is that you might have again 10,000 open API specs. In isolation, they are perfectly fine, right? But collectively they are a bit of a mess. Why? Because if we take for granted that most of an API spec is JSON schema, you're actually not governing at the right layer. So again, you might have 1000 open API specs, but your schema layer, which is supposed to be the substrate behind all of those, it still gets silo at the at the open API level. So again, you get into issues where each API defines kind of the same thing over again in a slightly different ways, right? Then you pay the integration cost, the coordination cost. There is no unified single source of truth of what something means, for example, in the context of a of an organization. So you get all of those problems they kinda get put in the shelf and and ignored because people don't think about usually the schema layer as a thing. However, that's actually changing. speaker-0: Gotcha. And so what would be the benefits of kind of having better governance at the schema layer? It it sounds like it's less duplication, ⁓ and what else? Like how how should people be thinking of that? speaker-1: And and yeah, and I think the core of it is coordination. I think the the amount of coordination cost that you pay for actually again operating in silos and not on a common shared vocabulary language is huge. In fact, I was I was reading one book recently. It's called the use of knowledge in society. And they were claiming that knowledge coordination is a main ball neck in innovation in civilizations throughout history. And I think that's the same kind of today, and even getting even more explosive given given AI. So again, if you would have a s single source of truth, for example, defining certain data modes that you operate in your organization, then everything taps into that, whether that's your open API specs, your MCPs, your databases, your data sets, if everybody actually talks about the same thing in the exact same way, everything that you build on top gets deduplicated. So again it's less work that you're wasting for doing the same things over and over again. But then everything connects better. And when they connect they connect better, you can get, I guess, benefits out of that information a lot more, right? With or without AI. speaker-0: Got it. And this I feel like ages me perhaps, but when you talk about it that way, it makes me kind of think of like my ye olden days of somebody wanting a data dictionary at work. Like what is the difference between what a JSON schema can provide versus kind of that that exercise of single source of truth that we've written down in a document somewhere? speaker-1: So I think JSON schema has come to prominence as the most popular schema language out there. Again, like if you look at AI, if you look at, for example, ⁓ APIs, even in governments, we have this study where we found out that all of the G7 governments were heavy users of JSON schema. And I think, I mean, the so there are two parts to that question. One, I think JSON schema won, clearly. I think this schema were, if you if it was any. ⁓ because it's actually very expressive. It allows you not only to define a structure. But to define advanced constraints and semantics on top of the data. So I think that's what made it a a in a way like the technology that could satisfy that vision of a data dictionary somewhat ⁓ at scale. But I think yeah, it's the same idea, it's just like the the the current expression of that and and maybe XML and XML schema used to be a bit of that in the past. speaker-0: Mm-hmm. When you mentioned the word semantics there, just ⁓ made me pause up because I think one of the things that I have seen in conversations of late as developers and engineers continue to adopt AI in the way that they are generating their code, they've had to pay less attention to specific semantics and more attention just to their intent and their architecture and how they're thinking about things. I'm curious how you're kind of thinking about JSON schema. as kind of a main driver for one of the layers of AI ⁓ with MCP and also at the same time seeing developers kind of move into a different direction and how they're thinking about semantics. How how are you kind of just seeing that in your world? speaker-1: Yeah, and and and there are two things to that. I think even beyond MCP, I think people don't realize how pervasive JSON schema is. And as we call it, I think it's like the language of AI, like the one and only. If you look, for example, at all of the major providers of AI in the world, all of them when they ship, for example, structure outputs, which is an API for actually interacting with LLMs based on well defined data structures. The only language that they actually support is JSON schema. All of them, like literally all of the major A LLM providers, it's the one and only schema language that they support. So then as a consequence, a lot of the AI pipelines are all JSON schema based almost by definition. And I think what that's bringing from the AI point of view is that if we take that LLMs now are being used to write code, and I think they're getting quite good at it. You might argue that it's not, you know, the same level of a senior engineer yet, but I think all of the arrows are pointing into that trend that AI is actually gonna get better at writing code. I think that's inevitable, whether the time scale is long or not. It's a different thing. But assuming that writing code, writing functionality is getting commoditized in the world, that you can describe something and the AI will just like do it and it will do it really well. That means writing code, it becomes the solved part of the problem. What that means in turn is that the interface and the contract and the blueprint of what you're trying to create, then that becomes the most important thing. So I think we could envision a future where we as software engineers, we might be purely operating at the blueprint layer, right? Like, for example, using things like JSON schema or MCP or OpenAPI to define really what we mean, have like sort of an executable blueprint. of what we want to accomplish and then handing that over to the AI pressing a button and saying, hey, now generate me this. ⁓ so I think if any, it sounds like the world is going more into this interface definition thing, which is where JSON scheme actually actually shines and it's already deeply embedded in the AI space. So I think it's the it's a natural thing to occur. speaker-0: Very interesting. So talk to me about what you're ⁓ doing at Source Meta. What what is the company trying to tackle? speaker-1: We are defining an entire ecosystem of both open source and commercial tooling for actually being able to use JSON schema at scale. And what I mean at scale, for example, consider that Italy and France, for example, now they are inaugurating schema registries national wide, right? That's actually a thing that they do by itself and they are publishing schemas and and data modes with JSON schemas as directly a public good. And to give you, for example, a sense of the scale. Italy, the the API catalogue of Italy has something like fourteen thousand ⁓ I think like like ⁓ actual APIs or like e-services to say manage it. So think about that massive amount of scale. When you're trying to actually use JSON scheme at that level of scale, you're gonna reach into many blockers, right? Both in terms of tooling and for example development tooling on developing all of these data moles. how to actually govern them and so forth. So one of the flagship products that we have, it's a JSON schema registry that you can deploy internally or externally at your company or public sector, for example. And that's a brain that knows about all of the schemas and the interconnections between them, offering APIs for discovering them, for connecting them into your open APIs or NCPs and reason about these single source of truth in in your organization. speaker-0: Very cool. Well, how how big is your team? speaker-1: ⁓ it's just me, pretty much. Yeah, it's all a small bootstrap kind of stuff. And and I think that that raises an interesting point, right? When people when people ask me, well, you're approaching something quite big, right, with something like that. And I think the model of a bootstrap small company, funnily enough, it's I believe it can yield better results at core infrastructure products, because you don't have the wrong incentives of something like, for example, a BC involvement or for example, growth or die. Right. Or for example, multiple people to actually coordinate on on the vision and execution of something cohesive at scale. I think interestingly enough, this model which which I've chosen by design, it seems to be better suited at at actually building and pulling off these foundational technologies. And I think there are plenty of examples in the world out there. I think it's a it what it's it what i it is what can get you a cohesive thing in the end. speaker-0: Agreed. And I I I think there's plenty of times when that small by design is the correct ⁓ approach and I think we're probably going to see that more and more ⁓ as AI helps augment people's ability to work on their own. So yes, very cool. speaker-1: Yeah, exactly. And I think I mean, maybe something interesting, I think, to touch on this is that ⁓ which I find very, very fun, is that I think the idea of representing data well, right? For example, the semantics of data or the structure of data and so forth, and for example, documentation also of your APIs is something that we, I think, in the tech industry we have been repeating for ages. I think everybody knows even before AI that they should probably have need to have good documentation for the APIs. or good, for example, API definitions. Right. But still I think a large portion of the industry was not paying attention, right? It is it was always like a secondary concern. And I think what made it pretty interesting is that with the rise of AI, now you know we we we might completely ignore the humans and and the documentation for the humans, but when it comes to actually produce documentation so that AI can actually perform better, then we're all in. Right. It's that we completely ignore the the the the humans when we get the AI VIP treatment. And I think that's giving like a massive trend on now can we actually define our data in like such a good way so that the AI can navigate everything completely transparently. And again, it was the same thing before, but now but now because it's AI and not humans, I think we yeah. We seem to neglect human beings. I think that's the the lesson. speaker-0: argue with you on that one. I th I think that you have pointed out a a very ironic truth in the way that we tend to operate. Well one what else would you like me to know? Any final thoughts that you'd like to share? speaker-1: Yeah, I mean I would like to to like paint I guess like a like a vision of that feature. What does it look like if you are actually managing so many APIs with a very cohesive single source of truth? For example, imagine that you have an API catalog that lists all of your APIs in there and they all tie together into the same data definitions and you have consolidated that very well and all of these data definitions are rich. You don't not only know the structure, but you know very specific constraints. you're mapping to international standards, for example, when impossible, and you ha you're augmenting all the operations that you do across APIs or MCPs with plenty of semantic information. It turns out on w when you achieve that, you can actually go and point an AI to your three thousand API catalog and ask it to do something. And you will actually do it completely smoothly. Well actually understanding everything, navigating everything, knowing how to join information, right? How how to go through many hopes in that. And I think that's something that it's not the case at the moment. And and people are realizing that and they are acting upon that. And again, many enterprises and public sector institutions are like the the proof of that. And some are actually working with us at Source Meta. So that's kind of cool. I think we are we are going in that direction and and finally unleashing that that vision. I'm very excited about that. speaker-0: Very cool. Well Juan, thank you so much for carving time out of your day to talk with me. ⁓ this has been so much fun and I love learning about fun, nerdy things with people who are excited about them. So thank you. speaker-1: Yeah, thank you very much and and yeah, pleasure for being here.