You Need a Monorepo × Client Only React × TanStack + More

Welcome to Sanity. Today, we got a potluck episode for you today. Keep the questions coming. Syntax.fm.

In the URL bar, you can submit your own question, and we'll answer it on a future episode. Today, we're talking about monorepos.

Really good explanation or or really good question about a problem somebody has that a monorepo is going to solve it. Do you really need a server for a React application, or is is a CloudFlare worker enough for for when you need that? A Java developer thinks that the Node. Js ecosystem is a mess. A good question about, like, how do you possibly use Next. Js without tan stack query? So we're gonna go into a lot of the new invalidation APIs on Next. JS, someone transitioning from, a musician to an engineer, and all kinds of new stuff. Let's get on into it. I'm wearing a different shirt right now because we forgot to record this ESLint. So now we're gonna cut to me and Scott. Awesome. And if you would like the best tools to make sure your application is running as smoothly as possible, head on over to century.io.

In fact, they just added uptime monitoring, which is, something that I use uptime monitoring all the time. And now I don't have to go somewhere else for it. I can have it directly in my my Sanity settings to make sure my applications are up as much as I think they are. In fact, I had an issue, Wes, with my Sanity path, which was hosted on Coolify.

And Yeah. Something happened with my Coolify or my server, And I didn't realize that it crashed. But what it didn't do is it didn't restart all of my services.

So here, I I I know that my server's up and running, but Yeah. The habit path was down, and I didn't Node. Because, I mean, I use it. I didn't know until I used it. Somebody Sanity me a message or whatever, but that's exactly the type of issue you don't want with any application, especially something if other people are using it. Right? So uptime monitoring is something that's important to have on just about any web property that you care about people seeing. Because if you're not checking it twenty four seven and it goes down, you might not have any clue. So, check it out, century.i0/syntax.

Sign up and get two months for free with the coupon code Sanity treat. This podcast is presented by Century.

Let's get into the potluck questions, Wes. First question here from Secret Agent.

Hello, Wes, Scott, and CJ. Been listening for a few years as I transitioned from being a musician to software engineer. Thanks for all of the help over the years and, specifically, Scott for showing me a music major can be a developer.

That's me.

Just got my first full time job, but I find myself wondering if we are shooting ourselves in the foot. We have a separate repo for each layer of our app, the front end, RestAPI layer. What arrest RestAPI.

RestAPI?

Hereby, four word, arrest API is gonna be called the RestAPI.

It's a RestAPI. I I just heard that it's all one word here, the Wes API layer. I was like, what's a RestAPI layer? This is, fascinating.

So their their front end wrote Wes. RestAPI. Okay.

Anyway, carry on. Yeah. Let's carry on.

The front end, the Wes API, services layer, the repo layer, workflows, and task layer. Each time I make a change that spans more than one layer, I have to do more than one PR. Get something reviewed more than once and then make sure the merge and deploy happens at the same time to make sure everything works together in prod as expected. I get decoupling, but for a small startup, this feels excessive.

Is this an instance where a monorepo would help, or do you have some other advice for me? Thanks for answering. To me, when I read this question, I'm smashing I'm smashing the monorepo button because I I like that, and I like that workflow. And there's a lot of monorepo tools out there, some of which are very heavy handed and feel like they can take over a whole lot.

I use PNPM with PNPM workspaces.

NPM also has workspaces that are a little bit more cumbersome. They exist. Yarn has workspaces.

So workspaces are a great way to get monorepo stuff going. I'd also recommend using turbo repo, which is something I didn't think I needed for a long time, but then I'm running, like, five dev processes at once. Turborepo makes that so much easier and so much faster. So I I highly recommend, you know my my workflow for this is p npm workspaces and turbo repo, and that's it. And I I I think, personally, that's a a nice way to be for something like this. If you are

hoping that deploying everything at the same time is your approach to making everything work together, it sounds like you need a monorepo.

If you are not, then you need to start versioning your APIs, meaning that you leave the old version of whatever API running for a while until enough of your traffic has has moved over.

And you can do that either by different domain names.

API key is a is another common way where you you generate an API key that's attached to a specific version of an API.

Mhmm. But, like, that's that's so incredibly complex, especially for a startup Wes a monorepo is a much better approach to this type of thing that like, you see some of these node modules that are published.

Like, for example, Next. Js has has that, but they have Next. Js image. They have, like, six or seven different versions. And every single time they publish one version of something, every other package gets published as well. Right? In that way, all of the changes can go out as one, especially if you're trying to update a back end API as well as update, like, a UI layer in, your RestAPI API is also being updated. It's all Scott go out at once, and it's so much easier in a monorepo.

Just casually throwing the RestAPI in there. I love it. RestAPI.

Hello. Ricardo says, hello. I'm a Java developer. Condolences.

For professional reasons, it's taking its first steps in Node. Js. Greetings for Portugal.

