Realtime Frameworks with Dev Agrawal

Episode Description

Dev Agrawal and Anthony Campolo discuss Solid Start, real-time WebSocket frameworks, Vinxi, AI-powered podcast tooling, and the state of JavaScript ecosystems.

Episode Summary

Anthony Campolo reconnects with Dev Agrawal to explore what's happening across the JavaScript framework landscape. Dev shares his work on Solid Socket, a project that won $7,000 at the Solid Hackathon by bringing real-time WebSocket capabilities to Solid Start through a "use socket" directive inspired by server functions. The conversation traces how frameworks have historically avoided real-time features due to their reliance on stateless architectures and Lambda functions, and how PartyKit and Cloudflare Durable Objects began changing that calculus. Dev makes a case for Solid Start as his preferred framework, contrasting its client-centric model with the restrictions he experiences using Remix professionally and the server-centric approach of Next.js. They discuss Vinxi, the meta-framework builder created by Nikhil Saraf that combines Vite and Nitro, which enabled both Solid Start and TanStack Start. Anthony then shares his own project, AutoShow, a CLI-turned-product that uses Whisper transcription and multiple LLM integrations to generate podcast show notes, chapters, and summaries automatically. The two discuss practical decisions around auth, hosting, TypeScript adoption, structured outputs, and the enduring value of GraphQL despite its perceived decline in popularity.

Chapters

00:00:00 - Catching Up and Dev's Background

Anthony welcomes Dev Agrawal back to the stream after a period of less frequent interaction, noting that Dev attended his wedding earlier in the year. Dev introduces himself as a full-stack JavaScript developer with seven to eight years of experience who works at Smartdata as a software engineer while also creating YouTube content and engaging actively on Twitter.

The conversation turns to how Dev approaches the JavaScript discourse online, primarily by observing and synthesizing conversations rather than trying to drive them. Dev explains that the most effective way to shape discussion is through building something substantial, whether that's an open-source project, a product, or a high-effort video, rather than just tweeting opinions. Anthony notes that Dev's thoughtful written takes have earned recognition, including a retweet from Evan You praising his perspective on React Server Components.

00:04:11 - Solid Hackathon and the Real-Time Web Problem

Dev describes the Solid Hackathon, sponsored by Netlify and Sentry, which aimed to grow the Solid ecosystem and motivate developers to build with the recently released Solid Start. His winning project, Solid Socket, addresses a gap that exists across all JavaScript frameworks: real-time WebSocket support. Dev explains that frameworks have gravitated toward stateless HTTP architectures to maximize deployment flexibility, making real-time features an afterthought.

He traces the inspiration for his work through PartyKit, whose creator left Cloudflare to build it independently before being acquired back, and through projects like Phoenix LiveView that advanced the developer experience for real-time applications. Dev argues that server functions, which erase the client-server boundary through compiler directives, should be extended to real-time communication. His "use socket" directive allows developers to write reactive state on the server that automatically synchronizes with clients over WebSockets, eliminating the need to manually wire together messaging systems, state management, and database layers.

00:10:44 - Server Functions, Loaders, and Framework Conventions

Anthony and Dev unpack the terminology around server functions, loaders, and actions that has emerged across modern frameworks. Dev clarifies that loaders are route-level data-fetching functions designed to prevent client-server waterfalls, while server functions are a more general mechanism where any function marked with a directive becomes an HTTP request at runtime. Actions handle mutations and trigger loader revalidation upon completion.

The discussion traces the origin of server functions from Solid Start's function wrapper approach through Qwik, Next.js's string directive adoption, and TanStack Start's continued use of function wrappers. Dev notes that Rich Harris has explicitly spoken against this pattern, preferring SvelteKit's file-based separation of loaders and actions. Anthony draws parallels to his experience at StepZen, where the arrival of loaders in Remix and SvelteKit dramatically simplified server-side GraphQL API calls that previously required manual Lambda function wiring.

00:23:39 - Why Solid Start and Comparisons with Other Frameworks

Dev declares Solid Start his go-to framework, mentioning a recent talk titled "Meet the Web Framework from the Future" and a conference app he ported from Next.js to Solid Start with significantly better results. He contrasts Solid's client-centric model with Remix's restrictive data-fetching patterns that force data through loaders and reduce component composability, and with Next.js's server component model that requires careful management of the component tree.

Anthony pushes back on the Remix community's marketing claims about simplicity and web API usage, and Dev agrees that every modern framework now uses web APIs, making that distinction meaningless. The conversation shifts to how Remix is evolving into essentially a React Router plugin, reflecting a broader industry tension about what functionality belongs in the router versus the bundler versus the server, a tension that Vite's new Environment API also addresses.

00:32:16 - Vite, Vinxi, and the Meta-Framework Builder

The conversation explores how Vite transformed the JavaScript tooling landscape by replacing Webpack and Babel with a simpler, faster alternative, empowering developers who previously couldn't consider building frameworks to start creating them. Dev then introduces Vinxi, created by Solid core team member Nikhil Saraf, which layers on top of Vite by combining it with the Nitro server runtime from the Nuxt ecosystem.

Dev explains that Vinxi's core concept is multiple build pipelines for different runtimes, solving a problem that was difficult to represent with a single Vite configuration. Both Solid Start and TanStack Start are built on Vinxi, and Brandon Roberts quickly prototyped a version of Analog on top of it. Dev mentions that Vinxi was also essential to building Solid Socket, and he's considering building a minimal React framework on Vinxi to demonstrate what server functions can accomplish without server components.

00:44:05 - Anthony's AI-Powered Podcast Tool

Anthony shifts to discussing his own project, AutoShow, an AI-powered tool for generating podcast show notes. He explains the evolution from manually using OpenAI's Whisper for transcription and feeding results to ChatGPT, to building a Node.js CLI that automates the entire pipeline from YouTube links or RSS feeds through transcription, LLM processing, and metadata generation. The tool integrates with seven different LLM providers including OpenAI, Claude, Mistral, and Gemini.

After showing it to several podcasters who urged him to commercialize it, Anthony began converting the CLI into a product with a Fastify backend and Astro frontend. He discusses the challenges of structured outputs across different LLM APIs, the trade-offs between open-source and commercial models, and the practical limitations of running large models locally. Dev suggests using Zod schemas for structured responses and the Vercel AI SDK for provider-agnostic integration.

00:59:49 - Work Life, Consulting, and Career Paths

Dev describes his role at Smartdata, a consulting company where he's currently building a healthcare member portal using Remix for a client. He reflects on how consulting exposes developers to diverse projects and technologies, having previously worked with React, Angular, PHP, and MongoDB across various client engagements before his DevRel stint at Clerk.

The conversation takes a humorous turn discussing COBOL, with Anthony sharing the story of a friend whose father advised learning the language because all the COBOL developers were aging out of the banking industry. Dev mentions a startup called Codemod that uses LLMs to generate deterministic code transformation pipelines rather than performing direct AI refactoring, an approach both find compelling for large-scale migration work like upgrading React versions or porting legacy codebases.

01:12:24 - Building the Product: Auth, Architecture, and TypeScript

Anthony details the architecture of AutoShow's transition from CLI to product, explaining how CLI flags naturally map to API endpoints and form inputs. Dev recommends consolidating the separate Fastify server into Astro's built-in server capabilities to simplify authentication and deployment. They discuss auth options, with Dev recommending Clerk's generous free tier of 10,000 monthly active users as a starting point over rolling custom auth.

The conversation touches on Bun as an npm replacement versus a full Node runtime alternative, with Dev recommending the Elysia framework for anyone going all-in on Bun. They briefly discuss Effect as a TypeScript library that provides additional compiler-level safety around program execution, error handling, and concurrency, drawing parallels to how TypeScript itself eliminated categories of bugs that existed in plain JavaScript.

01:31:03 - GraphQL's Enduring Value and Closing Thoughts

Dev makes a provocative claim that React plus Relay remains the ultimate frontend stack because Relay solves data-fetching composition problems that other approaches are still chasing. Anthony agrees passionately, arguing that GraphQL's perceived decline was driven by ecosystem complexity from libraries like Apollo and Prisma rather than problems with the spec itself, which he considers remarkably simple.

Anthony shares the story of Edgio's collapse, describing how the company failed to unite its three acquired businesses into a compelling product and eventually declared bankruptcy. He reflects on lessons learned about corporate instability versus startup agility and his motivation to bootstrap an indie product with full autonomy. Dev shares that student loans and immigration constraints keep him in traditional employment for now, but he aspires to eventually pursue independent open-source or product work once his financial situation stabilizes.

Transcript

00:00:02 - Anthony Campolo

All right, we are back live, AJC and the Web Devs, with Dev Agrawal, or "Dev" technically. It's really good to hang out with you, man. We haven't talked much this year, but you came to my wedding, which was awesome. Very much appreciated that. I've been wanting to reconnect and see what you're up to these days. Do you want to introduce yourself for anyone who doesn't know you, the few people out in the web dev world?

00:00:33 - Dev Agrawal

Definitely. I'm a full stack JavaScript developer. I've been building JavaScript apps for about 7 or 8 years now, something like that. My experience is pretty much all over the place, but it's primarily been the full stack. I never really felt like I'm only building front ends or I'm only building back ends.

It's kind of an interesting direction that my career has gone into because of that. And obviously everything that I'm doing recently has been informed a lot by that experience of mine, just fully building full stack apps forever. I work at Smartdata as a software engineer. I make YouTube videos sometimes. I post a lot on Twitter, trying to do some open source stuff recently. Not very good at it, but I'm trying.

00:01:38 - Anthony Campolo

I think you do some pretty cool open source stuff. I think just being someone who is out there kind of always engaging in the conversation, that's something I did a lot more in 2021, 2022 and started to fall off in 2023 and didn't do much in 2024. But it's just so valuable because people get to see the conversations and how people think about these things. Everyone has hot takes and opinions, but you actually take the time to write out your thoughts in a very coherent way.

00:02:15 - Dev Agrawal

Retweeted. Here's my cat's tail.

00:02:18 - Anthony Campolo

Oh hey, what's up cat? Yeah, you're retweeted by Evan You who was like, "this is a good take on React Server Components," which I thought was pretty cool.

00:02:27 - Dev Agrawal

Yeah, caused a pretty big jump in my followers thanks to him.

00:02:31 - Anthony Campolo

Yeah. So what are the topics that are interesting to you? Do you feel that you kind of check the vibe of what the conversation is, or do you try and drive the conversation?

00:02:46 - Dev Agrawal

