Noel: Hello, welcome to PodRocket. I'm Noel. With me today is Tejas Kumar. He is the Director of Developer Relations at Xata, a Keynote speaker, angel investor, YouTuber, a whole bunch of stuff, and we'll try to cover as much of that as we can. How are you doing today, Tejas? Tejas Kumar: I'm doing fantastic. I love it. I'm happy to be here and chat about all the things we're going to talk about, and just have a good time. Noel: Awesome. Awesome. Yeah. Again, I just like to turn the floor over to our guests when they're on to tell us about themselves, and their background, and how they got to where they are now. How'd you find yourself as a developer relations professional? Tejas Kumar: That's a great question. I didn't actually start as a DevRel person. I started as a front-end developer, just because I was so fascinated by like, "Whoa, I just write HTML and open it in a browser and I see stuff." Right? That feedback loop, that is the magic, just having this rapid feedback loop. And spent many years working as a front-end engineer. Really got to appreciate the complexity there, which is so unique, because you work on systems that are way outside your control. Different browsers, different network conditions, different... All kinds of things. Different people with colorblindness, and so many variables. And so, I did that for a few years, and eventually, I kept coming back to the same frustration, which is I'm blocked, and it's because the backend is not ready. Tejas Kumar: There was a lot of times where I was just waiting on backend stuff, and I thought, "You know what? Let's just pivot and become a backend engineer to see what the delay's about," and did that for a few years, mostly with Node.js backends and Postgres databases and stuff, and I got to appreciate that... The backend is something it's really important to get right from a security and privacy standpoint, but it has way less variables than front-end. You control the machines, you control... Or at least your ops team will control the infrastructure and stuff, so it's way more controlled, which I appreciate a lot over the front-end world. And then, from there, move to the infrastructure side. Things like Kubernetes, and AWS, and stuff like that. Did that for a couple years. Tejas Kumar: And then, my last thing before DevRel was, I was working at Spotify, just as a general software engineer across the whole stack, and we were working on deploying a database with high availability and failover. If US east is down, some other region needs to pick up the slack, this kind of thing. And then, one day, I randomly found a DM from the founder of Xata, where I work right now, and she said, "I have this young company. We're like six people. Do you want to join us as DevRel?" And I said, "Yeah, let's do it." Tejas Kumar: And in the interview, she made a really good point. She was like, "We could hire you to do engineering. We could hire a lot of engineers, but what we haven't found is like someone who speaks about stuff like you. That is unique. There's no one else we could hire." She and the CTO said to me... They were like, "I think you'd be well suited to DevRel in this company." And I was like, "Wow, okay. No one's ever said that. Awesome. Let's do it." And so, that's how I ended up doing DevRel as my full-time thing. Noel: Nice. The existing channels that they found, were those your YouTube videos and that content, or where were you filling this niche before? Tejas Kumar: Yeah, it was definitely not YouTube content. I do YouTube stuff almost irregularly, just because hardware is hard to set up and tear down, and lights, and cameras, and all this. But what I love doing, what I've loved doing since 2009, was just speaking at events. A lot of people are afraid of public speaking; I enjoy it. And also, I've been writing code for a very long time. I'll speak, and I'll do some coding and stuff on stage to show people things that I think are cool, and I've been doing that a lot, especially before the apocalypse. Lots of public speaking. Noel: Nice. That's a good segue into a recent talk you have done, or are about to begin. I'm not sure which it is, but one that you were wanting to talk to us about. What is that? What is that topic? Tejas Kumar: Yeah, that's at Belgium JS. That's an upcoming conference this week. Noel: Oh, nice. Perfect. Tejas Kumar: I'm talking about the next evolution of data infrastructure for JavaScript developers. Yeah. Noel: Gotcha. What is that? What is the next evolution? Tejas Kumar: That's a good question. I think the next evolution is to reduce data infrastructure to a serverless API. I think the short answer is serverless. I think it's been taking the world by storm, with things like Jamstack, and functions... And CloudFlare just today announced open sourcing their workers' run time, which is another serverless offering. I think that's definitely the next evolution. It used to be like, we'd have servers that we'd provision and scale as we need, even at the database level, even at the data infrastructure level, and I think slowly, everything's just moving to, "Someone else manage this for me so I can build my thing." Noel: Right. Yeah. I feel like there's a few players in that space. We've been creeping this way a little bit. Right? We have very managed SQL, or whatever. Relational databases that the cloud host will set up for you, and then you can just plug that connector in. And then, we have the Firestores, things attached to the suites that I can just write data to, and get data from. Do you feel like we're on this path already, or do you think we're about to hit an inflection point, where it's really going to take off even more? Tejas Kumar: I think, as you said, we've been moving towards it like LA traffic. Slowly. I don't know if we'll hit an inflection point, or if we're actually in the middle of the inflection point, to be fair, but I do think the degree of how much control we were willing to give away in exchange for convenience, that is growing rapidly, because a lot of the players in this field, even, they'll give you a hosted database, but you'll still have to usually connect to it, and then build an API into it, for example. And I think we're going to see more of people saying, "You know what? If you give me an API, I'm more than comfortable having you deal with my authentication, and all of the API things as well, in exchange for convenience and money. Noel: Gotcha. Gotcha. Yeah. That makes sense. Yeah. I'm trying to think where... When we talk about authentication, and things that are not just the simple case of reading and writing data. It's like, "Sure." It's that's not that interesting if there's nothing else we're doing around it. The hard part of the database is controlling access. Who gets access to what? How do we figure out who can read what, and make that timely? How do we solve those problems in an environment like the front-end, where a dev doesn't want to go through that overhead of setting up the things that were necessitated to be on the backend before? Tejas Kumar: Yeah, exactly. That's exactly the evolution I'm talking about, is... Let's imagine if you wanted to do that today. Right? I know so many companies that are doing exactly this access control and authorization at the database level. They're doing it so differently. There's a company called Guild. Brand new company, and what they're doing is, they're using Postgres to control all of that. Postgres has first-class support for authorization using SQL. They're just straight on the database. Tejas Kumar: And then, there's another company... I don't know if I'm allowed to even share it, but whatever. There's another company called Relay... Replay, rather. Replay.io. Great company, and what they're doing is, they're doing access control at the resolver level. They've got a GraphQL API into something. And so, the resolver essentially looks like, if cookie has permission, then forward to the database; else, 401. This is something that I feel like could be standardized, almost, by virtue of having a serverless provider be like, "Look, we'll handle that. Send us a header, and then we'll do the rest." I think teams are tired of figuring this stuff out themselves, especially front-end teams. Noel: Yeah. Agreed. And I feel like it's also interesting, because it's one of those problems that has always felt to me like, "Eh, we're all doing a lot of work on the same thing, here. We're all resolving this every single time we do it. It feels like this shouldn't be that hard to abstract." I feel like we're getting there. What do you think is different now? Why has it taken this long for us to get to the kind of services, or architectures, or even just technology, that empowers us to do this? Tejas Kumar: I think we're kind of sussing out things that are in demand based on past experience. Back in the day... I'm sure you're familiar with this. Just the simple act of deploying a static site was super hard, or at least harder than it needed to be. You'd need to have some type of S3 account, and then you'd have to orchestrate it yourself. You'd need to, in Jenkins or something, when you get pushed to a repo, you would build that static site, and then push that static site to S3. You'd have to manage all that yourself. And now, we have things like Netlify over the past few years, where you drag and drop your static site into some drop zone on a front-end, and boom, it's deployed. And not only is it deployed, if it's a git repo, you'll get deploy previews on each PR. Tejas Kumar: You can preview your front-end. That's new. And so, I think how we find ourselves where we are today is, we've solved the front-end deployment problem. We've solved the functions API deployment problem with things like CloudFlare Workers, and Netlify Functions. We've been solving a lot of problems across the stack, starting at the front-end, and now we've made our way... Right? ... all the way to the database. But I think it's just a matter of pulling on a thread. And so now, we're in the database part of this thread we're pulling on until we solve that, too. But I like what you said earlier. We've solved these problems multiple times in our careers at multiple different companies, and at some point, we have to have this zero one end thinking of engineering, where, if we do something more than one time, it's generally a good idea to have this be a reusable function that we can unit test. Tejas Kumar: And I think the serverless offerings are exactly that. There's teams that are... It's their full-time job to make database infrastructure awesome so that, if you're a new startup, you don't have to worry about that. I think that's where it's leading, so I wouldn't be surprised if, after the database portion of the thread we're pulling, we move on to something else. Maybe we make Kubernetes or something really easy for people to use. Noel: Gotcha. Gotcha. I feel like the existing offerings, at least the stuff that I had played with, it wouldn't be that much of a jump for a no-sequel developer to be like, "Oh, okay. Whatever. I can use this database as a service, and write JSON-like data to it, and get it back from it, and that's fine." But to those developers that... They're much more in the relational database mindset. They've spent their careers working on normalizing data, and getting effective indexes on keys to make it so we can query certain rows really fast. When we have 10,000,000 rows in this database, we're reading 1,000,000 of them every two minutes. How do we ensure that those people are brought along as well as we're trying to push towards data storage as a service? Tejas Kumar: Yeah. Let me be really clear, I think SQL or relational databases are not going away ever. I was going to say anytime soon, but ever, because look, there's a lot of value to be had with no SQL, or non-relational databases, particularly around horizontal scale and geographic distribution, and replicate... That whole story is effectively solved with no SQL solutions, but there's a great cost to that. Right? Tejas Kumar: You lose normalization, you lose the standard query language, even, that so many people love, in favor of what? You need to know a programming language to glue your unrelational stuff together in your application. There's trade offs, and I think SQL is... Oh, this is going to be controversial, but I think SQL in so many ways is superior, barring the scale story, the distribution story. I think really, the future, or the ideal, is you give people a relational model, but you just handle the scale side of things. And then, you get the best of both worlds. You get the problems that no SQL solves, but also the joins and the normalization that people are used to, while still offering regional failover, and horizontal scalability, and all of that, as a service. Noel: Yeah, yeah. Yeah, that makes sense to me. I feel like it's much more difficult to get yourself into an irrecoverable data architecture, or something, if you're using a relational database. There's just better rails in place, and you can like... [inaudible 00:13:43] Tejas Kumar: And also, the whole thing about asset guarantees, which you just don't get with no SQL. Your transactions are not atomic. You don't get consistency. Right? There's a whole area where noSQL is just not a good choice. I would probably use it for a like button use case, where you click a like button and you don't really care if it has 1K or 2K, it's important that it's liked. But if I'm doing a bank or something, there is no chance of me using no SQL for areas where data is important, mainly because of ACID. Noel: Yeah. Right, right. Yeah. In that realm, I feel like that's... It's an interesting topic, because I feel that's the decision there, of, what does my application care about? Do I care about absolute data accuracy, or high availability and speed, and replications, and having that. And that's always informed, I guess... The engineers that are focused on those problems have used those decision points to figure out what they want to use. What do I want to use for a data store? The answers to those questions are what inform my decision. How do we, now that we're moving.... Or, I guess, if our theory is correct, that developers are going to keep pushing towards data as a service, how do we make sure that we have answers for all those kinds of questions? Because I can't imagine technically we're going to be able to have the perfect solution for all of those use cases across the board in any product or configuration. Tejas Kumar: Right, and I think that's why there's so many players in the space, too, because there's companies like FaunaDB, for example, who give you no SQL, but with ACID. That's their whole thing. But then, you have to ask yourself the question, "Okay, that's great. But do I still want the ambiguity of no SQL? Do I still want to stitch stuff together in my application logic?" Versus... There's other companies, like... I can't think of names right now, but there's other companies that give you the opposite. They give you hosted SQL, and they handle scale up. PlanetScale, great example. But yeah, I think to cover most of the use... You know what I would love? Here's my dream. Right? A multi-model, serverless database, where you can just throw data at it... Structured, unstructured, doesn't matter... and it just works. Tejas Kumar: And the reason why this is my dream is because then, if I have 10 months to build a Tinder clone or something, I don't spend three of them trying to figure out, "Oh, shoot. What do I do with the data?" And I think that's so valuable, especially for companies that are early, or maybe with a small runway, or even older companies that are running out of runway. The less time you spend on essentially a solved problem, the better. Here's something that would be fantastic, is this dream database that I have in mind... Right? ... where you just throw data at it, and it just works. What do I mean by, "It just works?" I mean even something as simple as a little switch element in the UI, where on one side you have, "Eventually consistent," and on the other side, you have, "Immediately consistent." Tejas Kumar: You just flick this thing, and that determines where you land on the CAP theorem. Right? Do you get consistency or availability? And that's essentially what I'm talking about. A serverless database for developers that gives them the choice, and it feels like at the flick of a button. Honestly, outside of one company, there's no company that I know that is focusing on developer experience, but for databases. The Vercel-style developer experience, but for databases. Maybe Vercel will start doing databases. Who knows? Noel: Yeah, yeah, yeah. And they'll design with that perspective. Do you think that that is tenable, I guess? My intuition is that there's more to that decision, or more to how an application needs to function, than flipping that switch. I would assume that the way even the front-end behaves is going to be beholden to what it knows about the state of the database, like how it works. When I'm sending up a new read or write operation, I care about, "Is this an eventually consistent database, or do I know that my current value is right before I write it?" And I feel like often, that knowledge is going down all the way to what was formally the API layer, but now in serverless world, now it's either on the front-end, or in a function, or something. Do you think that it's possible to write that logic in the front-end, or in a serverless function, without having to think about what setting is toggled, for example? Using your example, in the UI for the database on consistency. Tejas Kumar: I love that you brought that up, because now I'm thinking... And by the way, it's my job to think about developer experience. Right? Now, I'm thinking, absolutely. What if... A lot of these databases will just give you an API. Right? And some of them don't even give you direct access to the database, so you have no chance of executing SQL statement, or something. What if, instead of the switch in the UI, what if the switch was a header you could send when you do a transaction on the database? [inaudible 00:18:50] God, can you imagine? You fetch to get data, but you add this header, "X mode, consistency or availability." Ooh. Wow. And then, your apps could actually control that. Damn. That's what I'm talking about. This type of developer experience doesn't exist, but I want it. Noel: Right, right. Yeah, yeah. It'd be super cool. In your front-end, be like, "Whatever. MyDB. Here's the data I want to write, and just..." There's an options param I send in there, and in that, I can tell it how I want this operation to perform, if I need to always make sure I have the latest... Tejas Kumar: Yeah. Write it, or even read it. Read this with immediate consistency, so it'll take a bit longer, or read it with eventual. Or even write it with immediate or eventual. If you write it with the setting for immediate consistency, then what's going to happen is, on the backend side, in a distributed environment, your primary will get the rights, but not committed until all the replicas commit. And then, there is some time you'd lose, but that's effectively opt-in from user land. Holy smokes. I really want that. Noel: Okay. Yeah. Yeah. If you ever find yourself implementing it or on it team, you got to call back to the PodRocket podcast. This is where it all started. Emily: Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcast, and because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers, so check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right, back to the show. Noel: In this talk, were you going to focus at all on how thinking about data like this affects how these serverless apps are architected, or how devs are creating their new architectures? Tejas Kumar: Yeah, I was actually considering touching on that, but the conference is BeJS, Belgium JS. For me, it's super important to have a strong appeal to the audience, which, in this case, it's in the name. Right? The JavaScript developers. In preparing for this talk, and spoilers, I'm giving you a bit of the outline, is to come at it as a JavaScript developer myself, and realize most JavaScript developers, especially if you're doing a high-velocity job, you don't get that much time to think about it. The general feeling on your team is, "Okay, I push this web view, this landing page, this whatever." And then, there's an entire backend team to take care of that, and as a result, most JavaScript developers, especially front-end developers, would have decisions to make. Tejas Kumar: "I need a database, maybe for local testing or something. What do I do? Do I use SQLite? Why should I use SQLite instead of Postgres? Why should I use Postgres instead of Mongo?" I think for a lot of front-end developers... And this is from even talking to people at conferences... there's just some type of Wild West confusion. And with that, I think more importantly, comes imposter syndrome among front-end developers, and this is not helped by the former outgoing school of thought, that, "Oh, JavaScript developers don't know anything, they just push pixels." Right? That's how it used to be when I was starting out. And so, with that comes a lot of imposter syndrome and so on, and so the goal of my talk is to just eliminate that, and give the JavaScript developers working on the front-end, or even in functions, just more insight into how data has worked so far, and the next evolution of data infrastructure as well. Noel: Gotcha. Yeah. That's interesting. Do you feel that this old mindset of, "Oh, JavaScript developers are just solving simple problems on the front-end." Do you think that that is untrue moreso now because they are dealing with the scalability problems directly on the front end? Tejas Kumar: I don't think it's more untrue now, because even if you go back to jQuery days, or even MooTools days way before... Right? ... There's always been... The browser wars are a thing, and you cannot ignore... Maybe the developers who are making webpages to work on just one browser at one screen resolution and one internet speed, maybe that's saying, "There's not a lot of complexity there," but as far as I can recall, that's never been the case. There's always been a requirement to fulfill major browsers, sometimes even unreasonably, back to IE11 or something, IE10. But then, there's also the network constraints. There's the visual impairments constraints. There's so many constraints. I don't think that statement has ever been true. I'd even question... Maybe the backend is oversimplified, because we control all of the systems. There's fewer variables I can see, there. Noel: Yeah. Yeah. The backend feels like a much more controlled system. And yeah, just for clarity, I wasn't implying that it ever was true. I feel that perception is starting to shift, so I was getting at, what do you think is causing that change in perception? Do you think it is just there's more empathy in the developer space in general, or it's like, there are scalability concerns and stuff that are being pushed to the front-end, so the backend engineers are like, "Eh, this is a hard problem"? Tejas Kumar: Yeah. No. I think really, it's just a community effort. Speaking frankly, full disclosure, I've been a part of so many conferences since 2018, 2017, and in the beginning, even, there were some talks about the difficulties of being a front-end engineer, and I would watch backend engineers in these talks literally just get up and leave, and I go, "Come on. You don't know anything." That was the early days, but I've watched community events over time, and yeah, I think it's largely just community engagement, where they highlight... For example, if somebody was to work at Spotify... Right? ... there would be a talk about, "Here's all the problems we had to solve to get this player to work right across multiple front-end platforms. Apple Watch, TV, web browser." And then, people were like, "Oh my goodness. I had no idea." I think it's just an ignorance thing. I think if you don't know the constraints, you'll always oversimplify. Noel: Yeah. Right. Yeah. Yeah. I think that that's true. But anyway, I think it's good that empathy is building, and I think it's also cool... Tejas Kumar: Yeah. And I think that's how we build empathy, even, is education, because the people who... "JavaScript developers don't know anything," they just didn't know. Could they have done the work to find out? Sure, but personally, I don't think that way. Nine out of 10 times, it's easier to just say, "They don't know anything," instead of, "Go check for myself." It doesn't make it right, but it is the natural, easier tendency. I can understand the other side from those days, but I'm generally glad education is doing its job, and leading empathy. Yeah. Another example is, a lot of people, I feel like, have major problems with downtime, and GitHub has had, unfortunately, a really bad quarter. Right? Just incidents left and right, and sometimes... When GitHub's down, people can't work. Tejas Kumar: We've had people just say, "Yeah, GitHub's down. I'm done for today. Goodbye," and that's super valid, because what are you going to do? Engineers, especially. I feel like, back in the day... Again, as I was starting off... there was always hatred, "Oh, these ops people are so incompetent. Fire them all." But lately, as incidents have happened, I've seen a hashtag trending that I think is so beautiful, is #HugOps... Right? ... where you still give your ops people a hug, because they're under fire. I think I'm seeing this shift in the tech industry, and I freaking love it. Noel: Yeah, totally. Totally. Yeah. This is just an interesting aside... Any of that old, "The front-end engineers aren't solving tricky problems." Do you think any of that was stemmed from that blame the ops people kind of anger? They're like, the back end engineers, "If I fail, I bring the site down, it takes us a while to recover. Things are hard. If a front-end engineer pushes a bug, we can send out a rollback, and fix it, and it's fine." Do you think that that kind of negative energy that was always directed towards the ops people led to that chip on their shoulder? Tejas Kumar: Yep. Yep. Yep, for sure. And I think also, unmediated and uneducated we're all super helpless. If it wasn't for the community, I'd be the same. You know what I'm saying? I really not give enough credit to the community around helping us be better people. Yeah. Yeah. Noel: Cool. Nice, nice. Let's bring this back and talk about JavaScript a little bit more. Yeah. You started us off talking about how this conference was really focused JavaScript developers. Do you think that the JavaScript engineers have spent less time thinking about database architecture and stuff than the backend engineers have? Tejas Kumar: Yeah, for sure. Because, especially with the advent of Jamstack, I think everything's an API. JavaScript API is in markup. Right? I think JavaScript [inaudible 00:28:36] spend a lot of time thinking about APIs, but where those APIs lead to. An API, effectively, is like a pipeline to a backend system. I think they don't have as much exposure. And, before the Jamstack, the expectation... At least in my career, like 2015-ish... was, "Make this landing page look like this Figma, and here's a few APIs you can call. Good luck." Right? Yeah. Front-end hasn't been as involved, I would say. And then, you get no JS, and even that I feel like hasn't been as closely involved. At best, you'd get GraphQL that resolves to some database connection, but generally, I feel like the space is young. I think a big help there was a company called Hasura. Hasura and also Apollo GraphQL with Apollo Server. I think these two companies really helped front-end engineers move more towards back-end stuff, including the whole GraphQL spec as well. Noel: Yeah, yeah, yeah. Yeah. This is going to be a weird analogy, but I feel like Apollo got JavaScript and Node developers thinking about data in the way that backend engineers had always had an ORM to lean on to help them inform how to make a database. It's like, "Oh, I've got this object relational model having an opinion about how I do things," and that opinion often would help you get to a functioning end state, and I feel like Apollo observed as those guardrails, as well. Tejas Kumar: Definitely. And also, the hype of GraphQL. GraphQL was advertised as a front-end thing, I think, from Facebook. Ultimately, it's just a specification. Right? But when it came out, this whole notion of, "Oh, you can just do one round trip to a server and back instead of multiple," that was a front-end optimization. It was in almost this demilitarized zone between front-end and backend that it just came into, and I think that was, for sure, a segue for a lot of people, myself included, to that world. Noel: Yeah. That notwithstanding, where do you point front-end devs who are now, due to these changes that we've been talking about in the industry, where you have this database as a service, it's much easier to use it from the front-end directly, but you have to make those architecture decisions without necessarily building an API, or a backend? How do you instruct JavaScript developer? How do you tell them where to look to be guided on how to do that properly? Tejas Kumar: Yeah. That's a good question. Personally, what I tell people is to build stuff. [inaudible 00:31:24]... But I don't mean within the company. Take a weekend, or sometime you have off, and ask the question, "What happens when I want to communicate with my database? How does this work?" And then, just pull on the thread until you're led to some... [inaudible 00:31:40] That's personally how I learn, as well. For example, when I didn't understand React, I just built a poor man's React clone just to get it, and that's usually what I tell people, and it works generally so far. But just to circle back to one thing you said about querying a database from the front-end directly, I don't think that's a good idea, because you probably will have to authenticate and send a header or something for authorization... Right? ... and this is not something you do on the front-end, because... Noel: Right. Yeah, yeah. Totally. I was probably being overly generous. I wasn't thinking write a SQL query. I was more like, "Call the service that's doing your database management for you to give you the data you need." Yeah. Tejas Kumar: But even then, you'd include your off token on the cloud. Generally, you would have a serverless function or something do that, and you'd send your front-end code to the function. The whole thing is to obfuscate off-headers so that people can't inspect your network tab, and... Noel: Yeah. Yeah. Or you don't have to think about it at all. Yeah. To close the circle then when thinking about data on the front end, from a data storage architecture, and then just a data structure itself, that we're using to read and write data, do you think that those need to remain of the same shape, or synonymous, or can we start to separate those back, and these services can be storing data in a different way than we're thinking about it on the front end? Tejas Kumar: Yeah. I think it can help a lot to maintain some type of homogeneity between them. Right? Because then, front-end engineers can be included in backend discussions, because there's overlap. I think it can help companies and teams to speak the same language. This is why I really admire the work Prisma is doing, for example, giving typescript engineers a really nice ORM, because that's a backend... ORMs have been around on the backend for years before Prisma. And so, bridging that gap, I feel like, will... It does so many things. Right? It removes imposter syndrome to some degree from the front-end engineers. It says, "Look, now we speak the same language," and it allows collaboration in ways that were impossible previously. Yeah, I for sure think maintaining... How did you put it? Synonymous-ness? ... is valuable for sure. Whereas, what's the alternative? There's a divergence, but then, but divergence between teams and orgs, even, gets bigger, and then ultimately the code gets less predictable. Therefore, we'll have scale problems. No, I think synonymity is the way, for sure. Noel: Yeah. Do you think that the presence of GraphQL and Apollo, where it makes it easy to build up different data structures for the front-end to consume from disparate data sources in the backend that might not even have the same shape? Do you think that is dangerous, then, because it's so easy to do transforms through that API layer? Tejas Kumar: It depends. Right? If you're using GraphQL as a batch API, which a lot of people do, then it's valuable. And, other than the developer experience, it's definitely, beyond a shadow of a doubt, valuable for the user experience, as opposed to doing like 17 different round trips to 17 different services. It's, I think, just in terms of value prop. But what I do think is really important... Because GraphQL is not a front-end concern. Right? It's a front-end optimization to choreograph GraphQL API, but a GraphQL API itself is not a front_end concern, it's a function, slash middleware, slash backend concern more than it is a UI, front-end concern. I still think having an ORM like Prisma or something on the front end, and then having that be homogenous with your GraphQL API, is super important. Tejas Kumar: But then, if your backend GraphQL API proxies to like 17 different disparate services, like you said, that's entirely a backend thing. If that differs from what the front-end people are doing, I don't think it matters. As long as there's one element on the backend and one element on the front-end that speak the same, I think it's fine. And that is the GraphQL server on the backend, and the Prisma ORM on the front-end. Yeah. I think there has to be overlap in semantics at at least one level on both sides, for sure. Noel: In an organization, let's say, where there is some separation of concerns between teams... Right? There's the front-end team and the backend team. And now, I'm sure this topic has been beat to death, but if we're talking about this middle layer, who do you think should own that? Should the front-end developers be in charge of saying, "This is the shape I want the GraphQL API to return," or, like you said, that the GraphQL API isn't really a front-end concern in functionality, it's just how I get the data. Should that not be in their purview? Tejas Kumar: If you draw a Venn diagram of front-end and backend, GraphQL is the intersect. Right? I think that can perfectly model even the team participation. If you've got 10 front-end engineers, 10 backend engineers, you could allocate one of them each to fill the middle of that Venn diagram. It has to be a collaboration, otherwise, it's going to get complicated. Yeah. I think, in terms of resources, that middle layer is not as binary as the others. I think we need at least one from both side, there. Noel: Yeah. Oh, absolutely. Yeah. I think the collaboration definitely... It tends to happen there, and that is the way it is. I feel like one could make the argument, just given where we've gotten in our conversation, that should be the purview of the frontend. Right? You could use your schema that Prisma's spitting out, and like, "Okay, I generate my GraphQL types just based on the ORMs types, and then, we need the backend team to make sure that they can satisfy our requirements," but that just seems like an overly optimistic, or naive, way to do it, because the backend teams are going to have concerns about performance, and the way that that layer is querying the data. Tejas Kumar: Exactly, and this is why you... I think any team that just has one team be responsible for that is going to be in a lot of trouble. Yeah. Because you can't separate those. Noel: Yeah. Agreed. I feel like we've covered a lot so far. Is there anything else in this topic, or what you're planning to cover in your upcoming talk that you wanted to touch on, or talk about? Tejas Kumar: Yeah, I wanted to touch on the notion of database-less development. I think this is where it's going. A lot of people talk about serverless, and make jokes like, "Oh, but there are servers," all the while not getting that it is serverless for you, the user. You literally don't provision or scale anything, and it's reduced to just an API, usually. I think we're headed more towards a database-less world, where other people manage whatever your database is, and you just get an API. I think it's valuable for multiple reasons. We've talked about them already, but I think one of the biggest reasons is then being able to globally distribute and query your database from the edge, from CDN edge, and that's nuts. We see some users of Xata, for example, use something like CloudFlare Workers to query their stuff, and they get these ridiculously fast reads from their database, which... Unheard of in the past. Tejas Kumar: I think that's something, and I also think it's not just databases that are being hidden behind serverless implementations, but also entire data infrastructures. We don't want to do this at Xata, but we have the potential to have companies exist that just don't have ops teams at all, because... Yeah. Actually, you don't need an ops team at all if you're a newer company, which reduces the barrier to entry, so anyone can start something, and if they use things like Vercel or Netlify... Right? ... For their static sites and functions, ops steam is not needed, but you would still need an ops steam for your database until Xata shows up and says, "We give you the same thing that Vercel does, but for databases." And then, what I mean by data infrastructure in this case is not just the database, but at some point of scale, everyone needs and has a search engine. Literally. Instagram, Reddit, YouTube. Search is super important. Tejas Kumar: I'm talking about the concerns of a database, a search engine, and some type of in-memory KV store. These three things always go together. And so, when I say database-less infrastructure, what I mean is all of that stuff becomes someone else's problem, and so then, I can just build an app that uses it, and I don't have to worry about sharding, and indices, and stuff like that. Yeah. Noel: Yeah, gotcha. I totally feel that. I am that way, myself. When I'm spinning up a new project, I try to pull as little of that database ops work as I can. Now, I'll find some service, make it super easy. But I do feel that, if you're a new company trying to get started, even if you don't have resources to dedicate an ops person to it, I would theorize that many companies are still choosing to manage a part of that database themselves. Either they're spinning up a managed Postgres instance, or whatever. They're spinning up a managed service somewhere to give them a database for fear of vendor lock-in at the database level, and being unable to adapt or make a change if they're running into an issue. What do you say to those companies that have that reservation? Tejas Kumar: Lock-in is one thing, but also just the basic notion of privacy. You'll sign your contracts with whatever database service, and they have terms in there, terms of service, like, "Your data is yours. It belongs to you." Awesome. We do that too, but you don't know know. You know what I'm saying? You don't have physical access to the machine, so I think those reservations are super valid, and for lock-in specifically, that's why what we're doing at Xata... And I think a lot of others may follow suit, I don't know... is, we make it so easy for people to leave, like data exporters, because we don't believe in holding people hostage. If you're happier at PlanetScale, then go use PlanetScale, we'll make it easy for you, because... Tejas Kumar: And this is getting philosophical. I even believe, in interpersonal relationships, if somebody's better friends with someone else, and they don't want to be my friend anymore, then I have no reason to be like, "No, stay with me." Just go be happy. That's all we want. Like, "Go be happy." Yeah. I think the concern of lock-in is super valid. We, as a company, recognize that, and we're trying to actually make it easy for people to leave. And also, having companies concerned about who owns the data, and so on, those are valid, and we try to make those concerns non-concerns. We try to massage them, and say, "we should be super open about these things." Noel: Yeah, totally. Yeah. Yeah. I think that's awesome. I think it's super cool that you guys are making it easy to get data out. But I guess my personal feeling, if I'm starting a big project and looking at these tools, or even looking at Firebase, or something, it's like all of this engineering work I'm doing, even if it's saving me a lot, I'm saving time by committing to a certain API shape. Right? I'm making design decisions that are beholden to the assumptions that I'm making about this service that I'm using. Are we missing, maybe, a layer of abstraction that may be helpful at some point to make it swappable, so I can find a different service provider to do this? Tejas Kumar: If lock-in is a real concern... And it's introducing coupling... Right? ... between your code and some vendor, I think it's an awesome idea to just have that Venn diagram, GraphQL thing in the middle. Your app, all your front-end, and all your clients... Which, probably, you're going to have way more clients than you are backends as a company. I'm talking about iOS app, Android app website, and these clients speak to this single GraphQL API that then talks to whatever vendor you want, which you can then change out, even. You can make it swappable. I think, yeah, that's huge, and I think GraphQL is uniquely suited to do such a thing. That's a really good point. I think more companies that are concerned about this should do that, for sure. Noel: Yeah. I think people are aware of it. That's why these tools are crapping up. This is not some big revelation. This is what people are thinking about. But yeah, it's cool to see vendors ensuring that their products are swappable, in that regard. And, if you've done a little bit of work as an engineering team, you can make it so your architecture isn't super beholden to our paradigm. Yeah. Yeah. Cool. Thank you for answering a couple of the tough questions, there. I know I was getting into it. Yeah, yeah. Is there anything else you wanted to talk about, anything upcoming, anything you want to plug? Tejas Kumar: I'm excited about a lot of conferences. At Xata.. for us, we love hanging out with developers. Actually, DevRel is one of our biggest pillars on which we're trying to build the company, because we're not doing anything new. We're just wrapping existing, tried and tested things. Postgres, Elasticsearch, DynamoDB, and the name of the game for Xata is developer experience. Right? We just want it to feel premium. We want to give you a nice, white-glove database experience while taking all the stuff out of it, and we do it ourselves. Yeah. It's developer communities. We're going to be at React Amsterdam, Cascadia JS. There's a whole bunch. But yeah, what I did want to plug is Xata. We care about developer experience, and we're all about giving developers the most premium and best developer experience with datas, databases, and data infrastructure as we can. We're in private beta. If you want us to hook you up, we can. And so, that's my only plug. Noel: Nice. Nice, awesome. Cool. Yeah. Will be a link in the show notes, for sure. But yeah, thank you. Thank you for joining me, Tejas. I appreciate it. This has been an awesome conversation. Usually, we're not able to get in the weeds to this degree, so this has been great. Tejas Kumar: Thank you, man. Thank you so much for having me. Kate: Thanks for listening to PodRocket. You can find us at PodRocketpod on Twitter, and don't forget to subscribe, rate, and review on Apple Podcasts. Thanks.