I'm wondering if it's my impression if most Node. Js libraries are generally poorly maintained coming from nearly twenty years of Java development. I've noticed at least at least on the back end for things like ORMs and caching, the latest release of many Node libraries seems to be several years behind. They often appear to be maintained as a hobby rather than a structured approach. I'm used to seeing this in Java. What are your experiences in Node. Js in this regard? Do you feel like everything is abandoned or generally more well maintained? That's a good question. I I think, like, there are a whole slew of packages in the Node ecosystem that are sort of I don't know. Like like, I'm thinking of Express. I'm thinking of of Mongoose.

I'm thinking of some of the more established packages that are maybe not the things that we reach for immediately, and these are maybe the things that you're finding when you Google, like, web server in in Node or something like that. And you kinda have to be in the know of what's going on because if you were to look at the most popular packages in Node. Js, those are maybe not the things that you would grab right off the the bat. But I don't know. You're talking about ORMs. We have several really well maintained ORMs, several good approaches to caching. I I don't think that this is necessarily the approach, although the Node. Js and JavaScript ecosystem does tend to change what we like to use much more frequently than, a more established something like like the Java ecosystem, especially it's

much more corporate. You know? Yeah. It is interesting. You know? I I also, you know, come across this in, like, the Rust ecosystem where I found a lot of abandoned Rust packages.

And people say that they're done, but then I'll find, like, stuff that just straight up doesn't work, and then you're you're pulling through it. And there's like, oh, this hasn't been touched in, like, two years. And so I think I find less of that with JavaScript, and, you know, it could just be ignorance on all parts on my part.

So, yeah, it it really depends on, I guess, what you're using, how established it is. There could be abandoned stuff Wes there could just be, like,

you know, it's been baked into the the language now or, you know, there's no reason to use x, y, and z. But for the most part, I don't necessarily feel like I've had this issue. One thing I'll also say about that is because JavaScript is kinda bring your own for everything, you gotta, like, piece together the parts yourself for the most part. It can be often very hard to figure out what do I use for x, y, and z. What do I use for an ORM? What do I use for type validation? All of those things. And if you simply are just googling for that, it's it's really hard to find out what people are actually being used. I like to use socket dot dev when searching my dependencies, and that does give you a little bit of a better idea of of what's being used. But I would like even something further JS of like, okay. Here's a package. Like, what have people switched to or, like, what are similar packages in this area? You Node, you when you're shopping for something on, like, Amazon, and it's like, well, you might also like this one, which comes with an Allen key. You're like, yeah. Okay. I would like that.

Alright. Next one here from Brett Perry.

Oh my gosh. Brett, he specifically says Scott Perry like pee eery.

So pee eery.

Sorry, Perry.

Sorry, Perry. I called you Perry. Perry. Brett, hey, Syntax Nation. I have ideas for a new collaboration based product that will start as a micro app and add more micro apps over time to make a suite.

I'm wondering if I should do straight up SvelteKit or go local first with PowerSync, Scott's new hotness.

Which would you use? My first question for you all, been following you from pre syntax days. Yeah. I I'd I've seen Brett, online a lot. So shout out to Brett. What's up? So you know what I would use? I don't know. I'm using pretty much I'm pretty much using Deno Sync for everything right now. Typically, with Svelte, SvelteKit, specifically, I wrote the library bindings for it. I really like it. I have a few production apps working with it right now. That said, Deno sync is not shaky super shaky ground, but things change. You know? There's been changes here and there to the permission system, to the, the schema definitions, and that stuff's kind of happening as it goes. Now I don't think it's gonna massively change, but it's not the most absolute solid ground today. That said, if you're the type of person who doesn't mind that type of thing, and you want to use something like that, man, XeroSync's a great option. I I I have such a good workflow going right now with ZeroSync Wes because there's a great Drizzle to ZeroSync schema translator Wes, essentially, you write your schema in Drizzle like typical.

That way, you can take advantage of the migrations, all the Drizzle stuff whenever you wanna use the Drizzle stuff. And then you essentially just take those schemas directly, pipe it into this function, and it gets your zero sync schema automatically configured. So that way, it's not like you have to maintain two schemas.

You have your your your Postgres DB JS super easy to set up, whatever, run the migrations. And then on the other side, you get zero sync to do all that stuff. I also have my own, like, auth system and stuff like that, which I'm working on. But, you know, I think for the most part, I I think it's a really great platform, and I I've really enjoyed building on it. In fact, I just added some new features to my habit tracker, that's built with Deno sync. And it was just a joy, right, to be able to update the schema, via migrations with Drizzle and then just have that those changes be available to you on the front end. You're you're calling essentially what feels like an ORM on the front end, but you're getting that local data saving. You're getting that sync in the back end. So hey. If if that sounds like something that fits the type of project you're building, like, that's the one thing you didn't really mention, is that, like Yeah. What do you think? It? Yeah. Like, micro apps. Can can you take a stab at explaining what a micro app would be and multiple micro apps? I would imagine just, like, even, like, one page utilities or something like that. I honestly have zero clue what what micro apps mean in this context. Nothing against you, Brad. I just don't know. Yeah.

Some sort of, like, suite of tools that are used for I don't know. We like, for example, in in syntax, in the editing Node. Right? We have so many little tools that we've built for helping us push the podcast out, and I I would consider those micro apps. So the kinda nice thing about building micro apps is you could possibly try many things out, and then and then if they're small enough, you can port them over. They're micro. Right? You can try a whole bunch of different stacks, and especially if you're gonna go this approach of what Scott said JS use Drizzle for the ORM.