I think it's mostly the first, just try to check the vibe, try to form my own thoughts and offer some sort of insight into what I can see going on. Very few times is it actually trying to drive conversation or trying to generate new conversation. I feel like there's a bunch of people doing a much better job at that.

The best way to drive a conversation is not really just making a tweet about it. It's more like you build something, put it out there, something fully formed, either a high effort YouTube video or a product or an open source project, something like that. And that's how you really drive the conversation. That's something that I'm trying to do, but it's not something I'm very good at.

00:03:42 - Anthony Campolo

Yeah, it's almost like the framework authors, to a huge extent, drive the conversation just by the code they write. But then you also have people like Ryan Carniato, who does both. He drives the conversation about building this stuff, and he's constantly trying to explain why he's building it and the direction he's trying to go. You're super involved in the Solid community, and it sounds like you went big for the Solid Hack.

00:04:10 - Dev Agrawal

Yeah.

00:04:11 - Anthony Campolo

Yeah, you should talk about that. What was your project? Actually, first, just what was the Solid Hackathon? Some people probably saw it, some people probably didn't. And it was a pretty substantial one from what I was looking at.

00:04:23 - Dev Agrawal

Yeah, so they tried to do it almost every year, I think. But I don't think they did it last year. So this is the first Solid Hack after 2022. What's up, Nick? How's it going? Nice to see people popping up.

So it's a hackathon to try to grow the ecosystem, to try to motivate people to learn Solid, to build something with it, to show off its cool capabilities. And obviously Netlify and Sentry were the two big sponsors because Netlify is where Ryan used to work and Sentry is where he works now. So two pretty big sponsors, lots of money flowing in, and lots of excitement around Solid Start, which was recently released. It was also kind of a way to get a lot more people building stuff with Solid Start or for Solid Start and grow the ecosystem.

Because at this point, everyone that talks about Solid or Svelte online says, "okay, these are clearly better frameworks, but React's ecosystem is bigger."

[00:05:34] So they're going to use that. Ecosystem is kind of the only thing holding the React mindshare together at this point, it seems like.

00:05:45 - Anthony Campolo

Because it's the network effects. There's a real argument to why that makes sense, because you end up with the most people building stuff, and then you get the whole community stuff. Solid and Svelte both always have this problem of how do we have all these extra libraries that do all the crap that people expect from React libraries?

So you kind of did something that really added something substantial, which is real time capabilities essentially. Was this something that Solid Start didn't have, or did it have it and you made it nicer?

00:06:20 - Dev Agrawal

It's something that no framework has. Every framework has kind of gone in this direction of stateless. "We're just going to do HTTP, we don't care about..."

00:06:31 - Anthony Campolo

Just stick it in a Lambda.

00:06:33 - Dev Agrawal

Yeah, exactly. And doing WebSockets with AWS Lambda is a whole category of pain, which is why people probably don't want to build any sort of agnostic layer around it. Most people just wanted to put their apps on stateless servers so that they can run it as much as they can. And if the framework comes with a limitation that you can only use it on a long-lived persistent server, that immediately hurts adoption, right?

So every framework has been very scared of doing any sort of real time things. Even Next.js, which has a platform team behind it, even they're not really going in this direction. And I didn't like that. A lot of people need to build real time apps. We're just making it more difficult for them to build these kinds of apps. Sure, we have services like Ably, Pusher, Liveblocks that are doing some great work here.

[00:07:38] But what if I want to actually run code on that server? Why does that have to be a separate service that now has latency between my server and their servers and my client? You can always build better things, more efficient apps if you just have control of the logic that runs on those servers.

And then PartyKit happened, which is like, okay, this is exactly what I wanted.

00:08:07 - Anthony Campolo

He left Cloudflare to build that, right?

00:08:13 - Dev Agrawal

Yeah, because they wouldn't let him build it inside Cloudflare for some reason. And then later they realized their mistake and acquired him.

00:08:22 - Anthony Campolo

That's like the ultimate hacker move. They won't let you build it, so you leave, build it somewhere else, and then force them to buy it. That's awesome.

00:08:30 - Dev Agrawal

Yeah, baller move. That's basically what happened. And that kind of showed me that the direction I'm thinking actually can work.

The other thing that happened was I looked at things like Vue.js or Phoenix LiveView, which are doing some pretty good work in advancing the DX of how you build real time things. So it made sense that if we were to build real time apps, it's not going to be like Socket.io, which was great for its time. I had a great experience with Socket.io, but clearly we need to evolve past that.

And then server functions happened, which is like now the boundary between client and server is completely gone. The compiler takes care of it. You write a function wrapper, and it's there. So why can we not take this idea of the boundary being gone, or the boundary being a compiler directive, and apply it to real time?

[00:09:35] So that's basically been the premise of all the work, trying to explore how this might look, how this might work.

00:09:47 - Anthony Campolo

Yeah, that's super interesting because what you were saying about the stateless app architecture being really predominant. You mentioned Vercel and Next and Socket.io kind of went away from that and was like, "I'm gonna do these Lambda things."

With Redwood, it was really interesting because I learned kind of through seeing the progression of the framework the issues with just sticking it in a Lambda, because the whole thing was built to be stuck in a Lambda. The idea was Tom was like, "oh, in three years, Lambda will be ten times faster and you could do a thousand concurrent requests." He just thought it was going to get better and better every year. And then it kind of just didn't. And that was really tough.

But then they were like, okay, what if we just ran this in a PM2 Node server? So it was technically running all the time, but it was really just taking a Lambda and running it all the time on a server.

[00:10:44] It wasn't really WebSocket, because one of the oldest...

00:10:47 - Dev Agrawal

Right.

00:10:47 - Anthony Campolo

Forum posts we ever had was, "how do you implement real time and WebSockets?" And since it was GraphQL, you had this whole subscription thing as well. So it was always like, "oh, once we have GraphQL subscriptions, we'll have real time."

00:10:59 - Dev Agrawal

Yeah.

00:10:59 - Anthony Campolo

But GraphQL subscriptions were like, "actually we're not gonna do subscriptions, we can do this other weird GraphQL thing," live queries or something. I don't even remember what it's called, but there was something that competed with subscriptions. So then we had to decide which of the two to use, and it was just a whole confusing thing.

So I definitely get what you're saying, how it's not really built in to most frameworks. It's always been kind of like, well, you just roll your own with your own production app.

00:11:26 - Dev Agrawal

Yeah.

00:11:27 - Anthony Campolo

It's built into the platform, isn't it?

00:11:30 - Dev Agrawal

Exactly. And the other thing that was interesting is that with things like server components, or server functions even, it kind of became obvious that there's a bunch of additional complexity that we add on just to be able to communicate between a client and server. But with server functions, it's just a function marked with a directive. You don't need any extra concepts here.

It was something similar that hit me, which is that we already have ways to manage state. We have stateful components. We have signals. We have all these state management libraries.

00:12:12 - Anthony Campolo

We have databases also.

00:12:14 - Dev Agrawal

Yeah, we have databases. But then just to make WebSockets work, we now have to learn one new thing, which is how to communicate using just messages and then build a compatibility layer between that and our existing state management, and then another one on the server that takes these messages, talks to a database, and then sends messages again.

So we're kind of plugging these 3 or 4 systems together instead of just using the one reactive system that we are already familiar with. So that's another approach that I'm trying to explore.

00:12:55 - Anthony Campolo

Would you be cool screen sharing actually, and showing the code for your project? Because I could go into it, but I wouldn't know what to look at. I'm sure you've probably done demos of it already.

00:13:07 - Dev Agrawal

Yeah, I should have done that earlier. Give me a second.

00:13:10 - Anthony Campolo

Yeah, go for it. But you won a crapload of money, so that's what I think is pretty cool, is that you were recognized for building something super useful. Because that's the point of a hackathon. Ideally you're creating something that's not just cool that you can show off, but something that's actually useful to someone somewhere. And I think it's cool that instead of just building a bunch of dashboards or something, you built actually a useful library, it sounds like.

00:13:44 - Dev Agrawal

Yeah. The hackathon had two different categories, one for apps built with Solid and one for ecosystem libraries.

00:13:52 - Anthony Campolo

That's really smart.

00:13:53 - Dev Agrawal

Yeah, so there's definitely...

00:13:57 - Anthony Campolo

You won seven grand, right?

00:14:01 - Dev Agrawal

Yeah, so that was part of the...

00:14:03 - Anthony Campolo

I'm assuming that's probably...

00:14:06 - Dev Agrawal

It is. Yeah, it's on their website.

00:14:08 - Anthony Campolo

Yeah. So I cut you off. What were you saying?

00:14:13 - Dev Agrawal

Yeah, I was just saying there is an app category where you will see a lot of random apps built out over a weekend or something. But there's also really good ones, like Chris Griffin spent a lot of time on stream just building out this code diff tool.

00:14:33 - Anthony Campolo

Nice.

00:14:35 - Anthony Campolo

Yeah, when I saw it announced, I thought about it, but I was traveling for the first ten days of November and could not even code for like six of those. So I was like, not really going to have the time to do it as well as I would want to. Can I share your screen?

00:14:52 - Dev Agrawal

Yeah, let's do that. So I'm gonna fix this up a bit. This is a simple example of a counter. It's very straightforward. You have a signal and you have increment and decrement functions. It's a custom hook that you might build for React or Solid or anything like that, but by annotating it with "use socket," now this runs on a server. This piece of state lives on the server. These functions live on the server.

What you return from here, all of this is server code, but it can be called from the client. So I don't think I have an example for this, but if I can just go in here and...

00:15:42 - Anthony Campolo

A to-do app is fine, yeah.

00:15:45 - Dev Agrawal

Yeah, the to-do app has a bit more going on there. So instead I'm just going to do this. Counter is "use counter," which gets imported from the... I'm literally importing it in a client file and calling it. And then here I can say, button onclick, counter dot increment. And then it's going to show count, which is counter dot count. It's literally as simple as that.

I can try to run it. I hope nothing is broken. But basically, the value of this count now comes from the server over WebSockets. When you click the button, we send a message to the server saying, "hey, please run the increment function," which will increment the count and it will immediately update the signal on the server, which will update the signal on the client.

00:16:54 - Anthony Campolo

So obviously this is inspired by, and to some extent, React Server Components because you're doing the "use socket." I haven't used Solid Start since it was in beta like a year and a half ago. Are there any other "use blank" things, or are you the first one to do this?

00:17:15 - Dev Agrawal

So...

00:17:16 - Anthony Campolo

Specifically for Solid.

00:17:18 - Dev Agrawal

