StepZen with Anant Jhingran
Anant Jhingran discusses his journey from Berkeley databases to GraphQL APIs, explaining how declarative programming powers StepZen's approach to the Jamstack.
Episode Description
Anant Jhingran discusses his journey from Berkeley databases to GraphQL APIs, explaining how declarative programming powers StepZen's approach to the Jamstack.
Episode Summary
In this episode, Anant Jhingran traces his career from studying under Mike Stonebraker at Berkeley, where he contributed to the development of Postgres, through his work at IBM on semantic annotation, to co-founding the API management platform Apigee, and ultimately to his current venture, StepZen. The conversation centers on a throughline connecting all of these experiences: the power of declarative programming, where users specify what they want rather than how to get it. Jhingran explains how this principle, rooted in database query languages, maps naturally onto GraphQL, which he sees as a constrained yet accessible query language that empowers front-end developers to self-service their own API needs. He describes StepZen as a tool that lets developers point to multiple backends and receive a unified GraphQL API in minutes, using virtual tables and semantic constructs to connect disparate data sources. The discussion also covers the pragmatic evolution of the Semantic Web through Google's approach, the organizational and cognitive reasons behind the front-end/back-end split, and why the Jamstack's emphasis on APIs aligns perfectly with StepZen's mission. Throughout, Jhingran emphasizes that openness and collaboration across disciplines drive the best technical outcomes.
Chapters
00:00:00 - Introduction and Background at Berkeley
Anthony Campolo welcomes Anant Jhingran and shares the story of how they first connected, with Jhingran reaching out about a potential collaboration. Their mutual appreciation sets a warm tone, with both emphasizing the value of surrounding yourself with people who bring different experiences and perspectives to the table.
Jhingran then discusses his academic roots at UC Berkeley, where he studied under Mike Stonebraker, the creator of Ingres and Postgres. He describes how the experience of working alongside pioneers in relational databases shaped his foundational belief in declarative programming—letting users specify what they want rather than how to retrieve it. This principle, he explains, has guided every phase of his career since the late 1980s.
00:06:37 - SQL, Postgres vs. MySQL, and the Semantic Web
The conversation shifts to the declarative nature of SQL and how it connects to modern front-end concepts like Redwood's cells. Anthony asks about Jhingran's apparent preference for MySQL, which Jhingran clarifies was driven by early customer needs at StepZen rather than personal preference—he remains a devoted Postgres advocate. Both databases serve important but slightly different developer communities.
Jhingran then discusses his time at IBM working on semantic annotation, explaining how Google evolved from purely syntactic search to incorporating semantic concepts like understanding that "restaurant" is a concept, not just a keyword. He argues that the Semantic Web vision failed because it tried to annotate everything, whereas Google succeeded by taking a pragmatic, targeted approach—adding just enough semantics to improve results without boiling the ocean.
00:15:38 - Apigee and the World of API Management
Jhingran explains what Apigee was and what API management means: surrounding externally consumed APIs with security, scaling, analytics, and developer portals. He describes how Apigee evolved from purely managing APIs to also offering tools for building them, which represents a fundamentally different challenge.
He then lays out two paradigms for API construction. The first is imperative, where backend teams write complex programs full of conditional logic to stitch together data from multiple systems. The second is declarative, inspired by databases and search engines, where APIs are compiled from backend introspection rather than hand-coded. This declarative model, he argues, is what enables front-end developers to self-service their own API needs without waiting on backend teams.
00:22:46 - GraphQL and the Front-End/Back-End Divide
Anthony and Anant explore why GraphQL is such a natural fit for declarative API building. Jhingran describes falling in love with GraphQL because it combines the power of a general-purpose query language with enough constraints to make it intuitive for front-end developers—eliminating the cognitive overload of SQL while retaining expressiveness. Anthony adds that constraints, much like in music, often lead to the most creative and productive outcomes.
The discussion then turns to why front-end and back-end development are typically separated. Jhingran attributes it partly to organizational structures in large companies and partly to genuine cognitive limits—people can only deeply master so much. He argues that APIs serve as the ideal contract layer between these domains, but the difficulty of building APIs has been a bottleneck that StepZen aims to eliminate.
00:30:31 - What StepZen Is and How It Works
Jhingran defines StepZen as a tool that lets front-end developers point to backend systems and receive a running GraphQL API in minutes, with two core functions: building the API and hosting it reliably. Anthony raises the concept of an API gateway, and Jhingran clarifies that while StepZen shares gateway characteristics, it focuses on what the API actually is rather than just managing access around it.
The technical underpinnings are explained through the concept of virtual tables—shims that describe what each backend can accept and return without holding data themselves. StepZen connects these tables by finding shortest paths between inputs and outputs, using semantic constructs to bridge gaps like converting a city name to latitude and longitude. Machine learning and introspection techniques further automate the process of generating intelligent GraphQL schemas from existing backends.
00:41:20 - Jamstack, Open Source, and Closing Thoughts
The conversation turns to the Jamstack, which Jhingran enthusiastically supports as a return to simplicity after decades of accumulated web complexity. He highlights that the "A" in Jamstack stands for APIs, making StepZen a natural fit for providing the data layer that powers both static and dynamic Jamstack sites.
Anthony and Anant close by discussing the value of open-source culture, with Jhingran emphasizing that openness—more than open source code itself—has democratized software development, allowing smart people from non-traditional backgrounds to enter the field. The episode wraps with mutual gratitude and Jhingran's reflection that building great technology takes a village and that every day should bring new learning.
Transcript
00:00:00 - Anthony Campolo
Welcome to the FSJam Podcast.
00:00:15 - Anant Jhingran
Thank you so much, Anthony.
00:00:17 - Anthony Campolo
It's a real pleasure to have you here. I always like telling the stories of how I got to know our guests and my first memory of those guests. I have a really good one for you. The very first time we ever spoke.
00:00:33 - Anant Jhingran
Oh my God, you're going to embarrass me now.
00:00:35 - Anthony Campolo
You reached out. Totally out of the blue. And you were just like, hey, are you with Redwood or are you interested in other opportunities? And that was it. What I loved about that is it was so to the point without being rude or anything. You were just like, hey, we're interested, you know? And I thought that was really cool because, for me, I was at a point where I was so desperate for anyone to even notice me, to give me any sort of baseline-level job, to do anything.
To have someone with your experience, who had something pretty cool going on, reach out to me meant a lot. So I'm really happy to have you here. I'm really happy to talk about this stuff you're working on, and I'm really glad to be part of this whole thing you’ve got going on.
00:01:32 - Anant Jhingran
Hey, Anthony. Listen. This is awesome for you to say. I don't know whether you saw, but I was kind of blushing when you were praising me. I think it's actually the reverse, which is true. As you know, Anthony, I strongly believe that life is a lifelong journey. We know some things and we don't know some things. And you always try to learn whatever you don't know or whatever subset of what you don't know.
In my view, I learn from people more than I learn from reading and all that. I also read, but to me, surrounding myself with people who have different experiences and different perspectives is a very important part of who I am. So it was just a pleasure to reach out to you and get connected. And then finally to be able to convince you, given all the things that you know, to join us on this journey was an absolute pleasure.
[00:02:24] I went and, though I don't drink wine much, opened up a bottle of wine that day. I was just really proud. Thank you.
00:02:32 - Anthony Campolo
That's awesome. Yeah. And I didn't take much convincing, let me tell you, because it's really cool tech that you're working on. We're definitely going to get into it. It's around a lot of the stuff that we talk about on this podcast, which is why I think you reached out to me because you saw the work I was doing on Redwood and you saw a lot of potential synergies that could happen there.
But I'm really curious to talk about a bunch of stuff you've worked on. I think you're someone who is very forward-looking, so you probably don't talk about your past accomplishments very often. But I think some of the work you've done is pretty cool. I'm someone who finds the whole academic world and the research being done there really interesting. There's some really cool stuff in terms of how it eventually filters down to the actual tech we end up using.
And you've done some really incredible work with databases. So I'd be curious to get some background on the work you were doing in Berkeley, the type of people you were working with, and why that's significant to the whole database universe.
00:03:46 - Anant Jhingran
I let others be the judge of whether my contributions mean anything, but I'll tell you what I learned. I came to Berkeley, I was from India, and I came to Berkeley because, of course, Berkeley was cool. But also there was a professor out there, Mike Stonebraker, who some of you might know. Mike Stonebraker was the inventor of Ingres, the first or the second relational database, and then the inventor of Postgres that we use till today. And I was sitting in India and I said it'll be super-duper awesome to get a chance to work with Mike Stonebraker. So that's what I came here for.
I'd already done a bit of database hacking, a very small amount of database hacking, while I was in India in my undergrad. I dove straight into what databases were and all that, and it was absolutely fascinating to be part of a community that was leading the charge. This is, Anthony, way before you were born.
[00:04:40] This was in the mid to late '80s. Just hanging around with people who had done this before and learning from them was absolutely fantastic. Even though I didn't actually contribute code to Postgres, some of my ideas and some of my thought process went into the implementation of Postgres.
Then I got a chance to move to IBM and continue that journey of building out really good, innovative database techniques. What I learned in this world of databases, which has stuck with me for a very long time, is that in the world of databases, there is this abstraction where the end user doesn't specify how to get the answer. The end user basically specifies what they want.
There have been many manifestations. A good example of this would be Google Search. In Google Search, you don't say all the things about how the answer should be gotten. You just express what you want.
[00:05:43] So there have been many journeys on this. The way databases started, which said, look, let the end user focus on the what and the database will focus on the how, has stuck with me. And as you know, in our latest journey of StepZen and others, we bring these together.
But just to finish up the story on the world of databases, what is absolutely fascinating is that databases have stuck with us in mostly the same form for over 40 years. And imagine that kind of technology. That only comes about when there's something deep, meaningful, and impactful going on. And I'm happy that I have been part of that journey and have contributed to it in some small ways. Okay, I've spoken way too much about myself, but that's what I wanted to tell you.
00:06:37 - Anthony Campolo
This comes up all the time, this imperative versus declarative type of programming. What you were saying is that SQL is declarative. You just say what you want and then you get it. And this is really appealing for people from the Redwood world because we have this concept called a cell, which is a way of making our data fetching declarative. So we're already on the whole declarative trip.
So I'll be curious then, as someone who was already super deep into Postgres and working with the creator of Postgres, you seem to be someone who tends to reach for MySQL over Postgres. So how did that kind of happen?
00:07:19 - Anant Jhingran
Ah, no, that's a false accusation to me. For me, after I did database stuff and everything else, we moved to Apigee and we did APIs, which is a very different world. Hopefully I'll get a chance to talk about it. The entire Apigee story was built on Postgres, so I'm actually in absolute love with Postgres.
It so happened that the very first person that we needed to work with in StepZen wanted a MySQL implementation. So we said, okay, let's put the MySQL implementations out there, knowing fully well that the Postgres stuff is going to come pretty soon. So I'm a bit embarrassed, but both MySQL and Postgres are awesome databases. I've got a bit of a bias toward Postgres, but it is not reflected in the way we have prioritized. That's got something to do with market and everything else.
00:08:11 - Anthony Campolo
Yeah, well, it's funny because everyone who's ever been on this show, for the most part, has been someone who's using Postgres, and it's very much embedded into our whole programming universe and the types of projects we're working on.
So the fact that StepZen right now has a MySQL connector has been good for me in terms of actually having to learn MySQL and get it spun up and see what the differences are there.
00:08:38 - Anant Jhingran
Postgres has got some awesome capabilities, as you know, for example, the ability to store JSON right in. And I've been following Postgres. Once in a while I get a chance to give some keynotes at Postgres conferences, and it's an absolute pleasure to connect back with the community that has not just created in the past, but is continuing to create and everything else.
But MySQL is also popular, as you know, in the WordPress environment. PHP and MySQL kind of come together and you try to put your biases aside and say, okay, what is it that the developers really need and focus on? And then when you look at it, you'll say, okay, Postgres for the people who are building their own stuff, and MySQL for the people who are borrowing other frameworks and doing work around it. So both are really important, but in my mind they are like number one and number two.
[00:09:27] The orders may be slightly different, but they are both really important.
00:09:31 - Anthony Campolo
Cool. Yeah. And so before we get into Apigee, there was a mid period between your database work and your API Apigee work when you were at IBM, where you were doing work around semantic annotation and this whole idea. I think it was probably because IBM was working on their Watson thing at the time and this whole Web 2.0 semantic web thing was happening, which some of our listeners may know about and some may not.
So I'm curious, what was your connection to all of that research? What did you think of the Semantic Web? Do you think it ended up happening, or did it kind of fizzle out? That whole idea?
00:10:11 - Anant Jhingran
For those of you who will look me up, you'll know that about now, 30 years of my professional life, I've done many things, including, for example, the thing, Anthony, that you just talked about. Let me tell you a bit about this world of semantics.
So if you really look at it and you say that, look, when you type something in Google and you say, find me restaurants near me, for example, which is very different than what you would have looked for, let's say, ten or 15 years back. You would have said, find restaurants near me. And at that time, Google would have tried to look for documents and websites that have the word restaurant in them, and who knows what it would have done with near me.
But today, when you say "find restaurants near me," Google understands the concept of a restaurant, which is not the same as the word "restaurant," right?
[00:11:11] So you may have, I love Indian cuisine, obviously, and all that stuff. So you may see something like Taj Hotel, or Taj, or Taj something or other, or Indian Taj cuisine. And Google understands that it's a restaurant. When the person says "restaurant," that's a concept that needs to be bound to literals like Taj or Annapurna or, for my son, Lazy Dog or whatever else it is. And then near me is a very different concept. There's a concept of location and nearness to that location.
So you can see that there has been an evolution from pure syntax to syntax mixed with semantics. And that evolution has made a huge difference in the quality of search and quality of fetching and everything else. If you really look at the goodness that Google has done, it has not gone and built out a semantic web. It has not gone and looked at every web page and said, let me try to extract the semantic concepts in this web page, etc.
[00:12:27] Two things. One is, sometimes it has actually asked the creators of the web page to meta tag the semantic concepts. So, for example, if you're writing a recipe page somewhere, you'll say put two cups of flour and this and that and everything else. This is all good. But now Google has to do a hard job of parsing through your entire thing to find out where the recipe is and what the ingredients are, etc.
So Google said, look, we are big. You go create a meta tag, we'll give you this meta tag library, and you say something like this recipe and then ingredients. And once we know that, now we understand everything else. Yes, obviously the details are there, but we have you create the semantic concepts.
On the other hand, Google says certain semantic concepts we understand, and we'll actually go and pick them out, like the restaurants example that I gave. But the point I want to make is that Google decided to do this as an example, not for boiling the ocean of a semantic web and everything.
[00:13:30] But they said, let's look at the most popular requests that people are making, and let's try to create some semantic concepts around those most popular ones. Either we create them or the creator of the web page creates them. Therefore I feel that the way to the world of semantics is through a very practical bent of mind, which is: do the least amount of semantics that are needed to improve the quality of responses. Don't build semantics as a root construct where everything has to be semantically annotated.
That is where I think the world of Semantic Web went a bit haywire because they felt that everything needed to be semantically annotated, whereas Google and others, and you'll see that in StepZen also, taking a much more pragmatic approach makes more sense. Sorry for a kind of five-minute answer. Hopefully it was useful for your listeners.
00:14:22 - Anthony Campolo
Yeah, I think that's great because it gets at where I think a lot of this data science and machine learning stuff has gone over the last five years especially, which is this idea of human-in-the-loop learning. You provide the machine enough data to train to get into a feedback loop that can then start improving.
So that's the idea that you're getting at there: you can't just tell it everything it needs to know, partly because we can't really specify everything we need to know. So we need to provide enough information to figure out the answer itself. And figuring out what information it needs is the challenge.
00:15:02 - Anant Jhingran
Even if Google has an example of an algorithmically driven company, it still has a huge army of people who go and annotate and add semantic constructs and maintain this and that. So it is absolutely obvious that humans and their ability to perceive is way ahead of any algorithmic stuff that exists out there.
Now, algorithms can apply it en masse, but a lot of intuition and innovation actually comes from people. So truly good systems mix and match the two sides.
00:15:38 - Anthony Campolo
Cool. So let's get into Apigee. So Apigee was an API management company, I believe. First off, is that accurate? And second off, what is an API management company?
00:15:51 - Anant Jhingran
Yes. So Apigee would call itself, or we would call ourselves, an API company. But it's absolutely true that we were an API management company. An API management company is quite simply that if you're building out APIs that others from outside your team use, the others can be the person in the next cubicle, when we get together in a cubicle or in an office space. Or it could be a partner, or it could be third-party developers.
When you get to your interface, your API is not just being used internally, but is being used by others. Then you want to make sure that the contract of that API is rigid, fixed, and well managed. So the right sets of people are coming in, the wrong sets of people are not coming in. You're able to deploy the documentation. You're able to scale the endpoints, etc.
So API management came about around the fact that APIs were really becoming the de facto way in which product and capabilities were being exposed to third parties or second parties, or even first-party. Second parties being partners, and first parties being your neighboring developer. For something that important, you want to surround it with the right management capabilities.
[00:17:14] And that's how Apigee came about. Of course, as Apigee came about and said, look, we are going to manage the scale and security and analytics and dev portal and everything else around it, it started to also do, look, can you actually build out an API in Apigee? Not just manage the API around it. So you'll find a lot of API-building capabilities within Apigee.
But at the core it says you have your API, and we are going to surround it and manage it. Hopefully that made sense to you.
00:17:47 - Anthony Campolo
Yeah. Last part you said about having capabilities of building APIs and not just managing it. That seems significant because that seems like an entirely different mindset that would be required and entirely different tools that would be required to do one versus the other. So what is involved with providing tools for actually creating APIs and not just managing them?
00:18:11 - Anant Jhingran
I think that's a fantastic point. So there are two different perspectives out there. There's a perspective which says that an API is just a program. So let's assume that there's an API that, given a customer's email, determines and generates the set of outstanding orders for her. When the end customer is logged in, the developer can show her all the orders that have not been delivered because she may have made a bazillion orders. You don't want to clutter the space. So you basically want to say, look, here are your two outstanding orders, or here is the expected date of delivery for those orders.
So you say, okay, awesome, I need to build an API in order to support that kind of request that might come in. Now typically in larger enterprises, the front end teams are different than the backend teams. So that responsibility then goes to the back end team and says, can you build an API for the front end team that delivers the outstanding orders given a customer email?
[00:19:13] And the back end team then says, okay, good. We've got a lot of other things that we need to do, and we've got a priority for this quarter and come back to us, etc. But when they finally get around to doing it, it's basically a programmatic exercise. Okay, let me first go and fetch something from the customer system and then extract some bits out of that customer system, and then let me go and get something from the order system. Now, let me get tracking information. Now let me go and fetch from the delivery system, which may involve a third-party call. If I find that the stuff that is coming out of the order system is gobbledygook, then I need to do something else. If I can't [unclear].
I start to write a program that goes like this, like this, like this, with all kinds of if-then-else and error conditions and other things put into it.
[00:20:02] But that is the current style in which APIs are produced, where somebody says, okay, let me write all the programmatic, imperative logic, as you said, in order to make that work. So that's kind of style one. And in that style one, you can make it somewhat more drag-and-drop where you can stitch pieces together the way we did it in Apigee and everything else. But in the end, it's really a program.
And that is why the development teams, the backend teams, say, wait, we've got a lot of work to do, and we've got to test it and scale it and everything else. So that's kind of one style of building out the API.
The second style of building out the API is what we are trying to do in StepZen, right? You're very familiar with it, and it borrows from the world of search and the world of databases.
[00:20:54] That is, in the world of databases or in the world of search, I'll give you both examples. In the world of databases, as I said, you don't actually specify how. You just specify the what, right? So you don't write a program for every question, Anthony, that you might ask. There's no way to write a program for every question that you might ask.
Similarly, in Google, while it's true that the Grammy Awards is a common query, and they could write a program which says, give me the best information of Grammy, there are just so many questions that billions of people can ask that they cannot write a program for everything else.
So if you figure out these two things, then you say, okay, there is a different way in which APIs can be built, which is they get compiled in as opposed to programmed in. And is it possible for APIs to be built in a way in which backends can be introspected? You can determine what this backend can do, or this backend can take X and return Y.
[00:21:49] This backend can take Y and return Z. This backend can take Z and return ABC. It never is that perfect, but then you can say, okay, good, now I can connect the dots and make things happen. So that's kind of the second style, which is a declarative style.
And what we believe in, in StepZen, and I'll just give one minute of plug out here, we want the front end developers to be able to self-service the API that they need. And what we don't want is to have them write all the if-then-else and all the other conditions that come about with protocol translation and errors and when to cache and everything else, because those are really backend concerns, not front end concerns.
Therefore we strongly believe that a declarative style of constructing the API is the way in which front end developers will get control over their APIs. So there is an imperative style, and there's a declarative style. We are pushing for the declarative style.
00:22:46 - Anthony Campolo
Yeah. To me, this is why people really like GraphQL in the first place. Because when we talk about this imperative versus declarative, I couldn't really think of something that could be more declarative than GraphQL because you're literally just saying, I want this thing. And then you say, I want these things from this thing. And then it gives you those things. And that's the whole deal.
So before we explain what StepZen is and all that, I'd be really curious. What was your first exposure to GraphQL?
00:23:20 - Anant Jhingran
Oh my God. It's rare at my age that you fall in love with something. It was just awesome because what I found in GraphQL is exactly what you said. But I actually found something very interesting: what GraphQL did was, in my mind, a phenomenal blend between a very general-purpose query language.
So what happens in a general-purpose query language is that there is still a lot of cognitive overload for the front end. What tables exist? Do these fields exist in these tables? Now, of course, some code plugins can make some things happen, etc., but there's still a lot of overhead in being able to construct the right query and everything else.
And in GraphQL, that burden basically goes away because you're only allowed to ask certain things. You don't have to read any doc. What you can ask is known. GraphQL tools are phenomenal. The back ends kind of self-describe themselves, et cetera. So I just fell in love with it because I felt that it took a general-purpose query language and put enough constraints on it to make it much more accessible and useful, right for the front end developers.
[00:24:36] I mean, if you poll your colleagues, they'll say, yeah, we can do simple tasks in SQL. But at some point, SQL gets very complicated, right? Even I have to sometimes open up the handbook of SQL to say, okay, what does the WITH clause on CASE statement look like, how the hell do I actually write it?
Whereas in GraphQL, the way you write and the responses you get is just so intuitive that I've fallen in love with it. And I think that is the way in which the world of front end developers asking for data from the back end, that is the next decade.
00:25:14 - Anthony Campolo
Yeah. Like what you said about constraints, because I think a lot of people don't appreciate the benefits that constraints can give you. This is something that I've really learned from not the programming world, but more of the art world. And I always found that when I was constrained in terms of what tools I had for music making, that actually led to some of the most interesting music I could make because it helped me hone in on what I could get my hands on, what I could manipulate, and how I could use that to create the overall bigger thing.
So the fact that GraphQL is constrained is actually, I think, what makes it really nice because it narrows the focus of what you have to think about as a programmer and what is going to be expected of you in the types of things you're writing within your program. And what you said about this split between the front end and the back end, this really gets at the core of not just GraphQL, but really this whole podcast.
[00:26:12] And what is the front end and the back end? Why are they split? Do they have to be split at all? Should they be split? I've found that it's partly an organizational thing and partly an actual technological thing because there are differences. There are separate concerns there. But at the same time, those concerns could be handled by a single individual.
So how do you think about the split between the front end and the back end? Do you think it's a natural force of the universe, or do you think it's an artificial split that we create? How do you think about that?
00:26:53 - Anant Jhingran
So I think that sometimes separation of concerns is good. Now what happens is that, as you pointed out, in larger organizations, it happens naturally because you've got to do things at scale. Expecting people to be vertically aligned is slightly more complicated than expecting people to be horizontally aligned, right? So that's just a natural thing that arises out of this. But again, it's mostly an artifact of organizational structures, as you pointed out.
There's no reason to believe that you can't form teams that are like this as opposed to like this, right? You don't have to expect one person to know everything, but you can always form teams that are like that. But it typically doesn't happen because of organizational constructs. You're absolutely right.
But there's a second thing also. The second thing really is that, in the end, the number of things that people can cognitively grasp, unless you are Einstein, and I'm sure Einstein, outside a few things, couldn't really cognitively grasp poetry. I don't know, I'm just making it up. I'm sure maybe he did, or maybe he didn't.
[00:28:01] But fundamentally, the number of things that you can cognitively grasp is somewhat limited. And if you think about it, you've got to say that, look, at some point in time, some things are outside your sphere of cognitive deep knowledge, and there's nothing bad about it. This is actually very good, which says that you know what you don't know or you know what you don't want to know, etc., and that just makes you a better person than saying, no, I'm going to try to be an expert in everything.
So in my mind, this concept of the sphere of what I'm good at and knowing what the boundaries are is goodness as opposed to badness. And therefore, in that world you say, okay, look, what is the right way in which, when people have their own sphere of knowledge and expertise, what's the right way in which those different expertise can come together in order to make something work?
[00:29:04] And in my mind, the answer here is API. An API has the ability to abstract the backends away and provide enough of the backend functionality to the front end person, and an API is a way in which the back end person, to a degree, can figure out something so that there is now a contract with the front end.
So in my mind, APIs are really good for this kind of front end, back end thing. But there's a problem in APIs that I just referred to like ten minutes back, Anthony, which is that they are very hard to build. The way we see it in StepZen is that APIs should be self-serviceable and buildable with some constructs the front end person understands. Those APIs must connect the backend stuff, and the backend APIs are built by somebody who understands the back end.
So if you can think about a layering where there's an API or a set of APIs that the front end person builds and understands, and there are a set of APIs that the back end person builds and understands, then I think there's a phenomenal meeting in the middle.
[00:30:18] And that's why in StepZen, what we are trying to do is to allow the front end person to build the API that she needs. I don't know whether that made sense, but that's our perspective.
00:30:31 - Anthony Campolo
Yeah, I think that's great. And I think that gives us all the context we need here to say, all right, now what is StepZen like? We've talked about the problems. We've talked about why we think this is a good solution in GraphQL. But what is StepZen? At the end of the day, how would you describe what it is to someone?
00:30:54 - Anant Jhingran
StepZen is a tool that allows a front end developer to basically point to a set of backends and get a GraphQL API out of it in minutes, and then that GraphQL API is always on so that the front end developer doesn't have to worry about that API ever going down.
There are basically two parts. In the build part, the front end developer can point, point, point, and out pops a GraphQL API. Then you give that API to StepZen and say, please run it for me so that I don't have to worry about it.
00:31:33 - Anthony Campolo
It's pretty good. Yeah, I like that. For me, I had such a hard time wrapping my mind around StepZen and then trying to figure out how to explain it to other people. There's one term that I come back to, and it made sense to me at least. What's funny is I didn't really know what this term was like before StepZen, and I had to research it a little bit.
But there's this term which is a gateway, specifically API gateway. I'd be curious to get your definition of what is an API gateway. And do you think that's a good or a bad way to think about StepZen?
00:32:06 - Anant Jhingran
Yes, absolutely. You can think about it as an API gateway, but an API gateway is basically a layer above an API. It's part of what we are talking about with respect to Apigee and API management. An API gateway is a gateway. Literally it is. Shall I let you in or shall I not let you in kind of thing? And those are very important constructs. But even after you come in, what do you see?
Therefore, StepZen is focused on what the API is, not just what the gateway around the API is, but again the construct. The concepts are very similar. But in effect, what StepZen is, it's an entry into all the backend goodies, but a limited perspective into the backend goodies that only you care about and that you have built up yourself. And now you can pretend that all the right backend goodies are available to you at that gateway endpoint.
[00:33:01] If that analogy makes sense for you, right? So in some ways, as our colleague Lucia talks about, you construct your own dish from all the ingredients that exist, and all you're doing is you're gorging on the dish that you have built out because you've said, I want this and I want that and I want that. And magically StepZen acts as a chef—I'm carrying this analogy a bit too far—and constructs that dish for you. And then you can go and eat how much or how little you want out of it whenever you want.
00:33:35 - Anthony Campolo
Yeah, I think that's great. And what I'm curious about is how do we select the dishes? How do you decide what's on the menu?
00:33:41 - Anant Jhingran
So one of the problems that happens today is that because an API takes a long time to build, you have to be very careful about what you want. And the back end people have to be very careful about what are the things that somebody may ever want. So what you really find is a huge amount of bloatware that happens in the APIs because you might as well dump everything that somebody might ever want.
And then the front end person, poor front end person, either doesn't get what she wants, or she gets so much more that she's sifting through and trying to find out what it is. Because APIs are difficult to build, it is much easier in today's world for people to just say, let me throw up everything, or the front end person say, let me ask for everything.
What we want is to make that construct completely frictionless, which means that today you ask for bits A and B, they'll appear to you tomorrow. You say, no, I want to add a side dish of fries if you really want to do that. Again, I'm carrying the analogy a bit too far. You can add fries.
[00:34:43] The idea really is: don't overthink what you would need way into the future. Don't plan three quarters down or two quarters down. Just get the right data that you want right now. Build your interface. Build your web experience. Now you say, okay, I want something slightly more. Add something more.
That's the model I think is much better than putting a gun to everybody's head and saying, determine what exactly you need. Does it make sense?
00:35:21 - Anthony Campolo
Yeah. Yeah, it makes sense. I'll be curious to talk a little bit about what the tech that's underlying StepZen is like, without revealing any of the secret sauce, of course. But what is underpinning the actual StepZen thing itself?
00:35:37 - Anant Jhingran
Underneath StepZen, you've got these core database constructs, which is that backends appear as these virtual tables. You can call them interfaces in GraphQL language. There is an approximate correspondence in that each backend is basically an implementation of that virtual table. And we know in that table what can be asked and what it returns. But the table itself is empty. There's nothing in the table. It's just a shim. It will only get populated by calls to the back end.
So once we know what this table can do, we can determine whether this table's output can be fed into this table. So, for example, you may have a customer backend. This is actually the demo that Anthony, you helped us build where customer information may come returning the city of the customer. Awesome. So there's a virtual table which says, given an email, it can return information about a customer, including the city that she's in.
Now you, as a front end developer, want to figure out the weather that you want to display for that customer.
[00:36:56] "Hello, in Miami it is 97°F," or whatever it is in Miami all the time. The second virtual table that you have only takes lats and longs, doesn't know how to take cities because who knows? Somebody built that stuff up. The backend API may only take lats and longs.
So you've got one table that emits cities and the other table that requires lats and longs. And of course, you want to start with an email and come back with a weather. So you've got to connect the dots between these two. And that is where, for example, the semantic constructs come into play. A city is a location and a lat long is a location.
Therefore, to get from city to lat long, it's a series of transformations that will enable us to get from here to there. So you take the street address and you take the city, and then you are able to use a lookup to generate a lat long that you can then feed into this.
[00:37:55] So at the core in StepZen, the basic idea is: how do you connect the dots? What are the shortest paths that you can take to connect the dots? And then how do you fill each of these tables with the right backends to do the right translations, to do the right caching, to do the right authentication.
00:38:17 - Anthony Campolo
So is that required? Just like reading the GraphQL spec super-duper diligently? How is it that you are able to normalize across so many different APIs and get it to all work in this one language? Is it just because there's been a lot of work put into figuring out how to translate all these things into GraphQL? Is there anything special about GraphQL that makes that easier or not? Or did you just have to pick something to normalize across?
00:38:46 - Anant Jhingran
Okay. Two things. GraphQL in some ways is awesome because in GraphQL there is this key concept of interfaces and concrete types. Imagine a world of weather, or imagine a world of customer records. It doesn't really matter. You want to build interfaces against common things, right? Because you don't want to be dependent on what's really happening with respect to back end.
But sometimes you want to access details that are only available in backends, right? So there are only two paradigms that exist. Either you take the entire backend crap and expose it as a type, which is entirely possible, but then you get all the gobbledygook that comes with the back end in order to make something work. Or you say, no, look, you've got an interface and the back end is an implementation. Backend one is an implementation, backend two is an implementation, backend three is an implementation. And GraphQL has a very nice and natural way of doing this.
[00:39:41] So that's one part of why we fell in love with GraphQL. It is just a very nice way of building out an API against multiple backends with different capabilities, etc. And you'll see that when you play with StepZen and you look at other examples and all that. Some backends produce extra information, some less, but you can still have a common interface. So it's very useful.
But the second thing that's happened is that the state of the art with respect to machine learning and data analysis has become really good. We have learned a bit when we were at Google and we know a lot of things.
So, for example, today, if you point us to a database, we can scurry around in the database and say, okay, look, this table is connected to this table, but this table looks like something else that is somewhere else. We're not fully there, but as you know, we are working on it.
[00:40:34] Therefore we can actually pop out a reasonably smart and intelligent GraphQL just by introspecting. Because of advances in data and machine learning techniques, we can dig into it, and some of us have done in the past. So basically, a combination of these two allows us to make the task of setting this up, we believe, significantly easier in our way of doing it than any other way of doing it.
00:41:01 - Anthony Campolo
But how are we using the blockchain?
00:41:04 - Anant Jhingran
Okay, I'm not going to comment on blockchain because some of our audience may get annoyed by my strong views.
00:41:11 - Anthony Campolo
We can talk about blockchain next time. Yeah.
00:41:14 - Anant Jhingran
Yeah. Having done distributed databases, I have a bias against blockchain. But nonetheless.
00:41:20 - Anthony Campolo
That's funny. Yeah. That's all really great stuff. And something else that I know StepZen has really been focusing on is connecting with the Jamstack community. And this is, of course, a big part of the Jamstack community, the Full Stack Jamstack podcast, and so many people are interested in the Jamstack right now.
I find that some people are genuinely interested in it, like myself. And then some people are like, ah, it's this big trend that I kind of feel like I have to pay attention to. And then some people are super anti-Jamstack, which we've talked about on some episodes. But I'm curious: how do you think of the Jamstack? What are you looking to get out of connecting with the Jamstack? And why do you think it's an interesting space?
00:42:09 - Anant Jhingran
Awesome. I'm very much in the pro-Jamstack camp for a very simple reason. I have seen the very simple world when Tim Berners-Lee came out with the web, where everything was static HTML. Then I saw all the layers upon layers upon layers that got created in order to add dynamism. And then there would be something else that would be introduced to compensate for the dynamism and all that stuff. The whole stack basically became really complicated.
Then with JavaScript in the browser and APIs on the backend, there is this chance to go back to the future, if that's the expression, and really build something fundamentally better. And that's why I love the founding principles of Jamstack. Now, what I also love about Jamstack is that the A in Jamstack, as you know, is APIs because APIs are how you get content that you actually build into your Jamstack sites, whether you're building a static part of it or whether on the dynamic side of it, you're fetching weather or fetching delivery or fetching whatever else it is that you need to fetch during the dynamic construct.
[00:43:21] Right? So APIs are really how content and data meet the Jamstack sites. And we believe that this ability to set up GraphQL and easily deploy it in serverless functions or just have browsers directly connect to it, etc., is going to be fundamentally transformative for the front end developers to now be able to pick and choose whatever data they want and basically build awesome Jamstack sites.
And you know this very well as to the components and the integration with common Jamstack tools that we're doing in StepZen in order to actually make this happen. But I fundamentally love the concept of Jamstack. If Jamstack didn't have APIs in it, I would have loved it still. But Jamstack has APIs in it and StepZen then becomes a very important capability to provide those APIs, whether you're building static or dynamic.
00:44:16 - Anthony Campolo
That's cool. Yeah. One of the things that I really enjoy about the Jamstack is that it's always been very open source focused, and I actually found a blog post you wrote a while ago about things you learned after leaving IBM.
00:44:34 - Anant Jhingran
Oh my God, yes. On my Typepad account. Absolutely.
00:44:38 - Anthony Campolo
Yeah. That's right. Yeah, yeah. I thought it was awesome because you spoke to something which I identify with very strongly. You said that people talk a lot, in a good sense, about the innovations they're doing and that they give talks and they're reading and listening and watching and, most importantly, coding. And you said that you didn't really appreciate this kind of open common knowledge sharing until you started getting into the coding aspect. This really resonated with me.
The knowledge sharing aspect of open source resonates with me, obviously as a teacher, because as a teacher you care a lot about sharing knowledge. So what have you gotten out of open source since you were exposed to it and got it back then? What has your journey through open source been like since then?
00:45:28 - Anant Jhingran
I just have one subtlety about open source, which is that how many of us have actually opened up the Postgres code to see how they actually do it? Very few of us, right? But we love Postgres as a database. So I think the fact about open source, what is fundamentally more important is that with adoption it gets improvements, and improvements are not constrained by the team that started that effort.
So to me that is the most important thing with respect to open source. What has really impressed me is that openness, as opposed to just open-source-ness, has brought so many more people into the fold of it. If you really think about it, Anthony, and think about ten, 15 years back, you'd be doing music, right? And it would be this cathedral of computer science gobbledygook that would make a very smart person like you still not be able to break into it.
But with this openness and open-source-ness, somebody who is inherently really smart and intelligent like you, but has a different background, was able to grasp and grok and self-learn these concepts. And to me, that's the most important thing that this openness culture has done.
00:46:52 - Anthony Campolo
Yeah, totally agree 100%. Awesome. Well, thank you so much for being here. And thank you for giving me the opportunity to work at your company. I've been having a blast so far, and I'm really looking forward to getting out into the world and showing people how StepZen works and what they can build with it.
Because as I was saying earlier in the episode, it can be a little hard to wrap your mind around, which is similar to Redwood in a lot of ways. And I think the fact that Redwood was really hard to wrap your mind around is actually something that interested me about it. It's an intellectual challenge to not only understand it, but then to figure out a way to convey that understanding to others. So it's a fun challenge. And I look forward to getting out into the world and communicating this crazy thing that you've built.
[00:47:43] So thanks for bringing me aboard.
00:47:45 - Anant Jhingran
Two things out there, Anthony. First, what we have built and are building takes a village. And second, as much as you say thank you for the opportunity, I'm going to say the reverse, which is: Anthony, thank you for the opportunity to get a chance to work with people like you.
I'll come back to where I started, which is that life is just a learning journey. We do interesting stuff. We do fun stuff. But every day we should know a bit more than we knew before. And to me, hanging around with people like you as representatives of the developer community is an awesome privilege. So thank you very much. And thank you very much for hosting me here.