And then that way, ducking out of zero or or whatever, if if you decide it's not for you, it's a very easy thing to do.

Yeah. I think of this like fuel. So we we have a site fuel, fffuel.co.

Wes. Yeah. Yeah. Which is like a full of a bunch of different utilities, command palette, color generators, lines, and, all kind like, noise generators and all kinds of cool stuff. I I think of this when I think about micro apps. But if if we're wrong about that, Brett, let us know because that that's kind of what I envision. Sharing utilities across multiple apps. Right? Like, you're like, oh, I need this thing again. I need to convert to SVG

in six of these apps, so I'm gonna share the utility across all of them. Word.

Chaff g p t says many people on Twitter, Reddit, and YouTube are a Sanity that you don't need stat queries in the chest. A damnit. Is that how you say it? It's adamant. But, I'm happy Really? I'm happy that I'm not the only one, goofing up today. I I think my whole life is a lie. I always thought it's a damn name because it's like, well, I'm damn near sure that it's this way.

Yes. Oh my god. I love it. Actually, I I prefer that. I I I'd Oh, how am I Damn near sure.

I'm damn near sure. Yeah. That's a damned. Adamant adamant sounds. Yeah. That makes a lot of sense. I love it. About it. Man, there's so many parts of my life that Node one has ever corrected

me. Oh my god. You Node, speaking of Wes, you know how I don't know if you know holidays, but we all know I don't know any holidays. This is just a a part of our brains. Right? I I I sat down with my wife the other night, and she quizzed me on every single holiday. And it was just hilarious. She Wes like, what month is this holiday in? And I was just like, what is the day what is Thanksgiving? What is and it's like all the I only got two of them right. I got Christmas and Halloween right. I'm I didn't get any of the other like, I could, you know, I could obviously I know what me there.

Oh, it was brutal. And and I think every single one, she was just in tears because she couldn't believe I I didn't know what day Easter was or what day

anything Wes. Even Thanksgiving, I think. I don't I don't think I could tell you when Easter is. Like, I know it's in April.

Sometimes. I don't know Node. I think sometimes it's in March. Also, in Canada, half of our holidays are named after, like, the queen.

So Wes have, like, Victoria Day and things like that. And I I could tell you what Canada Day is. That's about it. And I can tell you what the July 4 is because Yeah. We're the fans. Cinco de Mayo. She she said one of them, and I and I was like, that might as well be Boxing Day for me. I have zero concept of of what day that holiday is. Oh, Boxing Day. I know what boxing Boxing Day is the day after Christmas.

And if Bloxie Day JS, like, Canada's block party. Day.

And we we would like, the morning of after Christmas, we we would just go wait outside the stores at, like, 5AM. Mhmm. It's just a crazy thing to do the day after Christmas. Crazy. Yeah. And you get all the deals, but now we have Boxing Day as well. Anyways, he's a damnant that you don't need 10 stack query with Next. Js.

I don't understand how you can manage caching, revalidation, and optimistic UI without it.

So my question JS, how does one manage a sync state without transact query in Next. Js? I'm talking about instant updates to the UI followed by fresh data from the server without affecting the router cache. That's really important. Because currently, when you you call revalidate path, which is the Next. Js API for invalidating a cache on a page. So if you in Next. Js, if you've got some, like, server actions, you have some data Node, and you want to anyone that's on that page, you you wanna, like, reload part of that page. Right? You just call revalidate path and pass it to string to what path you're on, and it will just refresh all of the the queries and data that is on that path. So it's just Wes you call revalidate path, the entire router cache is JS true. Like, you're you're literally nuking the entire page and and starting again. The docs say a future version of Next will stop this behavior. The entire router cache is purged when you call router dot refresh from the client to pull fresh data on or out. Am I missing something, or is there really no way to make granular updates on the server that are synced with the client? Yes. You are missing that. Next. Js has a API that is coming. It's it's been in dev for a while, and I bet it will see it soon.

It's the unstable cache API that looks a lot like TanStack Query in Next. Js because, in my opinion, 10 stack query is is the best API in the world, and we need that everywhere else. So the way that this works is you tag your queries and you you tag any action with you can tag them with paths as well as a a time out, meaning that this data will be stale after however many time ever many milliseconds, and then you can refresh it. But then you can also tag them, which is much more important to me because I much rather tag, something as, like, like, podcast episodes or shop items versus having to revalidate paths. I don't know what page my items are going to be on. I'm big on component based design. I like when components can fetch their own data. React suspense makes that really nice.

But if if you're telling me you I have to pass you a list of pages to revalidate, I don't know. I don't possibly know which pages those are gonna be on, so I don't like that API. But the tagging them is really nice because you can tag it as, like, item six, but then you can also just tag it as an item. And in that case, you can invalidate all items or a specific item by its tag number. So that API is coming you can you can use it already in Next. Js. I've used it in production several times already, and I'm a big fan of that. As well as Next. Js is also rolling out this idea of just caching, not just like fetching resources, but Next. Js is also rolling out the idea of just caching a component's output.