For Solid specifically, I don't think there's any. Obviously there's "use server" which is in Solid Start, which is what this is mostly inspired by. Obviously it comes from Next.

00:17:33 - Anthony Campolo

Right, that's what I was asking. Does Solid Start have server components already? Like "use server"? Okay.

00:17:40 - Dev Agrawal

Yeah, it does have server functions that you mark with "use server." And that's kind of been a lot of my conversation recently on Twitter, which is that server functions have now become kind of a framework-agnostic concept.

They originated in Solid Start actually. They were not a string directive, it was a function wrapper, but they originated in Solid Start as a function wrapper. Qwik very quickly adopted that, and then Next.js with the app directory adopted a different version of it which used the string directive, "use server." But it was again basically the same concept with a couple more things added on.

Then from there, Solid also grabbed on to the string directive instead of the function wrapper. TanStack Start still uses a function wrapper instead of a string because they can add a lot more capabilities on top of it. Qwik I believe is also still just a function wrapper.

[00:18:48] But the point is that server functions as a concept now kind of exist. They're out there. Any framework can use it, and every framework should probably adopt it. I know there are some framework authors who kind of don't like it. Rich Harris has spoken out against it very explicitly. SvelteKit separates it into a separate file with loaders and actions, so they don't have separate functions. I hope they will at some point. Or you can just build a framework that has it.

00:19:24 - Anthony Campolo

We need to adjust some of these terms. What's the difference between a loader and a server function?

00:19:29 - Dev Agrawal

So a loader is specifically a function that you would use to fetch data outside of your components, most likely at some sort of a route-level routing event. A loader is something that would fetch data. It would be something that your router is aware of, which means your loaders can be called as soon as you navigate into a page instead of in between rendering. So a loader as a concept specifically exists to prevent client-server waterfalls, to help you load data in an optimal way.

Server functions are just the capability to invoke some logic on the server by sending an HTTP request. But what you're writing is just that function with a directive, so it can fetch data, it can mutate data, it can do something else. A server function doesn't imply how you use it. It's just the mechanism that you write a function, and at runtime it becomes an HTTP request and the code is not sent to the client.

[00:20:42] So you can combine those concepts, a loader and a server function, so that you have optimal data fetching and you're fetching on the server instead of on the client. And same thing with an action, an action would be a mutation usually.

00:20:58 - Anthony Campolo

Right?

00:21:00 - Dev Agrawal

Yeah. Action is a mutation, that's the first kind of property. And the second property is that when an action completes, any loaders, all the loaders or any specific loaders, are going to rerun and give you the updated data. So that's what an action is. And again, you can combine an action with a server function to make a server action.

00:21:23 - Anthony Campolo

Yeah, that makes a lot of sense. I remember when my first job was at StepZen, this GraphQL company, and at the time this was beginning of 2021. So Remix had been around for less than a year. SvelteKit had been around for like three months, I think.

So the way everyone just did GraphQL is you would just hit it from your client and just query it, but with StepZen it was a managed GraphQL API. You had an API key, so you'd have to do your call on the server. But there weren't a lot of good ways to do that at the time beyond just sticking it in a lambda function and then hooking that up to your framework.

And then I remember when loaders started coming out with Remix and SvelteKit, it was really nice. I'm like, oh, now there's this thing, and now all of my StepZen examples are now simple as hell because I just use the loader, you know.

00:22:19 - Dev Agrawal

Yeah. So a lot of frameworks kind of combine the two concepts, loader and this ability to just write a server function. So like Remix and SvelteKit, the loaders by default are on the server. They don't really have concepts of a client loader. Remix, it's literally called the client loader. But some frameworks because...

00:22:41 - Anthony Campolo

Why would you need one? You could just do a fetch on the client, you know.

00:22:45 - Dev Agrawal

Yeah.

00:22:46 - Anthony Campolo

Yeah.

00:22:47 - Dev Agrawal

I mean, you would still need one for the same reasons, like if you don't want to run a JavaScript server, or if you don't want to pay for a JavaScript server at all and you only want to run on the client side. You're talking to an external API, you know, or you have a separate server like Go or Rust or .NET, Java or something, and you just want to talk to that one instead of running your own servers. Then you might need the client version of them.

But yeah, so most of these frameworks kind of combine both. So you also have a server and the loader by default runs on the server, loader and action both. I think SvelteKit must have a way to say that these loaders... Yeah, it has both. I'm not really familiar with SvelteKit.

00:23:39 - Anthony Campolo

Yeah. And then you've got Astro, which has now a lot of this kind of stuff as well. They have a whole bunch of stuff that can run on the server in different ways.

And yeah, I guess, obviously you did the Solid hack thing, but if you're just building greenfield apps in your spare time or whatever, is that what you would reach for, or are there other frameworks? What are some of your go-to's these days?

00:24:07 - Dev Agrawal

Yeah, Solid Start is my go-to these days, 100%. I just gave a talk last month called "Meet the Web Framework from the Future." That's a provocative title, but yeah, obviously it was about Solid Start. I don't think there's a recording up there yet. I don't think there's going to be because that conference, they don't really publicize recordings.

00:24:29 - Anthony Campolo

The recording only the initiates got to see.

00:24:33 - Dev Agrawal

Yeah. I did record my in-person talk, but it was such a rush because I designed the talk to be 50 minutes but it was only a 25-minute slot, so I had to rush through it. So there is a recording that I can post, but it's not great because I had to rush through a lot of stuff and I had to skip through a lot of stuff as well, so I might just record it separately on my own.

But if I'm recording on my own, do I just want it to be a slideshow or do I want to make it more high effort? I don't know. I should just record it, there's no reason not to. It's fully prepared and it should be out there.

But yeah, it's 100% my go-to. I built a conference app recently, or I've been actually building it since last year, but I initially built it in Next.js and then I ported it over to Solid Start.

[00:25:24] And the experience has been much better compared to when I was building it with Next.js.

00:25:28 - Anthony Campolo

Remind me what the name of that was, I remember this.

00:25:32 - Dev Agrawal

I just called it Velocity, but that's kind of like an internal code name. It's just called the Momentum app, like app.momentum.com. It's for attendees to look at the schedule, bookmark things, and give feedback. And then this year I added a lot of newer features, like for speakers to assign themselves to sessions and give specific feedback, and some attendee networking to scan QR codes, kind of like LinkedIn.

So yeah, Solid Start has been a much better experience than pretty much anything else, because of their focus on client side and not moving everything to the server. I'm also using Remix at work right now and it's not the same. Remix is a lot more painful.

00:26:27 - Anthony Campolo

Interesting. Yeah. The answer will be slightly different I'm sure for these two, but I would be curious if someone was like, "I'm just going to use Next.js" or "I'm just going to use Remix" kind of person. How would you make the pitch to use Solid Start instead?

00:26:43 - Dev Agrawal

I mean, I think the more difficult part of the pitch is moving from React to Solid. That's really the more important one. If someone is using Next.js and Remix, they probably just want to use React. But if they're open to using Solid, then I would say that first of all, Solid actually keeps the client-centric model instead of the server-centric model of Next.js and Remix.

Server components are really nice with Next.js, but Remix is very restrictive in terms of data fetching. All the data has to go through the loaders and then you have to make sure you pass it through either with props or context. And it makes your components kind of brittle, like they have to be used in the correct route, or they have to always be passed in the data that they need. You have to always make sure the data is fetched. So yeah, it's very restrictive in that sense.

[00:27:42] Next.js, I like server components, but not enough. There's some very weird pains around using server components, like if suddenly you need... They both suffer kind of the same issue where suddenly if you're in a component down in your tree and you need to fetch some data, you now have to make sure you go all the way back up to the root level and make sure everything is a server component in one case, or all the data comes from the loader and is passed down. So they both have less composability.

Solid kind of retains that by allowing you to actually fetch inside your components and then very easily on your root level say, "Hey, prefetch this data because I know I'm going to need it down the tree." So I like that a lot.

00:28:31 - Anthony Campolo

I found that really funny, what you were saying about Remix, because I feel like this was basically just marketing hype when it came out. Everyone was always saying it's just using web APIs and you don't have to learn a whole bunch of new stuff. But what you're saying is the opposite, that it actually requires you to learn the Remix conventions, and that if you don't use the Remix conventions in the specific way they were designed, then your stuff gets all messed up.

00:28:58 - Dev Agrawal

Yeah, and it's also that using the web API doesn't necessarily mean you move everything to the root. Solid also uses the web API in the same way, and so does Next at this point. Using the web API is just that you're using the web standard web API.

00:29:17 - Anthony Campolo

There's like multiple web APIs. Yeah.

00:29:21 - Dev Agrawal

Yeah, in a sense. The web API just kind of specifically talks about WinterCG or whatever the browser JavaScript standards are. So yeah, in that sense.

00:29:34 - Anthony Campolo

Yes, the Fetch API is a web API. That's how I would think about it, you know.

00:29:40 - Dev Agrawal

Yeah. And the request/response objects that you see, like even in Solid Start you can get the standard request object. You can return a standard response object. Those work. You can use a form with an action, like method equals post, action is a server action, and you just post it directly. So all of that still works in Solid Start.

Whatever web APIs that you want to use in Remix, most of them work in Next.js as well. So the web API argument, yeah, everyone's using web APIs now. Now what?

00:30:18 - Anthony Campolo

And I think what Nicky is saying is true, that Remix is going to become like React Router with a plugin.

00:30:28 - Dev Agrawal

Yeah. So this is another thing that a lot of frameworks have been going through. And by a lot I mean two specifically, both Solid Start and Remix, which is this question of what belongs in the router and what belongs in the bundler. Because the framework is essentially three things. It's the router, it's the bundler, and it's the server. It's also the renderer, but every framework has kind of made their choice, like I'm either using React or I'm using Solid.

But everything else has kind of been trying to wrangle what lives where so that they can clearly find separations. Vite's new release with the Environment API comes a lot from this same tension of what should live in the bundler, what should live on the server or on the router.

So in terms of React Router, their version of this is basically a lot of these features come into React Router.

[00:31:34] And then there's just a React Router plugin. It's not even the Remix plugin, it's the React Router plugin that gives you access to server rendering and server data fetching, things like that. And without that you just have a regular... you would probably use Vite anyways. It's just a plugin that you can use to configure whether you want to run on the server or not.

00:31:59 - Anthony Campolo

Right. So it's just leveraging stuff that Vite has already built.

00:32:04 - Dev Agrawal

Yeah, it's a router with extra steps. And those extra steps are the bundler plugins and the server runtime.

