This post was originally published on this site.
Xano is a no-code backend platform that lets you build systems with visual logic, APIs, and modular AI components. Check out their tutorials on YouTube.
Connect with Prakash on LinkedIn.
User Bruno Bronosky is the winner of today’s shoutout and a Stellar Answer badge for their answer to How do I parse command line arguments in Bash?.
TRANSCRIPT
[Intro Music]
Ryan Donovan: Hello everyone, and welcome to the Stack Overflow Podcast, a place to talk all things software and technology. I’m Ryan Donovan, and today we are talking about the issues that will arise with all these companies trying to come up with this universal front-end interface. And those issues, of course, will be on the back-end. My guest today is Prakash Chandran, CEO and Co-Founder of Xano, who will be talking about this. So, welcome to the show, Prakash.
Prakash Chandran: Ryan, it’s great to be here. Thanks for having me.
Ryan Donovan: Yeah, of course. Before we get into our topic today, I want to get to know you a little bit. How did you get into software and technology?
Prakash Chandran: Yeah. I’ve spent most of my life in technology starting as a Doom 2 player before really the internet existed, connecting over BBS. Sure. So, I have always kind of been of that school, of building your own computer, adjusting your modem bit rate, and all that kind of stuff. But notably, I spent almost a decade at Google. I was on the UX product side. I was on the design lead for Google Calendar, and then I led the design and research team for Google for business and for education.
Ryan Donovan: It’s interesting. So, you spent a lot of time doing front-end work.
Prakash Chandran: Absolutely. A lot of time doing front-end work. And I also, after I left Google, I did a startup of my own where I basically was, I guess, the front-end engineer at the time. I used the Mean Stack. Stack Overflow played a pretty critical part in me actually learning and understanding what the heck I was doing. And I also, throughout all of it, I was with my best friend, who’s currently our Co-Founder CTO, who was on the back-end side, and he was the lead DevOps on Google Photos. It actually started on with the server on his desk, and he worked on Borg before it became Kubernetes. So, I got exposure to that as well, even though I’m more of a UX and front-end guy.
Ryan Donovan: So, in your time as a front-end UX engineer, did you ever write front-end UX checks that your back-end couldn’t cash?
Prakash Chandran: Yes, all the time, actually. I feel like that is just a rite of passage for the front-end engineer. ‘Cause I think there’s this moment where you’re like, ‘oh, I can just do everything on the front-end, and I can just, you know, process whatever workload I want.’ And I think that you run into walls pretty quickly. And I think that you even see companies built on doing a lot of heavy processing on the front-end that start to fall down under load, and you’re like, ‘okay, this is what happens when you let the front-end engineers loose for too long.’
Ryan Donovan: Right, right, right. And obviously, I think you talked about a lot of times where the problem with a lot of that load is just loading up the front-end with a lot of client-sized JavaScript.
Prakash Chandran: Yeah.
Ryan Donovan: Is there also a back-end problem with– everybody talks about Server-Side Rendering as the way to solve that problem. Does that have issues too?
Prakash Chandran: Yeah. In the Server-Side Rendering world, 100%. I think that the way that we look at it is that the heaviest workload obviously should be delegated off to the back-end, and all of your heavy, your business logic processing should happen there. And so, what we see sometimes is that, even with Server-Side Rendering, if a lot of the workload isn’t passed in a, in an appropriate way to the back-end, that you’re inevitably still gonna hit walls and problems, especially when you start to hit scale and go to production. And so, we kind of see this a lot, even in some products in production.
Ryan Donovan: Yeah. And the front-end dreamers in the generative AI world have come up with this new idea of a universal interface, right? I’ve seen demos for it. I think I saw a Gemini demo where the front-end is rendered on the fly, created on the fly, based on what you needed to do.
Prakash Chandran: Yeah.
Ryan Donovan: That seems like it could have a couple problems.
Prakash Chandran: Yeah. You know, I think this idea of ‘ephemeral interfaces’ and temporary interfaces—don’t get me wrong—is really interesting and exciting. I think that with the speed that AI can build, it’s only natural to draw the conclusion that yes, that’s the world we’re gonna go into. Maybe there’s gonna be purpose-built applications that an agent might build. However, I think it is a misconception to think that there isn’t a back-end component to that, and oftentimes, what is being rendered is only as powerful as the back-end that is helping to render it, or the APIs. It’s not that I don’t think that we will get there. I just think that this isn’t just like a front-end developer running off and just creating something without really thinking through the complexities of what is going to be presented, who’s going to be consuming it, and the complexities around the tooling that will be called. And then there’s a permissioning thing. There’s all of these different dynamics that they have to think through in this ephemeral app creation world.
Ryan Donovan: Right? Yeah. I remember in a previous job, [I] ended up working with a lot of client-side integrations, right? And one of the product folks gave an API that wasn’t ready for client-side integration. So, I ended up having to scramble, figure out what was the load they could bear if everybody’s ready for it. And I feel like this universal interface thing is like that, but for everybody. Everybody is now a sudden client of the APIs, right?
Prakash Chandran: I also think that expectations from users in terms of time to value have drastically shrunk. So, it’s not enough to say we’ll just put a loading indicator while this API finishes processing. You really have to think through, okay, depending on what’s being asked, they could be waiting there a while, and they could think that things are just fundamentally broken. And so, I imagine, in your use case, that you probably ran into that where it was again, writing a check that the back-end can’t cash; and I think as we start to open it up, especially Chat-GPT apps, SDK, people experimenting with that, they’re gonna learn very quickly that, okay, Chat-GPT and their team have optimized the front-end in such a way to where they’re trying to get the user the answer they need as fast as possible. Even if it’s temporary to say, ‘ hey, thinking longer for a better answer, but you can click to skip this.’ As other third-party apps get integrated into that platform ecosystem. They have to think about that same expectation from that same user that expects a response like this.
Ryan Donovan: Right. It seems like it’s relying on multiple back-ends, right? There’s the generative AI back-end that generates the UI, and then all the pieces that may be taken from third-party APIs – this seems like a nightmare to figure out. The waiting, like you said, the loading bar.
Prakash Chandran: 100%, and it’s also just [that] there’s so many unknowns. Even just the amount of load traffic, how many times an API can be called, setting the right expectation for the user, all of those things. I think coming down, again, from my background, really thinking through the user experience part of how you manifest the front-end to the user in these new platforms is going to be probably the most important thing. It isn’t enough just to kind of present them something and then have them waiting around. You have to think about, to your point, how are you going to orchestrate these different APIs to work together in a way that it serves the user in that new modality to that expectation of an instant response.
Ryan Donovan: Yeah. Are there intermediary ways we can do this instead of fully generating an entire interface? Can we use it for on-the-fly screen size rendering, or doing little pieces that generative AI could do better?
Prakash Chandran: Yeah, I think that’s actually– I mean, you said it best. It’s like starting more at the atomic or componentized level is 100% the right way to go. Like, really think about the business value that, at the end of the day, software is a mechanism to surface business, or business value, to the customer. So, what is the atomic unit of that business value? If it is the booking.com example, for example, that was shown in that demo, the atomic unit might be that card around, ‘ here is the place we think you should stay.’ You don’t need to render an entire front-end experience, like a web experience that someone might go to; it’s just the card that you have the best sense is the answer that they’re looking for, and then give them pathways to say, ‘okay, from this atomic component, how do I then start to scope out and learn a little bit more?’ So, that is the experience piece that I’m talking to and you’re referring to. Just kind of a modular way of building.
Ryan Donovan: Yeah, and it seems like if you have these pieces already. Maybe rendering or creating them on the fly might not be the way. I’ve talked to a lot of folks talking about componentizing micro front-ends, even like caching components for generative AI.
Prakash Chandran: Yes, 100%. I think before we get to this world where everything is just generated for you on the fly, it’s far more going to be a very thoughtful experiment around: what are the atomic units of the front-end I want to present? How is that going to interface with the APIs that power them, and how can, again, from a performance standpoint, I cache and show them to the user quickly? And to be honest, I don’t really know what the bridge looks like from that world to, all of a sudden, everything is just being generated as you need it. It’s just, I think the problem set of things to solve is just a lot bigger than people actually realize.
Ryan Donovan: Right, right, right. So, like you said, there is already a sort of problem set of the front-end directing with the back-end, right? What is the existing problems with the front-end back-end connection that still need to be solved?
Prakash Chandran: I think that even today, when people are building with Xano, for example, just understanding how to get a full read on all of what exists in the back-end, whether it be leveraging an SDK, or a swagger specification. That’s one piece, just knowing what is the world of things that exist in order to power a front-end, but knowing how to prioritize them, how to order them, which API should be used when for which component, is quite a different problem. And so, the point I’m saying is it might be easy to generate, today, a full-stack application, and the front-end understands what is possible in the back-end, but doing so in this new world that we’re moving into, I think is something that is an issue that will be hard to solve.
Ryan Donovan: Yeah. I mean, discovery, I think, is still a hard problem for microservices, and then all the other things. And I think it’s only gonna get worse as agents get thrown in the mix. Right?
Prakash Chandran: 100%. We already have an observability problem with agents as it is. So, in terms of okay, how are they processing this? How do I inflect and say, look, this is how you should be rendering things across a more complex application, with more complex front-end dynamics? I think that is why it’s like this componentized-level that we’re talking about, mixed with people are all talking about spec-driven design, but the spec around that component that you can basically co-collaborate, or you can kind of give intention to the agent to say, ‘ this is how it’s intended to use, and the APIs, and the order, et cetera,’ is probably gonna be the best way to approach it.
Ryan Donovan: So, how do you see the back-end having the change to even approach some of this new problem space we’re talking about?
Prakash Chandran: Yeah. I kind of mentioned the spec-driven design nature piece of it. I think that especially tools like ours are gonna have to be more beholden to specs, and figuring out how we can kind of make that a first-class citizen in terms of the way that back-ends are built and created. And interface with the front-end, I think that’s a problem that we’re, right now, a tool where you can build business logic. You can have AI assist you to build that business logic. It creates the SDK, creates a swagger documentation, but that’s not enough anymore. When you think about the world that we’re moving into where it is these modular componentized units and the state of the front-end, despite the Lovables, and Bolts, et cetera, it’s being commoditized, and it’s going to change. So, in that world, what is the nature of your API? Is CRUD going to be enough? How do you basically restrict scope on what information gets passed, when it gets passed in a world where context becomes important? So, I think it starts with the spec. And helping users think through, or the people that are creating the back-end, think through how an agent might think and process, and then rebuilding, and scoping, and narrowing your APIs accordingly.
Ryan Donovan: Right. Is there a space for a world where the back-end is also generated on the fly, or is that just like playing with fire?
Prakash Chandran: I mean, it’s happening today. Yeah. But I think especially with the back-end, unless you are an engineer with years and years of experience, and you have a strong tie and trust to the model that you’ve trained and prompted, and it remembers exactly how you build, you are playing with fire. Because generally, when the AI creates something, people are like, ‘it works.’ So, that’s that. But if you don’t understand it, you don’t own it. Right? And I think that, especially with the back-end, being able to understand it is critical because not only is it the engine for your business value, but there’s a governance piece, there’s a security piece, there’s so many things that entire companies are built on to make sure that your business logic is secure, it’s reliable, it’s scalable, it’s all of the things. And so, having an AI just generate it, maybe we get there. You know, maybe that’s the case, but I think we’re not in a world where we can fully trust it. The front-end is a little bit different to form out. And even then, you kind of have to, especially in this componentized world that we’re talking about, I think you have to be more prescriptive and opinionated about how the front-end gets generated. But the back-end, especially moving into this agentic era, I think, is going to be very important to really understand and supervise.
Ryan Donovan: Yeah, yeah. They both have risks, and they both have different risks. Like the front-end, I feel is, you know, a frustration, a brand risk, right?
Prakash Chandran: Yes.
Ryan Donovan: The back-end is like a data risk. I wrote something years ago. Obviously, Stack Overflow has been doing company copy and paste code for ages. And there was a story around the most copied and pasted piece of code getting into production systems, and enterprise companies, and having big security flaws in it.
Prakash Chandran: Yeah.
Ryan Donovan: If you don’t understand your code and you’re implementing it, it’s not your code, you’re just borrowing it.
Prakash Chandran: Totally. I think the one compliment I will give the Stack Overflow is, the thing I loved about it at the time when I was talking about it, is generally there was a threaded discussion. It always started with the problem you were trying to solve. There was a threaded discussion of experiments, and then you got to the answer. So, I think that there was naturally more context that I had as a user, versus an AI just spitting something out to me. Right? So, that’s just the first thing that I think that Stack Overflow did really well. But now that’s lost, and we get to that copy and paste code, you’re right. It’s copying something that you just don’t understand what the ramifications are, and especially when you talk about the software development lifecycle, and kind of SRE-type things going into production. AI isn’t trained on production-grade stuff, you know? And because of that, you have to be very careful. Not everything, of course, that’s being shipped needs to be inspected in this way. But if you are going to production and you’re trying to provide business value, you have to understand how AI came up with the answer that it’s giving you. And you have to be able to inspect if you expect it to perform securely and scalably in production.
Ryan Donovan: Yeah. I think, I worry that, you know, as AI is so fast at putting out code that human engineers will be a little overwhelmed, and I already see people coming up with, you know, AI code review tools.
Prakash Chandran: How do you see that in terms of you asked me the kind of the black box AI generating the back-end? How do you see that going in a world where we will actually start to adopt it?
Ryan Donovan: I mean, I think in the next couple years we’re gonna see some significant companies eat some dirt and learn some lessons, and those lessons will propagate down. But with any new technology, this is a powerful technology. There’s gonna be some pain, right?
Prakash Chandran: 100%. And I think this is why you see this shift of all the excitement around all these vibe coding tools, the art of the possible, the hype cycle around, ‘oh my gosh, engineers are dead.’ To the other side of the spectrum—the enterprise organizations being a little bit more cautious and measured because there is so much at risk to introduce something. And I think the ones that kind of enter into it headfirst without thinking through all of these dynamics, there’s gonna be an issue. But it’s so hard with AI because I feel like you have to be a student of the space, you have to be experimenting, you have to be trying it, but you have to do so in a measured way. The rules around SRE, and kinda the production-grade software principles still stand. That’s not gonna go away.
Ryan Donovan: Yeah. I get a fair amount of pushback from community members whenever I talk about AI. You know, a lot of ’em say AI is being pushed too fast. It’s being pushed too hard. Companies are forcing engineers to use more AI. As a company who’s building AI into your product, do you agree with that, or do you have a different take?
Prakash Chandran: I think it’s hard. I’m gonna give you the honest truth. I think we are moving maybe a little too slow, but I think we’re almost moving at the speed that we should be. I don’t know if that makes sense, but I have seen my contemporaries go full bore, force their engineering teams to leverage AI, track their efficiencies, and kind of get to the point where, yeah, their productivity goes up, but the understanding of the output goes down. And people are sacrificing skill development for speed. And I think at the end of the day, it’s going to cause more heartache to go back to audit, and to fix what you basically just sped up to create. And so, we have been very cautious with our own engineers around how we’re adopting it for some things, especially internal tools, which I think is a good place to start, that isn’t so mission-critical. Yeah. Experiment away and move quickly. I think when it comes to the things that we ship to production, we’re much more measured. I think it’s been wonderful to be able to create, to show the art of the possible, very quickly, like the POC. But then our engineers kind of take over, and then build it in the way that the rest of our code base has been built. So, I think that’s probably– I’m not saying that’s the right approach, I’m just saying that’s our approach.
Ryan Donovan: Yeah, just cautious towards production. Are there other controls that you can put on the AI code? Do you limit the amount or the role of AI code?
Prakash Chandran: Yeah, I think again, really– so, there’s kind of a limiter in that we’ve been using it for more internal tools, or things that are kind of less business critical. So, just by nature, we’re only leveraging it for those types of things. We also are having kind of the most seasoned engineers use it, versus a junior engineer that might, you know, go a little bit crazy and create too much. So, the senior engineers, I think, are able to work or co-create with it in a much more opinionated way. We certainly haven’t gotten to the part where we’re creating agents to do tests, and security checks, and those things. That is something that’s being discussed internally. But for right now, it’s just like, who’s using it and what we are using it for are the filters that we have on it.
Ryan Donovan: Yeah. Do you force your junior engineers to write more code?
Prakash Chandran: Yes. Yeah, because I think at the end of the day, it’s that skill development speed piece. People need to be able to learn. And I think that there’s a wonderful role that AI plays in literacy. And you can help sharpen your abilities, but to have it just generate for you blindly in a code that you haven’t written yourself, I think it’s a danger– again, you can’t understand. If you don’t understand it, you don’t own it. So, we’re forcing a little bit more of, ‘ hey, you need to write this.’ Yeah, sure, use it for efficiencies for the boilerplate stuff that we know you know how to use. But outside of that, I think that’s the right way to approach it. Now, again, that opinion is not shared by everyone. I think a lot of people are just pushing it a lot harder, a lot faster, but we’ve still been able to move pretty quickly, leveraging it for the parts that I just discussed.
Ryan Donovan: Yeah, I generally find that anybody who’s in an engineering role or engineering organization has a more cautious approach to it. They’re like, ‘there’s cool stuff going on. Little distance.’ And we found that in our last survey that the more that people use AI, the less they kind of trust it. Which I think is a good thing.
Prakash Chandran: Yeah. I mean, ultimately you have to put your brand on it. We had someone internally that was in operations and would just basically be like, ‘okay, this is what ChatGPT said.’ And she would say that over, and just like copy and paste.
Ryan Donovan: Right.
Prakash Chandran: And I was like, you know what? I don’t like. I don’t really wanna know what ChatGPT says, right? I hired you for you and your abilities, and I want you to be like, I don’t mind that you use ChatGPT to help sharpen and clarify your thoughts, but I want your thoughts. Right? And I think that this is the risk that we have around trusting it for too much at the end of the day. You’ve gotta own it. It can help you for sure, and it can help you move faster, but I think that’s, at least as a CEO of the company, I want the person, the individual that I spent a lot of time recruiting, I want their abilities. Right? And leverage AI to kind of move faster, but at the end of the day, you gotta make it your own.
Ryan Donovan: Right. And I think that’s a good pathway forward for people kind of worried about AI taking their jobs. It’s you gotta use it as a tool. You have to bring something yourself.
Prakash Chandran: 100%. AI is really just a tool and I think, look, it’s obviously having impact where it’s going to take some things like first-line support, for sure. That’s one of those things that AI can handle really well, get really high CSAT scores. But the people that were in those roles should be upskilling, right? They should be making themselves more AI-native to bring their own personality, and skillset, and creative problem-solving to then prompt and add value somewhere else in the organization.
Ryan Donovan: I think there’s also an interesting comparison here in the need to understand it, own it for the front-end engineers versus the back-end engineers, right?
Prakash Chandran: Yes.
Ryan Donovan: If you don’t understand how the back-end works, you’re not gonna be as good of a front-end engineer.
Prakash Chandran: I would definitely agree with that. I think that it goes back to– I think you said it really well in the beginning around writing checks that your back-end can’t cash, and no pun intended there, but yeah. It’s one of these things where I think front-end engineers need to have a pretty intimate understanding around… if they’re not the ones that are, you know, obviously creating the back-end code, that’s fine, but they have to have a pretty intimate understanding of how it works, what they can expect out of it, and it should be collaborative with the engineers that are writing it; because that is, holistically, I think what is going to create the best, at the end of the day, we care about the user experience. Right? It’s a means to an end. So, how do you achieve that? The front-end developers are the guardians of that, right? And in order to produce the right experience, it’s gotta be snappy. Right? All this trickery that we’re doing in the back-end really is to give the user the answer like this, that’s really all we’re doing right? And many or millions of users concurrently. So, how do we do that? And that really starts at the front-end.
Ryan Donovan: Yeah. So, for front-end developers still making their front-ends by hand, what would you recommend they do to understand the back-end needs better?
Prakash Chandran: I know this is kind of a little shallow, but I’m going to recommend you can leverage a tool like Xano, because it is a low-code back-end that abstracts away a lot of the syntax and gets into the primitives. Like, you understand variables, loops, conditionals, et cetera. I think that if you are not familiar with the back-end, that it can help you get more familiar just in building yourself, and visualizing the business logic. Even outside of a tool like Xano, I think now more than ever, it’s possible for a front-end engineer to become back-end literate, right? I think with AI, with some of the frameworks that are out there, I think it’s important to start building. And I think even more importantly, start to talk to back-end engineers, or build a relationship with them around what it means to build to production grade and to scale. What are some of the problem sets that you need to be thinking about? How are you thinking about building at scale? How do they think about building at scale? Learn about things like, you know, caching, indexing, all of these things that I think are important skill sets to have. Don’t just stick to your little domain of making a widget on a page. Really understand the full experience and the full life cycle of the request.
Ryan Donovan: So, how are you and your team at Xano thinking about evolving the tools for the back-end for the future?
Prakash Chandran: For us, we believe the future IDE or Canvas for back-end creation is mixed, meaning that we have– vibe coding right now is considered, ‘hey, this audience of like experimenters,’ but really it is really a modality around prompt response. And we think the IDE, just like a VS code, will always have a copilot component to get started. We believe it should have a code component, obviously. We introduced recently this DSL Xano script. And we also believe that there should be a visual component, because the visual part of what AI generates is the best way to kind of see what’s happening, and how systems are created, and how you can observe things. So, this IDE of the future, in terms of back-end create– or like the prettier control plane, I’ll just call it. That gives you more of that control I think is what we are building towards. So, even if you are building a full-stack application and you want control, you don’t have to understand a cloud console. It should be more accessible. There’s the Terraform piece, all the way to clicking buttons in your cloud console, but there’s somewhere in the middle, and I think we wanna be that middle for this next generation of developers. You know, taking it back to where we started around these new types of, I guess, universal interfaces, and the future of front-end development, things are changing, and things will change. And the way that we as consumers consume information – it’s already changed, right? So, as front-end developers and developers, really when you think through those modalities of how you present things to users, really think through the full experience, which means front to the back. And I think you might have to think and change your paradigm around how you rearchitect the front-end to make it performant, to make it fit into these new modalities that users are seeking to have their experiences, and that obviously also comes with being very mindful of how the back-end is serving up all of that data that powers that experience.
Ryan Donovan: All right. It is that time of the show where we shoutout somebody who came onto Stack Overflow, dropped a little knowledge, shared some curiosity, and earned themselves a badge. So, congrats today to the stellar answer winner, Bruno Bronosky, who dropped an answer that was so good, it was saved by a hundred users. And they dropped it on ‘How do I parse command line arguments in Bash?’ I’m sure there are plenty of people who have that issue. Prakash, you too.
Prakash Chandran: Yes. Nice, Bruno. I’ll have to look that up.
Ryan Donovan: Yeah. It’ll be in the show notes if you’re curious.
Prakash Chandran: All right. Fantastic.
Ryan Donovan: I’m Ryan Donovan. I host the podcast, edit the blog here at Stack Overflow. If you have comments, concerns topics to cover, please email me at podcast@stackoverflow.com. And if you wanna reach out to me directly, you can find me on LinkedIn.
Prakash Chandran: Ryan, really happy to have been here today. Thank you so much for taking the time. My name’s Prakash. I am the Co-Founder, CEO of Xano.com. You can visit us@Xano.com. Also, check us out on LinkedIn. We have a lot of tutorials on YouTube. Just kind of everywhere that you would expect us to be. Look forward to seeing you out there.
Ryan Donovan: All right. Thank you for listening, everyone, and we’ll talk to you next time.