So rather than, like, generating an entire page, you can statically generate a component or you can cache a component's output multiple times. So for example, I have, like, a Twitter feed in my footer of my website or the syntax one. I I might wanna cache that for, like, five hours worth of tweets or or a full day's worth of of podcasts and then, have that thing revalidate. So that's so that's a nice way to, cache stuff that is maybe shared between users.

And then finally, React 19, all the React suspense, all the server component stuff also has ways to do optimistic UI. Not to say you shouldn't use Stan's Stack Query. I I'm a big fan of it, but I think that that's why people are are saying that.

Yeah. Word. Sick. Thank you for that, Wes. Alright. Next one here from Famous Potatoes.

When starting a project, I often wonder if I really need to use a server in my code Bos. I think it's much easier to build a SPA, but there are some things you cannot do client Node, at least securely.

And Node a server like email, some databases, or libraries that are only built for servers.

But now that workers, Cloudflare workers, are more prevalent, do you think it's reasonable to build a client side app that does not use a server but pushes all of the server side stuff to a worker? The benefit being that you could build a SPA that benefits from simplicity in the code Bos and the ability to host a static site, but still has the ability to do traditional server side stuff using a cloud based worker.

Can you think of use cases where this would fall apart? Yes. I do this all the time. And, you know, one of the reasons why I do this all the time is because SvelteKit makes it easy to have, adapters for where you output. You throw the CloudFlare adapter in there, you post it up, and then you got your workers running as, you know, essentially functions for you, for any server side stuff you need. In that way, when you're using, like, .server.ts or whatever as a route, that that works on the server where it needs to, and then everything else can be Scott if you warp it to. You could even have server side running that way too. But I a lot of times, I'm I'm building apps that have, like, dynamic bits in them that don't need server side running for the app piece. Server side functioning, sending email, all that stuff works great.

I've been doing it also too now with AWS and SST, so that's really, pretty nice to be able to throw up on SST. You use, again, the same thing like an adapter for it. And then, AWS just runs those as Lambdas instead of, having to have a traditional server.

So I would say nine times out of 10, like, this is exactly how I'm deploying things these days. What Scott explained is the approach I would take as well, and that's not a totally separate

instance. I I think, like, the famous potatoes who asked this question is asking is, like, should I just, like, totally deploy my spa app somewhere? And then if I need to, I can I can fire up some workers and and sort of communicate between the two? That's a great way to approach it, but I would use something like SvelteKit or Next. Js or Tansac Scott or Solid start or something that is just puts it all into Node, meaning that you can do your whole app client Node, but at that moment where you do need a little sip of server, you know, you do need to do something server Node, it's so incredibly easy to do that on the server because you simply just like like in Scott, you just name it .server.js, and all of a sudden, that will will be running on the server. Or you can throw it, like, a server action in there, and that code will run on the server because that RestAPI back and forth of of hopping between them can be a bit of a pain, unless you have a much more mature application where you have a very clear API and a very clear front end, and you you sort of talk back and forth between those, that's pretty common. But if you're building from something from scratch and that you're doing it all in JavaScript, I would certainly pick something that allows you to do both. And you don't have use the server side stuff in unless until you actually need it. And in my opinion, that's the the best approach. Because so many times, I've I've whipped up a quick little, like, VDAP only client side, and then I I hit, I need a sip of server side. It needs something to run on the server. Yeah. Now I'm I'm opening up a new tab in my console. You know, I'm getting Deno fired up in that. I'm like, I should've I should've used something that I just have it all in one. Word. Totally. Yes. Max Wes c says, you've discussed implementing zero with Svelte, and Scott has even created the zero Svelte package. How would you load data in SvelteKit, though? Would you use plus page dot JS or stick with loading data in components and go directly and page dot Svelte files? Yes. Good question. How would you do this, Scott?

I I, yeah, I I pretty much skipped the loaders entirely. The way that it works JS, like especially because the the way that that, this Svelte Deno package works is that it uses it uses Svelte stores to do everything in runes. So it makes more sense to just toss it into a component.

I have some I recently published an AI chatbot, that's done with Xero and Svelte as a part of the challenge that the Xero team issued, which was actually a lot of fun because the way that it worked, Wes, was that, like, when I send a message and I type in, it it's doing the Xero sync stuff, but then it's also firing off a message to the server. The server goes off and does all the AI stuff.

And as the response is coming back from OpenAI, it's streaming into the database, and Xero is watching the database. And anytime the database updates, it's updating the UI. So the streaming is working by the AI response to streaming into the database, and the XeroSync is just recognizing those changes and updating the UI and patching the UI. So it's Sanity fast.

Basically, you're just tossing it in. And if it needs to respond to parameters, like page parameters or something or even, like, other inputs, you just throw it into a derived.