00:32:16 - Anthony Campolo

Yeah. This is a similar thing. My frame of reference is always Redwood because I followed it for years at a time. And man, when Vite first came out, there was a lot of hype around it. But yeah, the whole framework was built around Webpack and Babel, and every framework was.

But it was done in a way that leveraged those tools in an old-school way. Like, I'm a JavaScript dev, I'm gonna write this huge, ridiculous Babel config and Webpack file, and the whole framework is going to be in that Webpack file. It's not just that it was using Webpack. It was like Webpack and Babel together, and I always had the hardest time disambiguating those two tools because they were always used together and it was never clear to me which one was doing which.

And then you got Vite and it was like, oh, we're not going to use either of those anymore.

[00:33:16] And it's like, well, okay. So do we rewrite the whole freaking framework, or do we try and...

00:33:21 - Dev Agrawal

Basically.

00:33:21 - Anthony Campolo

Keep most of the framework the same and tack Vite on to do things it wasn't really supposed to do? And it kind of ended up being this process that took like 2 to 3 years, you know.

00:33:32 - Dev Agrawal

Yeah.

00:33:34 - Anthony Campolo

So that was so cool, it was so deep. So this is another interesting historical branch. Snowpack was the first thing that we were building on. Then Vite kind of came around and was like, we're like Snowpack but better. And I was like, oh yeah, it is better. Even the Snowpack creators were like, oh, this actually is better. We're just using Vite now.

00:33:57 - Dev Agrawal

Pretty much. Yeah. I mean, at the same time, Vite also empowered a lot of people who didn't want to build frameworks to start building frameworks, or made it much easier to build them. So yeah.

00:34:09 - Anthony Campolo

Yeah, I love Vite. I think Vite is probably the most important JavaScript tool that came out since I started development, because I got into development around 2018 to 2020. The mid-2010s framework landscape had already kind of calcified at that point. So I was coming into all this weird tech debt from the React class components and ways of doing everything.

And then Vite came out. It was just so refreshing because it was just simple. It was so simple compared to what came before, and it was fast. So it was like, this is both better for my brain and better for my performance. There's literally no drawbacks to using it. And it shows in these ecosystems also. That's Vue, or Nuxt, the framework I think is...

00:35:07 - Dev Agrawal

Nuxt.

00:35:07 - Anthony Campolo

Yeah.

00:35:08 - Dev Agrawal

Yeah. And that's the other piece that's really helped frameworks like Solid Start and TanStack Start: the ecosystem around Nitro. It's basically like, hey, we are building a meta framework, but we don't want to be so closed about it. We are going to take every single piece that we can abstract out and make it its own package so that you can use it outside of Nuxt, outside of Nitro, however you want.

Nuxt has a lot of power, a lot of money, a lot of resources behind it. So all of these packages are very high quality. And then suddenly, if I'm building my own framework, all I need to do is glue some of these packages together, which is what Vinxi did — gluing Vite and Nitro into a higher-level abstraction so you can build your own frameworks.

[00:36:13] I gave a talk...

00:36:15 - Anthony Campolo

I don't really know much about this. It kind of came out right when I was paying less attention to new stuff, especially the Nuxt ecosystem. So what exactly is it?

00:36:27 - Dev Agrawal

I gave a talk about it at React Rally and I did a Learn with Jason episode on it. It's basically like you can think of it as the meta framework builder or a meta meta framework, if that makes sense.

00:36:41 - Anthony Campolo

Well, yeah, because the framework builder was Vite, so it can't be the meta framework builder. It's got to be the meta meta framework builder. That actually makes perfect sense to me. I mean, totally serious.

00:36:51 - Dev Agrawal

It's more like Vite was not a great meta framework builder, but Vinxi is a better meta framework builder than Vite. It's a layer on top of Vite that combines it with a server runtime.

So the base concept in Vinxi is a router, which is like, take a set of HTTP requests. And these HTTP requests will be handled by their own JavaScript application. That could be a server application handling HTTP requests, or it could be a single page app, or it could be a static directory basically.

It's actually kind of difficult to explain like this, but it basically brings in the concept that you don't just have one Vite plugin pipeline. You don't just have one build, you have multiple builds. And this was not very easy to represent if you're just using Vite because you're building this one build pipeline that has to process all the code and then try to put it in multiple different places for different runtimes, or it has to do multiple passes through the pipeline, something like that.

[00:38:10] With Vinxi, you just define separate pipelines for separate things that you want to do, and it takes care of things like file system routing.

00:38:19 - Anthony Campolo

And have you heard of this...

00:38:22 - Anthony Campolo

New React framework called One? This sounds very similar to what you're describing.

00:38:29 - Dev Agrawal

Yeah, One is a React framework. It's a little different. Vinxi is much more of a lower-level tool that you can use to build your own frameworks. So Solid Start and TanStack Start both use it. Nuxt and Analog are actually very similarly architected. And actually Brandon Roberts built a version of Analog very quickly on top of Vinxi, which is very nice.

I gave a talk on how you can use it to build your own framework, obviously. And One, it very specifically is the React framework around Tamagui and Zero sync.

00:39:16 - Anthony Campolo

Hmm.

00:39:18 - Anthony Campolo

Yeah.

00:39:19 - Dev Agrawal

We can do a whole different tangent on One.

00:39:21 - Anthony Campolo

Yeah, I don't necessarily want to go too deep down that rabbit hole. I think it's cool because this is a thing again that with the Redwood React Router, we did a similar thing where you could first... it was always kind of client side and then there wouldn't necessarily be the same idea with routes, because you had your GraphQL server and you kind of just hit this big API in the back.

But we then added in a prerender directive. So if you wanted to have a page just render on the server, you just put prerender in. And then we eventually had this kind of hybrid mode where you can switch between pages that were on the front end or the back end. And I was always like, this is so cool. And I was always waiting for other frameworks to do it. And now it's kind of blowing up.

[00:40:20] And I think it's very cool that you're super into this thing that you did with Vinxi because I think it simplifies stuff so much to have your framework or your tool just have those things built in. It's really hard to fully understand until you have it.

00:40:41 - Dev Agrawal

I mean, I've thought about it multiple times, to actually try to build a minimal React framework and put it out there — like, hey, look, here's how easily you can do this. I've been planning on it for a while. I definitely want to do it with WebSocket at least, like here's a real-time React framework that you can use just as a proof of concept.

And at this point I want to build one to show off what you can do with server functions and how you don't really need server components for a lot of full stack composition stuff that people keep talking about. So yeah, I might actually build a React framework — at least a minimal one — just to make some points.

But yeah, again, it's because Vinxi exists. If Vinxi didn't exist, I wouldn't even think of building my own framework. Now I can do it.

00:41:37 - Anthony Campolo

It reminds me of when Ben Holmes was creating his own React Server Component implementation as kind of teaching exercises, just showing you how you could do this yourself. Because it's very empowering to have that lower level understanding of the framework, even if the framework is giving you that by itself. It's always really good to actually have the confidence that you could re-implement it yourself if for some reason you had to.

00:42:10 - Dev Agrawal

Yeah. I mean, hey, it got me a maintainer role in the TanStack Router/TanStack Start Discord.

00:42:15 - Anthony Campolo

That's cool. That's sweet, man. Yeah. You've totally kept up with the whole JavaScript web thing better than I have. I kind of stepped back from it because it got to a certain point where I knew all the frameworks, I tried them all, I understood the trade-offs, and I'm just like, I'm kind of sick of talking about it. But now it's been like a year since that and now there's new stuff. So it's like, all right, cool, there's actually new things now.

00:42:50 - Dev Agrawal

One thing I do want to mention before moving on to a different topic is that Solid Socket, the project from the Solid hackathon, that's another thing that would not have been possible without Vinxi and some of the things that it ships with. So that was very key to not just enabling me to build Solid Socket, but giving me a lot of the underlying things so I don't have to build them myself.

But yeah, I'm really curious about what you've been doing.

00:43:22 - Anthony Campolo

Yeah, I'll get to that in a second. But who created Vinxi?

00:43:25 - Dev Agrawal

Nikhil Saraf. He is one of the core team members. He was also the person on the Solid Start team for a while.

00:43:32 - Anthony Campolo

Yeah. Okay, no, I remember. I really wanted to get him onto my podcast right when those started, when I kind of stopped doing them. Someone was lining up like, I gotta get this guy on the podcast because he was building such cool stuff, for sure.

00:43:47 - Dev Agrawal

Yeah. He gave a talk last year called "I Needed a Server," which kind of goes a lot more into the background context of his experience and the motivation behind Vinxi. So if Vinxi is interesting to you, then check out that talk.

00:44:05 - Anthony Campolo

Totally. So yeah, what am I doing? I am building AI stuff, but still trying to keep it in the JavaScript world because, I don't know, you ever used Python? It sucks, man. Holy crap.

00:44:25 - Dev Agrawal

A little bit, yeah. My girlfriend's doing her master's in business analytics, which means she's learning Python, which means that I'm kind of also learning and helping around with some Python concepts, programming concepts, assignments. And obviously a couple years ago I was also helping out some friends with Python projects. So it's an inescapable part of any programmer's life at this point. It's like JavaScript, you cannot escape JavaScript, you cannot escape Python.

00:45:00 - Anthony Campolo

I'm doing my best. But I think for people who can just use a Jupyter notebook, it's really nice. And the language itself is great. I got no problem with the actual language. It's just once you get into package management, virtual environments, Python version management, all this stuff that I kind of take for granted now in the JavaScript world because I've got things like Volta and npm, which has actually gotten pretty good.

So yeah, it's just a total nightmare. But anyway, this is a bit of a tangent.

I originally created this tool just for myself. So obviously I had a podcast for a very long time and I'm just a content creator in many mediums. I've always had audio, video, text, and something I always struggled with was creating good transcripts for a lot of the spoken content that I did. So the first piece of this was Whisper, which is OpenAI's open source transcription model, which is really, really good.

[00:46:11] And I started using that a lot in late 2022, beginning of 2023. And then when ChatGPT started coming out and getting really good, I started to realize that you could go to another level where you could take the transcript and generate things like high-level summaries of the episodes and even chapters with timestamps.

Because that was the thing that can really take a lot of time. You have to at least listen to the length of the episode to write the chapters, and then you have to write good descriptions. And I found that even though it wasn't perfect, it was good enough at finding the general shape of the different topics that it would require just minimal editing.

So once I realized that I could do this, and I could do it with both open source tools and any kind of off-the-shelf LLM you could find, even the free versions, I was like, okay, this is pretty cool. But that was a very manual process to have to use Whisper to do the transcription.

