rss-bridge 2026-01-20T08:40:00+00:00

Don’t let your backend write checks your frontend can’t cache

Ryan welcomes Prakash Chandran, CEO and co-founder of Xano, to the show to discuss the intricate relationship between frontend and backend development, the potential challenges that universal frontend interfaces pose for developers, and the importance of understanding both your frontend and your backend when using AI code.

January 20, 2026

Don’t let your backend write checks your frontend can’t cache

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.

[...]

Original source