And, yeah, I'll have more docs on this, but I'll link that repo up that has a lot of good examples on how to do this. So, it's actually been really, really cool to see how many people are utilizing this. Zero's felt like like, they issued this challenge for anybody to build this AI chatbot and who who could do it. And just to see, like, people using my library to to do all that with, it's been it's been pretty great. Because I I use it myself for all kinds of stuff. So I, you know, I I feel the pain when there is pain, or I I I know where to fix when things are breaking or whatever. But Yeah. To have so many other people using it is is pretty dope.

So that's interesting to me that you said, like, you're doing all of the data stuff, like, in the component. Right? You're not doing it in a page at a page level or in a page Node. Is that right? Correct. Yeah. That's my, like, preferred way to do things as well. And the reason why a lot of people say, like, don't fetch in the component, but fetch at a page level, is because you can get waterfalls. Meaning that, like, you load a component that fetches data, comes back, renders out some UI. Oh, that UI now renders a different component, realizes that component needs some data, goes off, fetch it. Right? You that's how you get a waterfall.

But with local first, you're not so much worried about the network waterfall. You're not worried about the network waterfall really at all. Right? No. Totally. Why you can do that. Yeah. And and also the, the zero Svelte package, it saves every query that you do

into a a or, like, a map.

So if if I do a query once and it it hashes, like, what the the query actually JS. So, if I do that query once with one set of parameters, it saves it into a map, and then it doesn't have to redo that subscription or anything like that. That that will just ESLint, so it's gonna keep reusing that same that same data source every single time. So and and not to mention, the data loading is incredibly fast anyway. So it's it's pretty shocking. Yeah. Beautiful. I like it.

Yeah. Next question from Ronnie.

Do you think nowadays it makes makes sense to diversify to full stack developer instead of being only front end focus and learn something like PHP, Laravel, Python, Flask, or Java. No. It says Flash.

I know it says Probably Flash. Flask, but don't learn Flash.

Yeah. I think it meant to say Flask.

And then Java Sprint framework, but I don't know if that's supposed to be it might have been auto spring gap. Probably. So some autocorrect issues. But, Ronnie, I do think that it's probably important to spend some time learning these things.

I do also personally feel like front end development is a deep enough well that you should, like, be able to become a Deno expert in some front end development topics in a way that, like, you just can't if you're spending all your time focusing on on full stack stuff. So me, personally, I like the challenge of full stack stuff. The thing I like the most about it is that I can build full things myself without anybody else, but I'm not a a part of a small like, a a team where I'm doing one specific thing. And I do feel like with the the advancements to CSS, the advancements to JavaScript, all that kind of UI code stuff, I think front end focus is still very much a thing or, at very least, UI focus. Like, I'm building UIs with with this or that more so than just, like, just straight up client side code. I mean, whether or not you're doing it server side or, you know, HTML stuff. This is there's so much. There's a deep well here. So I personally would pick up, full stack stuff for fun to understand the process more, to know how these things work better.

But in the same regard, if you're looking to become a an expert at one topic, then by all means, I think front end is a deep enough well for that. Yeah. That's that's interesting. It's a UI

focused developer.

That's a great way to put it because as much as people want to be like, I only do the CSS.

Yes. That's that's not really a reality unless you are extremely good at CSS and you work at, like, a very large company where you're absolutely killing it. Right? Like, you work at Stripe and, like, you're just focusing in on on CSS. Even then, I think some of the the smart people that work out on the next level stuff at Stripe are probably also very good at JavaScript. So Yeah.

I would say it makes sense to at least be comfortable with the full stack, especially if you're trying to get a job today. As much as we would love to just sit in our little box and say, I just wanna focus on this thing because this is what I love, I don't think that those are where most of the jobs are. Most of the jobs are gonna want you to be able to jump in and work on whatever needs to be worked on. And you can be part of a a team where someone will say, give that to Scott or give that to Wes because they're going to do the best job at that. They really know the internals of x, y, and z. But when something breaks, you gotta be able to jump in and and figure this type of stuff out. And as AI is getting better for you to be able to explain how things work and be able to reason about different code bases, I really think being a full stack dev with a focus on one of these areas is is the way forward, and I don't know that you would get a very good and a well paying job otherwise.

Yeah. Word. Crispy Node. What do you think is a better way to track back end changes besides WebSockets? I have a scenario where I upload a video that is supposed to undergo some processing stages.

So I need to keep track of whether the video is pending, completed, or failed since I can upload multiple files. I tried pulling mechanisms, but it makes frequent API calls, which is costly.

I really need some help or advice. Thank you. So what he's explaining here is that you upload a video, and on the server, you you need to wait for it needs to process it. Right? It needs to maybe make captions, and the status of that, job needs to constantly be sent back to the client side. And there's several ways you can do this. Right? You can open up a WebSocket when you upload it and just send back data as it's needed. You can use Vercel sent events, where you ask for a request, you open up like a fetch request, and then that stays open for however long, and then the server can just sort of send data back to you as it's needed. Or you can do polling, which is just like, what's the update? What's the update? Mhmm. What's the update? And in most cases, for this type of work, you're going to be using polling.

That's what I see most often, because if you need to open multiple tabs or if you close the tab and reopen it, it's much easier to simply just ask for the status of job 299 and get it back and update the UI.