[00:47:18] I would then write a prompt with the transcription, give it to ChatGPT, and then get the answer back. So I was like, okay, what if I create a Node.js CLI that lets you input a YouTube link or a podcast RSS feed, and it will then run transcription, take the transcript, append a prompt, feed the prompt and the transcript to an LLM, and then give the response and put it all back in.

Then you'll be able to generate all in one shot, and you could almost create a whole web page based on an episode, because I also had to do frontmatter by pulling metadata from the YouTube or the RSS feed. And that's when I was like, okay, this is pretty cool. And then I started showing it to people, and I'm sure...

00:48:07 - Anthony Campolo

Podcasters...

00:48:08 - Dev Agrawal

Will kill for this.

00:48:10 - Anthony Campolo

So after I showed it to like 3 or 4 people, every time they're like, dude, you need to charge people for this.

00:48:17 - Anthony Campolo

Exactly, yeah.

00:48:19 - Anthony Campolo

Eventually that kind of convinced me to not just build it, not just continue having this open source thing, but to try and productize it now. The idea being that it'll just be like a dashboard with input forms. So someone who doesn't know how to run Whisper and clone down a repo and install your Node dependencies and do all that kind of stuff can just click and select the LLMs they want to use, select different prompts, and then just click a button, wait, and then you get it back.

So that's going to be the tool. And I ran it on your thing, your most recent episode which was about the thing we've been talking about. Let me see if I have the permissions to do this. Good. Okay.

00:49:08 - Dev Agrawal

So nice.

00:49:11 - Anthony Campolo

I'll read just kind of bits and pieces of this. So this is the default prompt. There's other prompts as well that you can select. The default prompt gives you three things. It gives you a one sentence description, and I usually use this as the description field actually.

So what I would usually do is take this and put it here so that you get a metadata field, which is nice.

00:49:36 - Dev Agrawal

Which you could also automate. But yeah.

00:49:39 - Anthony Campolo

Yeah, exactly. That's one of the last things because that part is harder to automate because the LLMs will not always give you back the response in the right formatting. So you have to do some kind of regex thing to differentiate the one sentence thing from the paragraph.

00:49:56 - Dev Agrawal

Couldn't you just, I mean, these days, can you just define a Zod schema like here's the structure I want the response in?

00:50:04 - Anthony Campolo

From the LLM?

00:50:06 - Dev Agrawal

Yeah, like I know even OpenAI directly added this in their SDK that you can define a Zod schema, and OpenAI literally will give you a structured response.

00:50:20 - Anthony Campolo

That's true. So if I was using structured outputs which would have it give it to me in JSON, then I'd be able to do that. The problem is right now I'm just using the completion API. So I just hit it and I get a whole string of text back.

So you're right, that's a very good point. And I just probably need to suck it up and build this in because it would give me more control over the output I'm getting from it.

00:50:48 - Dev Agrawal

It's not as good. Yeah, that also makes sense. Like, the more structured it is can, I guess, decrease the quality of the overall output. So maybe that's a trade-off.

00:50:59 - Anthony Campolo

The bigger problem actually is I have seven LLM integrations. I integrate with OpenAI, Claude, Mistral, Gemini, Cohere. So all of them have a completion API and they all work exactly the same because they all just copied OpenAI's thing.

So that's nice because then I have this really composable thing where I can switch out LLM services very easily. But once you start adding things like structured outputs, it's like, do Claude and Gemini have that? Are their APIs the same? Would I need to maintain code for all of those?

00:51:39 - Anthony Campolo

But it'll be like building all this AI crap, which is super fun.

00:51:43 - Dev Agrawal

Yeah, I mean, you can do it on top with Vercel. The AI SDK allows you to talk to any LLM and pass in a schema for structured output. It's the Vercel AI SDK, not v0. V0 is just a UI tool.

00:52:00 - Anthony Campolo

Right?

00:52:01 - Dev Agrawal

Yeah.

00:52:02 - Anthony Campolo

That's right, yeah.

00:52:05 - Anthony Campolo

Yeah, so that's a good point. The issue with that is then you use this one thing and they manage the connections to all the things. And I want lower level control because I also want like, I imagine this can also give you insight into what you're going to pay for one model versus another, but I don't really know if that's fair. I just don't know how often I would have to break it down.

00:52:36 - Anthony Campolo

What was that? Did I just see Bing? Oh, yeah. No, because I'm using Edge now, the Edge browser.

00:52:42 - Dev Agrawal

You just saw Bing.

00:52:45 - Anthony Campolo

Bing. But yeah, because I'm using Edge now, the Edge browser.

00:52:50 - Dev Agrawal

Nice.

00:52:55 - Anthony Campolo

So yeah, you have your episode summary which is the longer one, and you have chapters.

00:53:07 - Dev Agrawal

Yeah, this is fantastic.

00:53:18 - Dev Agrawal

I mean, if we can analyze long-form videos like that, it doesn't even have to be just podcasts. I guess this analyzes the transcript, right? Not the visual content.

00:53:31 - Anthony Campolo

Yes. And that's the thing, for what I'm doing, I find usually just getting the transcript is pretty much good enough. Like if it's a really code-heavy kind of stream, that might be harder because it would need more context into what's on the screen.

That's kind of what I'm now thinking about. Do I want to start integrating with the image APIs and have it take a screenshot every like 10 seconds or something like that?

00:54:08 - Dev Agrawal

Yeah, we definitely need these on Ryan's streams because they are not super code heavy. He tries to explain everything. So that works well.

00:54:22 - Anthony Campolo

Funny, as I was originally first building this, it was around the same time when I was on his stream for my Redwood episode, which was a five-hour stream. It was like three hours longer than any other stream I'd ever done. And that was the only stream I had out of all the ones I'd done that broke both Claude and OpenAI because it was too long for the context window.

00:54:46 - Dev Agrawal

Yeah.

00:54:46 - Anthony Campolo

Makes sense. After a couple months, the context windows got longer, so they became capable of handling a Ryan Carniato stream.

00:54:56 - Dev Agrawal

Yeah, that's true. It's also that he naturally breaks his stream into sections as well. So you don't necessarily have to run it for the entire stream, even if the context was smaller. But now that it's compatible, then yeah, it makes sense.

00:55:13 - Anthony Campolo

Well, it is nice to just get a high level description of each section, because usually when people do chapters, they'll have a timestamp and then a chapter title, but this will actually write you out like a one sentence, one paragraph description of what actually happens in the chapter. Which could be really nice because he just covers so much material.

So yeah, now that the tool is really built out, I need to go back. Because I could do this now, I can just run it on all of Ryan's streams.

00:55:42 - Dev Agrawal

How much did that cost?

00:55:45 - Anthony Campolo

Okay, so that's another big question. It depends on what LLMs you use. You have the six I mentioned, and then each of those has like 5 to 10 models with all these trade-offs of cost and speed and whatever.

I think if you go with the best cheap models for ChatGPT, Claude, and Gemini, someone was saying Gemini is super cheap. Those are probably going to give you a nice trade-off because you could find cheaper open source ones, but they're just not as good.

This makes me want there to be better open source models that we can use. And there are, but the issue is the open source models that are close to being as good are like 500GB. So you can't even actually run it locally, which kind of defeats the whole purpose.

So Llama 405 billion parameters is kind of the biggest one. But I'm on a fairly beefy one year old M3 MacBook and even still it would require almost my entire hard drive to use it.

00:57:02 - Anthony Campolo

I didn't even realize. I was making sure I had enough memory and GPUs and stuff like that, but I'm like, oh, I didn't realize I need a terabyte of storage just to save the model on my computer.

00:57:14 - Dev Agrawal

Yeah.

00:57:16 - Anthony Campolo

Yeah, so this is what I'm talking about. Things like Haiku, those are the cheaper Claude models, which are still pretty good.

00:57:25 - Dev Agrawal

Yeah, like even being open source, it would require at least one supercomputer.

00:57:33 - Anthony Campolo

Yeah, so the way I kind of get around that is I also offer integrations with Groq, not the Twitter Grok. It's an infrastructure company, along with Together and Fireworks AI. And what they do is they run the open source models on their own servers and then give you an API endpoint.

00:57:54 - Dev Agrawal

Right.

00:57:55 - Anthony Campolo

Yeah, it's kind of like using a service to run a blockchain. It almost defeats the purpose because you don't get to actually own the infra or your data. But you also don't get something as good as the managed services. So you kind of get the worst of both worlds to a certain extent.

00:58:14 - Dev Agrawal

Yeah.

00:58:15 - Anthony Campolo

I think the one advantage is that you could really push a ton of tokens in and out for very cheap and very fast. So if you wanted to process like literally a thousand podcasts because you've been podcasting since 2000, it would be probably good for that. Like really bulk data processing.

00:58:39 - Dev Agrawal

Yeah, I mean he has been streaming for like two years, so there's a lot of content. But if you've been podcasting for two decades, that's a whole different scale. I would imagine like .NET Rocks.

00:58:56 - Anthony Campolo

Which one?

00:58:57 - Dev Agrawal

Like .NET Rocks, which has existed for almost two decades, like 200 episodes of podcast. Yep.

00:59:06 - Anthony Campolo

Yeah.

00:59:09 - Anthony Campolo

It's funny. So I built this kind of for my own stuff and then I got sidetracked and just started making it a product. I never actually finished running it on all of my podcasts and videos because I ended up running it on all of them, but then I didn't quite have my Astro site configured yet to have different content collections. And then it just kind of fell by the wayside.

That is something that I'm probably gonna do, because that was partly the idea. I wanted good SEO for all of this content that I had out on the internet, but there's no real text content for it.

00:59:49 - Dev Agrawal

Yeah.

00:59:49 - Anthony Campolo

Hey, thanks for hanging out, man. Is this someone you know?

00:59:51 - Anthony Campolo

Yeah.

00:59:53 - Dev Agrawal

Yeah. From Twitter.

00:59:56 - Anthony Campolo

From the Twitters.

00:59:58 - Dev Agrawal

From the Twitters.

00:59:59 - Anthony Campolo

What do you do at your job? What does your company sell? What do you do?

01:00:05 - Dev Agrawal

My company sells us. It's more formally known as consulting.

01:00:19 - Anthony Campolo

Okay.

01:00:20 - Dev Agrawal

So through them, I'm currently working for a client, which is a healthcare company, building their next generation customer member portal. I don't know if I can talk more than that. I don't know at what point I came up with this analogy of a consulting company being like pimps, but yeah, essentially.

01:00:53 - Anthony Campolo

I would stop using that comparison. Don't say that.

01:01:02 - Dev Agrawal

Fair point. It's funny. I care more about being funny than...

01:01:07 - Anthony Campolo

I mean, I guess it's just a question of how good is your relationship with your boss and how good is his relationship with HR?

01:01:15 - Dev Agrawal

That's a good point. I don't even know who my boss is. The problem with being in a consulting company is that I spend a lot more time with my client company than my actual employer.

01:01:32 - Anthony Campolo

Interesting.

01:01:33 - Dev Agrawal

Like so in the last...

01:01:34 - Anthony Campolo

How did you hear about this company and get involved? What was your foot in the door?

01:01:39 - Dev Agrawal

The foot in the door was lunch and learns that they used to host back in Cincinnati when I used to live there. So I went there as a student many years ago. That's how I heard of the company. There were some people from the company who taught at my university.

I invited a couple of them to give some talks at our student meetups. Then when I was looking for jobs, I saw one of the recruiters post on LinkedIn. I reached out to them. She connected with the people that I already knew from Smartdata, or mutual connections. They gave some pretty strong referrals in my favor. Company name is right here.

01:02:38 - Anthony Campolo

Are you writing Java? I see that they're only hiring Java and .NET developers.

01:02:44 - Dev Agrawal

Luckily I am writing JavaScript and using Remix. So it's like one of the...

01:02:52 - Anthony Campolo

You mentioned that. Yeah.

01:02:54 - Dev Agrawal

Yeah. Usually in an enterprise environment, you don't get to do the things you like. You just get to maintain a bunch of legacy. But this is nice in the sense that they have some greenfield projects where they're using Remix, and that's what they were getting consultants for. That's what I lucked out on, working on a Remix project.

01:03:18 - Anthony Campolo

This is perfect.

01:03:19 - Anthony Campolo

For you and especially for where you are in your career, because you got to kind of live that startup life for a bit. And I think if you had stayed at Clerk for years and years, it would have been great, I'm sure, and you would have learned a bunch, but you would have been doing something highly specific, like writing a third party service.

Whereas now I imagine you're seeing multiple different types of apps for different types of clients with different numbers of customers and different constraints. How many projects have you worked on since you started? Are you just on a couple things right now?

01:03:57 - Dev Agrawal

Just one.

01:03:58 - Anthony Campolo

Just one. Okay.

01:03:59 - Dev Agrawal

Right now, just one. Technically two, if you count their identity portal, the login service, which is its own separate app. But yeah, this is basically what I was doing before Clerk. Before Clerk, for about three years, this was kind of my job. I was working at this place where a lot of companies outsource projects.

01:04:26 - Anthony Campolo

Yeah, I don't understand these messages.

01:04:31 - Dev Agrawal

Yeah, me neither. But I totally get what you're saying because I did get to experience a lot of that before Clerk, when I was working at a similar place where there were a bunch of different projects. So I got to do React, I got to do Angular, I got to do PHP, I got to do MongoDB. A bit of everything. Some mobile apps with Ionic or PWAs.

Was there any .NET there? Probably not. .NET was mostly class projects. But yeah, it's definitely a big diversity of projects. That said, there's a decent bit of diversity you can get at startups. I was a DevRel at Clerk, but even if I was an engineer, something like Clerk has its own auth service, then it has a dashboard and a whole marketing site.

[01:05:32] So there's a decent bit of variety in terms of what you're building at any startup that's non-trivial at this point.

01:05:43 - Anthony Campolo

That's true, but usually it's a single product focused business, or there's a general thing that is all encompassing. Okay, I get what they're saying. You work on things that people hate when you do this kind of stuff. There's something to that. But also if you don't, you would never use them otherwise if you weren't forced to.

01:06:09 - Dev Agrawal

Yeah. And that's where I feel like I lucked out because I work in an enterprise environment, but I'm also working on a greenfield Remix project, which is very nice.

Although, three months from now I could be assigned to a different project, or the contract is ending, and now I'm maintaining a six year old code base that was written by other engineers who thought they were very smart, implementing a bunch of abstractions that did not stand the test of time. Now it's an unnecessarily complicated code base, which is kind of like the code bases that I've written three years ago. AKA me three years ago. Exactly.

01:07:01 - Anthony Campolo

Totally. Well, as long as you're not having to work on COBOL apps, you're still doing pretty good.

01:07:08 - Dev Agrawal

I did have a friend who graduated college a year before me, who interviewed at a place, moved to Atlanta to work for them, was very excited. And then a month or so into his job, they handed him a COBOL book and said, hey, this is what you're working on, please learn COBOL.

01:07:29 - Anthony Campolo

Do you know Austin Crim?

01:07:33 - Dev Agrawal

I do not.

01:07:34 - Anthony Campolo

He's, I forget where he's working these days. He worked at Prisma for a little while. He's a buddy of mine from a while ago. His first programming language was COBOL, and I'd never met anyone who had ever said that before, especially someone who's roughly my age. I'm like, how the hell did that happen?

He was like, my dad told me, learn COBOL because all the COBOL developers are dying. His dad was a COBOL developer and had this insight because all the banking systems were written in COBOL and no one was learning it, and all the people were aging out. So he was just like, this would be a valuable thing. So he learned COBOL as his first programming language and then did COBOL jobs.

01:08:19 - Dev Agrawal

Nice. Honestly, that's a great way to make a lot of money. Even today. Around COVID there was a big demand and a lot of pay for COBOL developers, I remember. I'm sure that's still the case.

01:08:36 - Anthony Campolo

Yeah. I remember seeing that there was a specific New Jersey government agency that was like...

01:08:44 - Anthony Campolo

We need COBOL.

01:08:45 - Anthony Campolo

Developers. And I feel like it kind of got blown into a bigger story than it probably was.

01:08:51 - Anthony Campolo

That's fair.

01:08:52 - Anthony Campolo

Yeah, but a good use case I think for LLMs actually is just refactors. You could take a lot of COBOL code and port it in a way where most of it would turn out just fine for whatever language you need to put it in.

When you have to build new features, it doesn't necessarily have enough context into your whole app and it can do weird stuff. But if you're literally just taking hunks of code and saying, take this and put it in another language, here's a bunch of tests, make sure the tests pass. I feel like it's probably easier these days to refactor a COBOL app to another language.

01:09:32 - Anthony Campolo

Yeah.

01:09:33 - Dev Agrawal

There's actually a startup that's doing some work in this area, Codemod. The founder, typical story. Worked at a FAANG company, had great internal developer tools, got out of the FAANG company, wanted those advanced developer tools for the rest of us and built a startup out of it. Same story that we see in Nx and a bunch of these other startups.

So they're building a codemod pipeline and then using LLMs to generate the codemods, which means that your actual refactors and code migrations are deterministic because they are codemods, but AI helps you generate the codemods instead of doing the refactors themselves. I feel like that's a pretty good approach to this whole AI-driven refactoring space.

01:10:34 - Anthony Campolo

This is why you're the GOAT, Dev, because you tell me about things like this, which are the exact things that I want to know about, but I don't know about because I don't spend as much time just looking up new shit anymore. So thank you for doing all this work when I don't have the time to do it anymore. This is really cool. I'm gonna check this out, actually.

01:10:57 - Dev Agrawal

Yeah, always willing. I'm hoping that we can get one of these for Remix or React Router, and maybe... I know they have one for Angular to React.

01:11:14 - Anthony Campolo

Yeah. I was looking at it. I really want to... I saw...

01:11:16 - Dev Agrawal

Yeah.

01:11:16 - Anthony Campolo

It had like upgrade to React 19. One that they've been...

01:11:23 - Dev Agrawal

Working with framework developers on a lot of these. So like React 19, Next.js, Nuxt, Vue, I think one of those.

01:11:36 - Anthony Campolo

Yeah. React Router is probably its own category because they do so many rewrites. They always got so much shit for it.

01:11:44 - Dev Agrawal

Yeah, it's great. And now they're trying to make sure everything is backwards compatible. But they've had their own levels of pain.

01:11:54 - Anthony Campolo

I remember when I was in my boot camp, the teachers would be talking about how they'd have to rewrite the React Router curriculum every time. That was the main thing that would be changing. A lot of the stuff they wouldn't have to really worry about, but we'd be learning React Router 5 and they'd be like, oh, with 4 I used to have to do it this way. And I was like, I don't have to learn all this crap.

01:12:17 - Dev Agrawal

Yeah.

01:12:24 - Anthony Campolo

Cool, man. Anything else you want to talk about before we start closing it out?

01:12:30 - Dev Agrawal

I want to hear more about the product that you're building. Where you're at, whatever you're comfortable talking about. You don't have to talk about the things that are not built out yet or that you want to keep in stealth mode.

01:12:45 - Anthony Campolo

No, I'm happy to talk about it for sure. So the way I was developing it throughout most of the year, I've been developing pretty much all throughout 2024, and the majority of that was spent just on creating a CLI. That was a really good foundation for me because it allowed me to think very clearly about what I wanted it to do. Every time I wanted to do a new thing, I would have to just build a new flag.

So once I figured I had this huge set of things the CLI could do, basically you could run it on video or audio files, you can run them on local files or files on the internet, and then you can run it on RSS and you could process it in different ways. You can use different transcription services, you could use different LLMs, you could configure different prompts. It was very natural to just keep building out the features.

[01:13:51] Then I was like, okay cool, so now I just have to take all that stuff, stick a Node server in the front instead of Commander, which was the CLI framework I was using. Most of that logic stays exactly the same. You just have some endpoints instead of specific CLI commands. You send JSON with your key values that just does the stuff that your CLI would have done. Instead of doing --llm ChatGPT, you would just have a JSON object with llm: "ChatGPT".

01:14:25 - Dev Agrawal

It's not a GraphQL endpoint?

01:14:28 - Anthony Campolo

At this point it would be pretty easy to stick a GraphQL endpoint on it. I might just for old time's sake. But I use Fastify actually, which I'd never used before. Since it wasn't going to be just a demo app, I didn't want to use Express, but I also didn't want to...

01:14:46 - Dev Agrawal

Just...

01:14:47 - Anthony Campolo

Build a straight up Node HTTP server. Fastify felt like the right thing in that it's very established, it's been around for a while, it's well maintained, and that's kind of worked out well.

Then the next step was just sticking a UI on the front, where you have input fields that correspond to what the different CLI flags were. So that's what I've done. I started with the CLI, then I built the server, then I built the front end.