He's saying it's expensive here, which it shouldn't be expensive because you're simply doing some sort of, like, database query and then sending back a very small amount of text back. If you're doing bazillions of them, maybe, but it shouldn't be very expensive. And he's probably using something where you pay based on the, like, the serverless function that has been instantiated.

And every single time you run one of those, you have to pay for it. Node if that's the case, maybe look at how you can, I don't know, make that make that a bit cheaper? I don't think that there's any other way around this, and there are bazillions of apps out there that simply just use this simple polling technique.

Yeah. I know. Polling always feels like the easiest for me for some reason. Even if it's not, for some reason, it just feels like the easiest. It it is. It's because it's it's, like, stateless. Right? Yeah. Totally. It's simply just what's the status, and it comes back with the status. And you can recreate that at at any time.

So unless you actually need real time or, like, streaming or, like, something is like like, an AI response is simply streaming back the updates in real time, and you need to show that to the user. But if it's simply every ten seconds, you're checking if it's done or not. You can also do things like you can decrease the polling in the first like, if if you think, oh, it's gonna take at least five minutes.

Maybe the first minute or two, you only send a request once. Or if somebody has their tab not focused Mhmm. Then then don't send the request every two seconds. Mhmm. You know? Or if they if they haven't moved their mouse, there's a lot of things you can do to how frequently you should send that request. So maybe that's an avenue you should go down JS how do I how do I do this Wes? Or simply just put a refresh button on there for the user. You know? Let the user click on and see if they if they literally care. You can click on the button and see if there's an update.

Yeah. Yeah. Word. There's been a lot of talk about the zero sync stuff in this, but that would work really well for something like this because, again, you're just making changes to the database and it's listening on a WebSocket that sync process runs or whatever. Mhmm. And that that uses WebSocket. So I have a lot of experience using WebSockets from meteor days and now this. And, as a technology, when it works and it's all just set up and whatever, it just feels great to have that Yeah. Real timeness about everything. It's just something I like.

Next one here from Anan. This question is for Wes. Alright, Wes. You ready? Right. You have so many course sites with different domains.

Why don't you use subdomains for each course? Is this a security purpose or another reason?

I've had this question many, many times, especially in the early days of doing courses. People everybody was doing it at, like, a forwardslash. So it'd be like Yeah.

JavaScript instead of instead of on its own domain name. And my whole philosophy in life is make it a thing.

Meaning that if you put your hard effort into making something, package it up and ship it out as a thing. Make it a thing. Give it a title. You know? Give it make make some graphics for it, both because the the perceived value of it is is much higher. There can be, like, SEO aspects to it. That's never been a play for me with my courses, but a lot of people will do separate domain names because they'll put a lot of specific content on that domain.

Also, people like to sell their things.

I did it myself. Keycode.info was a little side project that I had, and it's simply you press a code a a key, and it will tell you the key code, the location. It'll say everything about the JavaScript event of a key up event.

And I put that on a separate domain name rather than forward slash key code on westboss.com simply because I wanted it to be its own thing. And a nice benefit of that is Toptal, this is a couple Yarn ago, came along, and they bought the whole thing from me. I sold them a website that shows you data on event on a JavaScript event, which is a bit of a silly thing, but they did it. Right? And and it was it was a significant amount of money that I made from it. So I'm a big fan of putting everything on its own domain name simply just from the perceived value and the ability to move things around should you want to.

There's no security issue. In fact, the security is a pain in the butt because, I have a couple things where I wanna share data between domain names.

Off is not cross domain name, but there's several other things cross domain name whether I show a banner or not.

If you've bought the course, they don't show the banner. That's a pain in the butt to try to cross domain share that info. Man, I I have experience with this because of level up tutorials. I did kind of the opposite approach where every single one was part of a bigger thing. Right? Yeah. So instead of each course being its own thing, I did each one as part of LevelUp Tutorials.

And I gotta say, you know, I feel like that was a harder approach because it kind of devalued every single thing I did, Wes, like, I have a new 24 video course coming out every single month. Why did I do that? There's so so much material, and it all had, like, less intention or weight, given to it. When in reality, it's like I was putting in the work on those those projects. I was really, like, hustling on them and and, like, grinding on it. But, like, yeah, probably would have been better to make them a thing instead and, like, make them bigger because I I think it was doing my content a disservice.

Not not, like, even, like, financial reasons, but I think it was doing my content to make make it more feel, like, disposable or more YouTube y by releasing so much all under under one thing. But, hey, it's out there, and it's free now. Vercel up.video if you wanna check that out. It's all for free now.

Next one from Object Object.

Could you guys talk about the pros and cons of a code based routing versus file based routing? Currently experimenting with Next. Js to ten seconds start and looking for some direction. Thanks. So yeah.

The idea with with the code Bos or config based routing versus file based is, when you wanna create a new page in a file based routing, you simply just you make a folder called, like, about, and then inside of that, you might have, like, an index dot TSX or you might have a page dot JS or whatever the whatever framework you're using. That's a file based writing. And then there are also ways to do things like optional params, like, if you wanna do, forward slash blog, but then you also wanna do forward slash blog forward slash one. Right? And you Mhmm. You wanna optionally put in the page number into the params.