Now though, the front end is just a very basic form with some input fields and some dropdowns to show you what all the different options are. The hard part now is going to be actually making a really good app experience, which is going to require having a dashboard, having a login, having some sort of payment service, because it's going to be a product that people pay for, since you have to pay for the LLM and transcription services.

[01:15:57] Unless I want to spin up my own servers that did the transcription and just host Whisper and host a local LLM, which I don't think really makes a lot of sense, mostly because the local LLMs just aren't good enough.

So what I'm going to do is have a credit system where people can buy a certain amount of credits and then generate as much stuff as they want. The credit amounts will be different for more expensive LLMs. It'll cost more credits to use Claude 3.5 versus Claude 3 Haiku, and so on and so forth.

The payment thing is simple, it's going to be Stripe, I'm sure. And the real question, which I haven't yet decided, is what to do for auth. Whether I want to use Clerk, whether I want to use one of these open source auth things. So obviously, I would be remiss not to ask a man who worked at an auth company. Should I use Clerk or is there an open source thing? Because what was Lucia?

[01:17:02] That one is now dead and was turned into a tutorial, which I think is kind of badass because he basically said, I don't think this framework should exist. So I'm going to delete it and put a tutorial that shows how to do auth yourself instead, which I was like, what a baller move. So what are your thoughts on auth in 2025?

01:17:28 - Dev Agrawal

I mean, 10,000 monthly active users is still a pretty big deal for that Clerk offer, so no reason why not.

01:17:38 - Anthony Campolo

10,000?

01:17:39 - Dev Agrawal

10,000 free monthly active users? That's still a very high threshold.

01:17:48 - Anthony Campolo

Sure, but an open source library would be infinite for free.

01:17:54 - Dev Agrawal

Fair, but it also won't be as good. And Clerk's payment integration can't get here soon enough, honestly. I'm just waiting. I know we talked about it last year when we were at Render ATL, that Clerk might have built-in payments so you don't even need to reach for Stripe APIs. You can just ask Clerk for a certain amount, like charge this user this much money and Clerk takes care of everything else.

There's also been a new wave of open source tools like Better Auth and there's probably a couple more that I haven't really looked at, so I don't know how good exactly they are. I would definitely say that Clerk is a pretty good starting point. And you can always move to one of these open source solutions if you feel like you can't really afford Clerk at any point and if you want to really customize everything.

01:19:08 - Anthony Campolo

Yeah, I guess the question will probably be since I have the Fastify server and an Astro front end, I'm going to need to be managing auth on both. So I know Clerk has an Astro integration and also has a Fastify integration. Would I use both of those?

01:19:33 - Dev Agrawal

Sure, yeah. I mean, you only need the Astro integration if you never make any direct request to the Fastify server from the client. If you're only talking to the Fastify server from the Astro server, then you don't need auth on that level. You only need it in Astro then.

01:19:56 - Anthony Campolo

Yeah. Well, the app itself, you're going to be creating show notes which will then be written to a database, which then you'll want to access. And the show notes should not be visible to other people. So I guess if you authenticate on the client then that would handle that, but you would still want a server-side check just in case based on the limited amount of what I know about security.

01:20:24 - Dev Agrawal

Yeah, that's what I mean. If you proxy them through Astro, like Astro actions, your request goes to the Astro server first. That's where it gets authenticated. And then it goes to the Fastify server. So then the Fastify server doesn't need any authentication because you've already authenticated it on the Astro server. So you're using the Astro integration there.

01:20:45 - Anthony Campolo

Yeah. And this is the other question, should I just get rid of the Fastify server and implement all the server side logic in Astro?

01:20:53 - Dev Agrawal

Yeah, I definitely recommend that option. You already have a server, you don't need another one.

01:21:02 - Anthony Campolo

Yeah, I guess I just like having a decoupled headless backend. And I guess you could still technically deploy the Astro server part as a decoupled thing. I'll have to explore this because I've done a lot of Astro, but I've always just had a blog with markdown pages, so I never really was using any of the server stuff. I never would write server function code like I would for serverless functions and stuff like that. So I need to explore that more and see what exactly that's like.

01:21:42 - Dev Agrawal

Yeah. Astro has pretty much everything that you would need that you would want from Fastify. So you don't really gain a lot by putting those endpoints into a separate Fastify server. I'm pretty sure Astro has API endpoints. So it would be separate API endpoints exactly like you have it now, but they're in the same code base so you don't really need to split that out. And you could probably share types much more easily.

01:22:15 - Anthony Campolo

I also saw you're using Bun earlier. Should I say screw it all and use Bun instead?

01:22:22 - Dev Agrawal

I'm only using Bun as a replacement for npm. So it's bun install, bun run, bun start. It's replaced npm for me. It hasn't yet replaced the Node.js runtime and I don't know if it will.

01:22:41 - Anthony Campolo

Yeah. Where I'm at with it is AutoShow. You can actually run AutoShow with Node, Deno, or Bun, but Deno and Bun are just running the Node compatibility layers, which totally defeats the purpose because a lot of the performance benefits you would get from Bun is by using their native API. So I'd have to rewrite it anyway.

01:23:01 - Dev Agrawal

Yeah. And if you want to go all in on Bun, then Elysia is the best choice out there. It's a fantastic framework. It's very, very fast. Fully takes advantage of Bun's own performance. I haven't tried it out yet, but I know it's literally the fastest JavaScript server that you can run at this point.

01:23:29 - Anthony Campolo

Yeah, Bun is pretty tight. And I'm finally using TypeScript, which I was very reluctant to do for a long time. And that is pretty nice. Having Bun where you don't need things like TSX and stuff, that to me seems pretty nice.

01:23:47 - Dev Agrawal

Yeah. I do use Bun directly if I have just some TypeScript files that I need to run to test them out, some scripts, things like that. Very useful.

01:24:02 - Anthony Campolo

There's something I had wanted to do like a year ago. I was thinking about having you come on and do a stream about Effect. Is Effect even still a thing anymore?

01:24:14 - Dev Agrawal

Effect? Yeah. They raised a bunch of money as well and they're doing a lot of cool stuff. They raised some money to build a durable execution engine. So something like running a bunch of Node servers where everything is handled concurrently and handled nicely between them with multi-step workflows, basically. Like if you've seen Temporal, building something like that for JavaScript.

01:24:48 - Anthony Campolo

Interesting.

01:24:53 - Dev Agrawal

Yeah, durable execution. It's not BS. Durable execution is just a nicer syntax on top of something that you would probably want to do anyways, but you would have to write a lot of painful logic for it. So it's a whole tangent if you get into discussing durable execution.

But yeah, that's what they raised money for. They're building that. Effect itself I think is doing pretty good. They recently started a podcast called Cause and Effect. I think they're only at their first episode.

I haven't gotten around to using it actually, but I've thought of the frameworks that I'm building to build on top of Effect. There's a pretty big barrier still on trying to adopt it because there's a lot of things in there.

[01:26:01] Obviously you don't have to use all of them in your project. You can just use one or two of the core things. But I just have to find some time to really dedicate to building something with Effect, getting a feel for it, and then maybe pitching it to my work projects and my employers like, hey, this is something that we can and should use.

01:26:28 - Anthony Campolo

Yeah, my thought was if I'm going to do the TypeScript thing, I want to do it right and get the full benefit. And it sounded like that would be good just because it would give you more of the end-to-end type stuff. But now I'm just going to have an Astro project anyway. Astro is going to handle the end-to-end type safety, right?

01:26:55 - Dev Agrawal

Yeah. End-to-end type safety is not really the big goal. It's more like when you go from regular JavaScript to TypeScript, there's a level of security that you feel knowing that there's a whole category of bugs that now are not going to exist just because the compiler knows a lot more.

It's kind of a similar thing going from regular TypeScript to Effect, where suddenly the TypeScript compiler knows a lot more about how your code runs, not just what your data looks like. So there's now another category of bugs that are never going to exist.

It has a similar hurdle. Going from regular JavaScript to TypeScript, you have to learn the type syntax. You have to write your code slightly differently to make sure you're always doing type safe things. You have to know how to rely on type inference. You have to make sure you define your types and then share them. There is a learning curve, but once you get there, it actually makes you faster instead of slower.

[01:28:04] It's something similar with Effect, where it is going to slow you down a decent bit in the beginning as you figure out your way around things. But in the long run, it's always going to reduce a category of bugs and give you that safety. Now the compiler knows how your program executes, what it depends on, where things go wrong, what errors can be thrown and how they're handled.

If you go a little further and use their concurrency primitives, then it can make things faster as well because we don't normally handle concurrency that well. Now if you're doing multi-step AI workflows, that might be something that is valuable. But for simple apps, that's not really valuable.

01:28:52 - Anthony Campolo

Yeah, it's funny. A lot of what you were saying in terms of the things it was trying to solve and what it would give you is kind of like Lambda Dragon. Aldo's thing is that he had this Rust thing that would give you insight into where the code runs and even into specific things like infrastructure and your AWS resources and all of that.

And what you said about the more upfront work and learning but then greater type safety in the end, that was kind of what I got the sense of from the little bit I had read about it. So yeah, I might check it out. I'd actually originally wanted to bring you on so that we could talk about types and stuff. We didn't really get to that. We had a bunch of other stuff to talk about, but if you wanted to come on again in a couple of weeks, I would like to actually dig into that.

[01:29:41] At any point, how I've been typing the project, because I basically wrote it all in JavaScript and then gave it all to Claude and ChatGPT and said write my types. And that kind of got me to the point of having types that basically worked. But there's a couple of things that were kind of weird with them, and I've started to iron out some of those issues, but I feel like I need someone who actually knows how to think more holistically about how to type stuff. So that would be a fun thing to do for another time.

01:30:16 - Dev Agrawal

Yeah, sure. I try to do a lot of the type stuff upfront because you've probably heard of the phrase where if you design good data structures, then the algorithms will kind of just fall out of it, like whenever you're trying to solve CS problems.

So it's kind of similar in that sense where a lot of your type definitions, like better type definitions upfront, can make the rest of the work much easier. And the kind of flip flop where if you either don't try to design them or if you have a bad design for your data, like your data types and things like that, then it actually just makes your job harder. So yeah, I totally get that.

01:31:03 - Anthony Campolo

Because this is one of the pitches I would make for GraphQL, because you would start with your schema and then a lot of things kind of spin out from that. And people always complain about how there's too much overhead with GraphQL, you need to do all this kind of stuff.

And I'm like, I mean, not really though. Not compared to writing TypeScript types. A schema is very, very narrowly defined in GraphQL. There's very few things you can put in that schema. And it's like if you're an experienced dev, it should take you like a week to learn how to write a GraphQL schema. I never understood why people complain so much about that.

01:31:12 - Dev Agrawal

Exactly.

01:31:36 - Dev Agrawal

Yeah, it's a similar thing.

01:31:41 - Anthony Campolo

Yeah, I do know why people complain. People complained about GraphQL because the ecosystem of libraries, especially Prisma's libraries, even as much as I love Prisma, they kind of made a whole mess of a lot of stuff. And Apollo, also Apollo and Prisma, they created all these open source libraries. Some of them ended up being rewritten, some of them got dropped, some got renamed, and it was confusing as hell for everyone involved.

But if you threw all that out and you just learned the GraphQL spec, it was ridiculously simple actually. Like if you had to build your own GraphQL server from scratch, obviously that would be more challenging. But I'm saying just writing the schema, writing your queries, like all that stuff actually was very, very simple.

The problem is people tried to use all these things like Apollo and Prisma and Nexus and, you know, and then everything was so confusing. But that was more of an ecosystem problem than a GraphQL problem. GraphQL Yoga is one of the things that helped fix a lot of these issues.

01:32:48 - Anthony Campolo

Actually, I remember when Redwood integrated GraphQL Yoga because they dropped Apollo Server and it was like the end of an era. It felt like the end of an era in GraphQL. So I was like, Redwood's not using Apollo Server. Finally.

01:33:03 - Dev Agrawal

Yeah. And then obviously there's things like Relay which will solve every one of those problems for you, but it'll be like 20 new things you have to learn.

01:33:16 - Anthony Campolo

I learned basically every single GraphQL library framework except Relay. I never did a single thing with Relay because Relay got, it was all wrapped up in a lot of the old way of doing React, like you'd have React and Flux and Relay. Yeah, and that was all worked together very, very well.

But then people started throwing out Flux and Redux and then they would have other ways of doing GraphQL. So it wasn't entirely clear when you would want Relay or when you wouldn't. And yeah, that one was always confusing to me.

01:33:50 - Dev Agrawal

Yeah, I think at this point, I still think React Relay is kind of the ultimate stack for front end apps because Relay has things that literally no one else has. And everyone's trying to chase things, like things that have existed in Relay forever, like the ability to just put your queries in your component and not cause like 20 spinners [unclear] to show up.

Like, that's the primary thing that everyone's trying to solve. But no one is able to solve it because no one is using GraphQL. And you need GraphQL to solve it.

01:34:26 - Anthony Campolo

You have no idea how many times I said what you just said about Redwood. People always talk about why that, you know, they're like, oh yeah, Redwood's cool, but I'm not gonna use it. And I'm like, you don't understand what it's giving you. And how many things actually become much, much simpler if you just take the GraphQL hit.

So I was kind of bummed when GraphQL kind of, quote unquote, fell out of favor. Obviously it hasn't gone away. It's still used in lots of places, but at a certain point, it was just people who were into new web dev stuff. They're like GraphQL is done. We got beyond GraphQL. I'm like, okay, bro.

01:35:07 - Dev Agrawal

Yeah, most of my talks that I give, like because a lot of them are around full stack, almost every time I have to add at least one slide about, by the way, if you're using GraphQL, this talk doesn't really apply to you. You're not facing these problems that I'm talking about.

You can just use these tools and your life is fine. You, in fact, have a whole different category of problems of how to implement GraphQL properly or how to write schemas, which I cannot tell you anything about.

01:35:37 - Anthony Campolo

Totally. Yeah, it's funny man. All right. I think we'll call it here. This is a super fun conversation. I'm really glad we got to catch up. And yeah, I'll try and keep in touch with you better. I fell out in terms, once I stopped doing as much stuff on Discord and X, I wasn't as good about keeping in touch with a lot of my friends, but I see your tweets all the time.

01:36:04 - Dev Agrawal

Thanks. Yeah, thanks for having me on. Actually, one random quick question. What exactly happened to Edgio?

01:36:14 - Anthony Campolo

They had a thousand people not building anything. And someone realized at a certain point that this is not a good way to make money. Yeah. I mean, the problem with Edgio is that it was an amalgamation of three different companies, one of which was a web deployment thing. One was a video streaming service, and one was a security thing.

And they never really coalesced into a product that was actually compelling enough to get people to switch off of Cloudflare or Akamai. And so even though we could have, you know, better performance stats or whatever, that just was kind of an uphill battle. And, you know, it was just a classic case of a large enterprise tech company with a lot of bloat.

Like, there was one point where the entire company, every single person stopped doing any work whatsoever because we had to spend a month migrating from Slack to Microsoft Teams. And it's just the amount of work it took to do that, it could not have possibly been worth the money we were spending on Slack. There's just no chance, you know?

Yeah. So just stuff like that. And, you know, there's lots of different layers of silos. So I never knew what the hell anyone in the company was doing, even though I was the DevRel person and I was writing this community effort. But we never had a clear path of how to get the community effort to pay dividends for Edgio.

So at a certain point, they dropped JavaScript Jam and they just were like, hey, you can now do security stuff. And I'm like, I don't know anything about security. Like, the hell am I gonna do about security stuff, you know? And so I kind of saw the writing on the wall and quit in March of this year, and then they declared bankruptcy a couple months ago. So they're gonna be, I think, you know, broken down, sold off for parts, I'm assuming.

01:38:17 - Dev Agrawal

Yeah, yeah. I saw that tweet about the bankruptcy. I was, yeah, that was fun.

01:38:25 - Anthony Campolo

Yeah. And I'm especially salty because I asked them if they wanted to just sell off JavaScript Jam or just let me take it over. And I told them I would keep doing it for free. And they were like, no, we want to hold on to it because it's our company IP, and then they just did nothing with it.

And now the domain is expired and all the shit that I wrote, all the content I created, now they're all dead links. I'm just like, hey, man, it's so frustrating.

01:38:58 - Dev Agrawal

Like, even the recordings.

01:39:00 - Anthony Campolo

So the recordings are still up on the Transistor site, but the Transistor site I don't have access to anymore. So at a certain point, even that's gonna lapse, I think, because that needs to be a paid service. So all of the stuff is still on the Web Archive.

So what I might end up doing if I'm going to try and buy the domain because it expires in two months. So I'm gonna just try. So I'm gonna see if I can just buy JavaScriptJam.com and then it would be fine. But if not, what I'm going to do is I'm just going to rehost it all just on AJCWebDev.com.

01:39:34 - Dev Agrawal

Makes sense. Yeah. That's a real shame. Yeah. Well, good to know. Thanks for the quick exposition there. I was curious.

01:39:45 - Anthony Campolo

Yeah, it was a learning experience for me for sure. Because, you know, when I got the job, I was like, oh, I'm gonna be working for this big tech company. It's publicly traded and has all these big customers and job security, and it's just, not how it went at all. You know, it was far more unstable and less job security than I had at like ten and 100 person startups that I was working at before.

So I'm glad that I went through the process. I learned a bunch, and it also put me in a position where I kind of had to figure out what I wanted to do for my own thing, because I've always wanted to not have to have a boss or work for a company. But I had to just to make money at a point because I was learning to code at the same time that I was trying to get a job. So, you know, it wouldn't have made sense for me to build a product 3 or 4 years ago because I had no freaking clue how to do it.

So now that I have some, you know, skills, I've worked with a lot of companies, I'm like, okay, now is the time for me to see if I can just bootstrap a basic indie hacker thing and just make enough to cover my own expenses. And then I really think that that is going to be the way to go, because then I can slowly build it over time. However I want.

And, you know, I wouldn't be opposed to taking VC money at some point in my life to build some sort of product, but I want to first try and just bootstrap something myself, because, you know, I'm not trying to build a hyperscaler kind of company, you know, and make billions. I just want to have tech that is useful, that I have full autonomy over and that I can make a decent living at, you know.

01:41:28 - Dev Agrawal

Yeah, that makes sense. This is something I wanted to do for a while, but at least until my education loans are paid off, I just cannot think of it. So until then, it has to be: I need some sort of stable income, and I need to be able to live in this country to continue to make stable income.

And then once maybe my loans are paid off and maybe my partner is also making money so I can be less reliant on my income, I'll be like, okay, now time to take a break, do some open source work or build some indie products.

01:42:07 - Anthony Campolo

Yeah. You gotta think about what can you build that would give value to people?

01:42:13 - Dev Agrawal

Yeah, that's also, that's something that scares me. I'm like, I don't want to do business. I don't particularly like doing business. Building a product is doing business, basically. I'd much rather just solve technical problems. Like, hey, here's a technical capability that I think that we should have. Can I build that?

If you ask me if I can sell it, I'm like, hell no, I don't have a clue. Yeah. Signals on the server is what I wanted to build. That's it. I have no idea how to sell it or how to make something that sells.

01:42:49 - Anthony Campolo

So you're a classic tech nerd.

01:42:53 - Dev Agrawal

Yeah. Pretty much, yeah. I have not. I need to watch it. I keep hearing references.

01:43:03 - Anthony Campolo

I'm sure lots of people have told you to watch it, so I don't need to belabor the point. Yep. But it is so well done and illuminates so many things about Silicon Valley and that the founder, he builds this compression algorithm and he is the biggest nerd ever and doesn't understand anything about business, doesn't know anything about people. He's just straight up autistic as fuck kind of dude.

01:43:33 - Anthony Campolo

Totally. Yeah. No, really. Except even imagine Ryan Carniato but also doesn't have people skills or communication skills.

01:43:41 - Dev Agrawal

Right? Yeah. Makes sense. So me.

01:43:47 - Anthony Campolo

Dude, you clearly got communication skills. You're, I mean, you're most known for tweeting. Let's be honest here.

01:43:55 - Dev Agrawal

That's fair. Yeah, but it's a recent thing. If you had known me four years ago, you wouldn't have said that I have communication skills. Like, literally four years ago, not even that long ago.

01:44:08 - Anthony Campolo

I knew you three years ago, I think.

01:44:12 - Dev Agrawal

Yeah, but yeah, I get, okay. Yeah. I need to watch that show. Cool. Okay. Thanks a lot for having me on.

01:44:21 - Anthony Campolo

Keep going. But I'll call it here. Just stay on for a second. Thank you.

01:44:25 - Dev Agrawal

Everyone needs to start packing up. I need to... yeah, yeah.

01:44:30 - Anthony Campolo

And people saw your Twitter handle and your company, so we don't need to do any of that. All right. Bye, everyone.