A config one would simply have you write out the config for your router and and declare what all the routes are.

Let's say Wes somebody hits one of these, render out this component.

Whereas a file based one is simply just putting folders. And I've gone back and forth between them. I don't love file based routing, but it's all I've used in the last probably three years.

Yeah. Same.

And I don't love it because I find it hard to navigate through all of my pages. There's there's ways in in Versus Code to rename the tabs and whatnot, but I don't know that I've I have a a favorite of these.

Mhmm. What what are your thoughts? That's Yeah. My approach here is I'm I'm not sure what I like the best.

Yeah. In in my mind, it all comes down to, like, with, like, programic based routing, it makes it way easier to do, like, conditional routing things, because you have the full power of JavaScript or that front end framework in your router.

Where with file system based routers, I feel like they all struggle when it comes to alright. I have, like, this group of routes that has a different, like, subgroup now. I have this parameter based route that needs to adhere to these, guidelines. Like, for instance, the SvelteKit routing system is very good, but it's it's kind of its own thing. You can, like you have, like, Wes routes. You have routes where the parameter is locked to a specific regex. You have, like, grouped routes. You have nested layouts in all these ways. And, if you want to have a nested layout route system that's a part of a different tree or whatever, it it just makes it all more complex than it would if you were doing it in a in a in a code based routing system. But on the other hand, you gain things like code splitting, and that stuff is way easier and less effortful if you're not having to do it yourself and to tell Yeah. Your application where to split and what to load, when to load dynamically, whatever.

The framework just takes care of it for you. So for me, at the end of the day, I prefer the file based routing for the benefits you get automatically for it rather than, having to deal with that stuff myself.

And then I will learn the syntax for

file based routing. I'll learn all that stuff. I will deal with it even if it's not my favorite thing. Middlewares is is another kind of pain in the butt one where it like, I want middlewares to apply to these three routes, and they're not, like, forward slash admin whatever, then you gotta do it. But, also, like, the Syntax website, like, our Open Graph images are sort of outside of the the Syntax layout.

And in order for us to do that, we need to have, like, a parenthesis blank and a parenthesis site sort of route inside of there.

But I think that's fine because I don't know. Like, once you understand it, it's a little bit weird. But once you understand what it's doing, I think it's totally fine. I I didn't even think about the the code splitting route. Another one is you visit a page in a new code Bos.

I wanna fix something that's on this page. It's very easy to figure out where to edit that code Mhmm. Because you simply just go to the page, the file based route for that page, and then you start clicking through the components until you find what you're looking for. Whereas, like, how many times have you opened up a code base before? We're like, I have no idea Yeah. Where to even look for this thing. That's why I, like I I still have it, like, a fairly big express app for my course platform, and I moved almost all of my routes into Node file at one point. And that was so nice because now I was able to just open up the routes file, and it's hundreds of lines long, but it's very easy to see what the routes are. And then I can click through to the controllers of each of them, and actually see the code that runs when people visit those URLs.

Last one here from Eddie.

I'm new to web development, only going into my second year of learning web dev. Do you guys have any advice for new developers that are new in this field? New developers that are new in this field. Absolutely, Eddie. This I feel like this is something we haven't even touched on in a while. It is a question we've gotten a number of times through potlucks, but, you know, we've been on we've been on the air in the airwaves since 2017.

So definitely wanna hit this one again. You know? What do we recommend for people who are new to this stuff? I I think the biggest and best advice that I can give you, Eddie, is that your curiosity is your superpower. It's your superpower towards being focused. It's your superpower towards gaining knowledge. It's your superpower towards building things that you will actually use, enjoy, and, like, advance your learning. So let your curiosity drive you, Dive into things. Explore topics. Get deep on some things. Get wide on other things. But, like, for the most part, find stuff that you enjoy making. Try to make it. Struggle through it. Don't give up. Ask Wes, all of those things.

And, you know, be open minded.

I think a a struggle that oh, maybe not a struggle, but, like, a a problem that a lot of newer developers have is they might listen to some influencer on YouTube or something and then build their entire, not just personality, but their entire developer skill based based on what somebody else has said is the way to do it. There are so many different paths that are all valid and all work. And if you like something and something feels nice to you and you're productive with it and, so and so influencer says that it's garbage, don't you don't need to listen to them. You know? I think keeping a very open mind, staying curious, and, you know, working hard to build things for both yourself, for other people, nailing the job requirements, whatever Yeah.

Is the way to go.

Yeah. Having that open mind is is absolutely key. So my advice here is build lots of things. Build lots of little things.

Having that success after success will give you crazy momentum in your career. Share what you've built. Share what you've learned. Those things, simply just putting it up on GitHub, writing a blog post, making a a video about what you built is unbelievable.

I've had major, major leaps and bounds in my career simply by showing what people what I have built. And that's led to conference talks and paid freelancing jobs and job offers and stuff all over the place. Right? And the last thing is, like, join the conversation and and, like, ask lots of questions. So if you are part of this community, right, you're listening to this podcast, you're finding web developers wherever it is that you like to hang out, that is going to be big for your career.

Word. Absolutely. Yes. Yeah. We should do another. We many years ago, we did one, like, advice for new developers, but let's we'll follow that up as well, especially as, like, the the job market has changed pnpm Everything has changed. Right? Last time we did that, AAI, LLMs weren't a thing. I mean, there was just so much that's changed. So I do think,

my advice will significantly have changed there in many different ways. So well, that's it. Let's get into our next section, which is sick picks, shameless plugs, the stuff that we think is great and that, you might be maybe should be paying attention to. Wes, I have a sick pick that I sick picked before in the past.

But, hey. Alright. It's a repick, but I I'm coming at this from a whole another year of experience. So maybe about a year ish ago, I sick picked a financial, like, tracking app if you've ever used Mint or something like that or Personal Capital.

There's so many of these now, like Copilot money, blah blah blah. I've been using Monarch for over a year now. And at first, when I I started using it, there was a lot of, like, wow. This is really great. It all works super well. It looks nice. It feels nice. I can tell I'm going to like this.

But now I've been using it for over a year. It's, like, really part of my general workflow where I'm approving transactions. I'm categorizing them. I'm using, like, the Sanity flowcharts for where my money is going and how how much of percentages is going to all of the different things. I'm using all of the budgeting tools, the goals, all of these, things, and I I use it every single day. So I can safely say, from my perspective, I've used a lot of these things.

This has been my favorite one by far.

The biggest complaint you will see people have with Monarch is that accounts disconnect.

But, like, I feel like web developers should know better that the way that works is that many of these are unofficial APIs.

And, like, for instance, our our mortgage lender is, like, the worst, like, nineteen nineties website.

And the fact that Monarch works at all with that mortgage provider is shocking to me. So, like, if it disconnects every once in a while, no big deal. Yeah.

So behind all of these financial apps are is a company called Plaid, and they provide APIs for all of these banks. And, like, I I think it's the wild west. There's probably developers working at Plaid that are just like, well, today, I wrote a SOAP API thing that will go around, or I'm sure they have some crazy processes to to get that data out of your bank. I have it with my FreshBooks. It constantly constantly disconnects and it's such a pain in the butt. And they all they do is point the finger at Plaid, which makes me really mad.

Yeah. But at the end of the day, you gotta know that, like, some of them they don't have real APIs. They're and there's so many institutions APIs for a lot of these banks. On their own stuff. Yeah. There's millions of have four banks in Canada.

What do you got down there? Like, bazillion? I don't even know. I mean yeah. I mean, we're in a credit union that I've been at for a long time. So on top of that, you have, like alright. Now I'm at a credit union with its own software and who knows what. So Yeah. Yeah.

Either way, I I like this a lot. The reports Yarn really great. It feels nice to, like, go through this, you know, monthly with my wife and, look at where we're at at the budgets and see all the stuff. And, yeah, it it's fun, and it it's a good UI. So Yeah. Check it out. Beautiful. I'm gonna take pick

these, like, Pelican cases, or whatever they're called. This one's called a SKB case, and these things are awesome. I have a couple of bigger ones. I have one on wheels.

I'm up up up at my cottage right Node. And when I go to the cottage, I bring all of my recording gear. Not all of it. I have I have doubles of everything, but I bring the expensive camera. I bring my laptop.

My wife brings her her camera and her laptop and stuff like that. And I'm always scared that things are gonna get busted or if you have to bring something on a plane. So these cases, besides looking like super badass, like, they have, like, nice foam inside of them that you can, like, cut out to match whatever it is that you're working on. They're, like, pressure sealed.

If you ever need to get a nice Pelican case or what's the name for these that is, like, not the, like, trade name? Pelican case is the name of it, but many companies make these. I have no clue. I don't case. Yeah. Rugged yeah. Some kind of rugged, waterproof case.

Are they waterproof? Yeah. Oh, yeah. Certainly. They, don't buy one that isn't because that that's very important. I'm sure Yeah. Someday my kids are gonna take this out of the car because it's in their way and leave it in the snow or something like that. You know? It's not at any time. So big fan of these. Alright. That's all we got for today.

Shameless plugs. Let's check out the Syntax YouTube channel. We just posted a banger of a video with,

the folks behind the TypeScript rewrite to Go. That was a lot of fun. Today's the day we release it, so we're kinda all hopped up on that release. Yeah. So check it out. Yeah. Also, you know, it's so funny. Somebody commented about the skateboard that was in the background of CJ's set. If you don't know about it, we have a store of all this kind of stuff. So if you head to century.shop, s e n t r y, Shop, we'll have the link in the show. We have so much cool stuff there. And there's, like, Century swag, obviously, but we have Syntax skateboard. We have miniature skateboards. We have all kinds of sick pick T shirts and and hats, and we got some cool new stuff coming that, like,

Wes has had access to for way too long that I have not had access to. I'm a I'm a I'm the official tester for the merch, so you probably have seen it in a couple videos, but they're coming.

Yeah. There's a lot of cool stuff coming, so check it out at century.shop as well. But, yeah, that's all I got. That's it. Thanks for tuning in. Peace.