Picking a Fullstack Stack, Is Next.js Too Complex? Services vs Self-Hosted + More

Welcome to Syntax today. We got a Pollock episode for you today. We're gonna be talking about, Node. Js back end choice. What if you wanna build a quick Wes API, what you use in Node. Whole bunch of questions around, like, full stack. Like, what stack should I pull together in order to build, like, a SaaS app or a CMS that I wanna do your own? We talk a bit about when to use a service versus when to host it yourself. That free tier will will come and and bite you in the butt once they pull the rug from you. Scott is wrong about 10 stack forms. He doesn't understand what they're for. No. And simple stacks. Someone's saying, like, was express in view in MySQL the perfect stack? Should we go back to that? Is Next. Js too complicated? Well, we're getting all into that, so let's get it going. I feel like this is the Stack a Node, Wes. Yes. It's a stack nothing but stacks. Full stack flapjack.

Full stack flapjack. Let's go. You ready, Scott? How you doing today?

Hey. I'm doing good, man. Just chant chilling, hanging out. Being back on my Mac feels weird. I'm just been turning into a Linux boy. So, you've been all over the Omar

using Linux AppGet installing things.

No. I have not used AppGet. There's something called Pacman. I've been Pacmaning. I've been, chomp chomping, waku waku, all that stuff. How how are you doing?

I'm doing good. We're recording on a Thursday today, which is a little odd, but I'm heading out next week, so we're getting ahead of it. Cranking out Node for you. And and, like, honestly, we do a potluck once a month, and there's a lot of questions today. I couldn't believe it. Like, it's we often come back to the the potluck, and, like, we could maybe do two of these a month sometimes. There's just so many good questions. So please keep the questions coming. Go to syntax.fm.

And in the URL bar in the in the menu, there's a button that says potluck queues.

You can, you can fill that out, and we'll answer your question up on a, an upcoming episode.

So you would say URL

or Earl? Earl. Which one? No. Yeah. I just say URL. I just,

somebody says warp. As well. No. I'm just saying, you gotta make a choice. Somebody says, URL or URL. What are you picking?

No. It's URL. But the one that you have to say it. I yeah. Oh, URL or URL? I don't know. They're both stupid. No. I'm not. I don't I don't stoop that one. You know what I do say? I say href.

You do? You say href? Yeah. Href. Href.

That's it's not right. I know. But I've been saying it my whole life, and I'm not I'm not about to change. But let's get into the first question from Finnish George. What is your preferred choice for a Node. Js back end? I mean, something newer than Express.

And how much would you say there is an it depends factor? I mean, when it's basically just a CRUD API. So, basically, you're just you're spinning up a Node server. You have a CRUD API that's taking in a get request, post request.

There's there's bodies that come in, maybe JSON. Maybe you need to handle streaming, you know, just your your standard Wes API that you need to be able to build out with Node. Js. And my reach for that is usually either, like, Deno or h three.

And the reason why I'm I'm saying those things is that both of those frameworks follow the standard web request and web response.

In fact, like, almost everything these days follows the standard web Wes and web response, signature, meaning that any handlers any API handlers that come in, you will be able to move those from like like, if you're in Hano, you need to move it to, like let's say, you you want the functionality existing, like, a Next. Js request or or maybe you're using, like, a Svelte server function.

That code will be almost entirely movable, meaning that the, the URL access to the URL, access to the body, access to the parameters, the query params, all of that stuff will be will look exactly the same way. And then the response that you send from that handler, also, those are are standard across the board. There is some, like, helpers for, like, sending JSON and sending text, but that is different than, like, Express Wes. Because Express, there was no standard, for doing this type of thing, so they just made it up. And now, luckily, other, like, connect other people, pick that that sort of standard up, but the new standard is web request, web response.

Yeah. Yeah. I would also have probably picked Node. I I in the past, I've used Fastify, fastify.dev and really, really liked it. Those there, Eliza.

I used Eliza

JS well. One as well.

But to me, is probably just what I'd pick today. That said, I'm I'm usually working in a more of a meta framework, so I'm not having to pick up,

one of these that often. But, yeah, I Yeah. I think that would probably be it. You know? That's the other alternative as well is, like, maybe don't even spin up a a Node back end. Like, the only reason why I don't use Hano more than that is that I'm often using, like, a full stack meta framework that also does my front end and handles all that for me. Yeah. And if you want something that is,

like, really lightweight and you're, you know, you're just looking for something super easy to spin up, Polka is a interesting option as well. This is actually what SvelteKit uses underneath the hood. It's a, 90 lines of code.

So, yeah, it's pretty minimal here.

That's that's that's really nice. Oh, because you can you can specify things like route handlers with, like, like, IDs and whatnot in them Yeah. Similar to how you would you would specify, like, catch all routes or or variable routes, param routes in Express.

Yeah. That's pretty cool. Yeah. It's it's it's a good good thing. I still have the Express app, and I've been slowly, like, writing, like, a conversion layer, anytime I add anything new because eventually I'm trying to move myself off of anything express specific and move to just standards based stuff so that I'll be able to one day just move move entirely over.

Yeah. Eventually. Right? Next question from Halindra.

Hey, Wes, Scott, and CJ. Shout out to CJ.

So after moving my database from Postgres over to Convex, where you would have explicitly chose the index for each query, I realized my indexing was kind of a Wes, causing a lot of full table scans. Do you actively manage your database indexes to prevent that, or is it something you usually only fix when it's a problem? Yeah. So for me, indexing really has always come down to what are the queries that I'm making, what do I plan on querying off of, and, like, what needs to exist. And from there, it's usually something I take care of when I initially write the schema. I tend to think very deeply about what am I actually querying for and off of what parameters. So, for people who may not know too much about indexes, oh, man, I wish I knew technically. I'm I'm I'm sure you might know a little bit more technically what exactly indexes are doing. But from a nontechnical perspective, what they're doing is when when you set up an index, the database becomes optimized to, look up over certain parameters in in or certain columns in a table. So, combinations of columns, individual columns. Yeah.

Like, if you have, like, a a user column somewhere and that user column has, like, a email address, first name, last name, and and, like, like, social handles. Right? You gotta ask yourself, like, will I be querying this? Like, obviously, you have a primary key, and and that's you're gonna be able to pull up that really quickly. But, if you are trying to, like, query somebody based on, like, say, their email address, if you don't have the email column indexed in your database, what happens is that your database literally loops through your entire every single item in your your database and will be looking for that specific one.

And when you specify a field as an index, it will often scan your database and keep keep those things in memory or or somewhere so that it can quickly look that up. So you just have to ask Vercel, like, I always look up users by email address. Right? Whereas, like, sometimes I'm looking up people by some weird combination of it, and the the query will be a lot slower, but that's okay. And and often, what I'll do is if you don't know it ahead of time, it's gonna show up in in your stats that you're having very slow database reads. And in fact, we had one in the Syntax website where I forget which column it was, but we were not in the I think it was shows, and we have a show number. And we were often looking up shows by show number, but the show number was not indexed.

And as the day the database grew, the the queries got slower and slower. Every single time we added a show, the queries got slower, slower, slower, to a point where, we got a Sanity alert that said, hey. Slow query detected.

And then we went in there and realized, oh, Scott of index. Boom.

Solved immediately.

Yeah. You know? So part of it, again, is paying attention. That that's really what it is. But another thing is if you want to use a tool to do this, Sentry has slow queries. They have a slow query tool.

And then just to be clear, we work for Century. So this is me, plugging Century.

Centuryofcentury.io, it's a perfect place to find your, missing indexes or even for better yet, track your slow queries because there is an entire slow query, feature within Sanity that allows you. And and, honestly, we I think that's how we found our slow query,

with our shows, our missing index. Yeah. That's exactly how it it it emailed us.

Yeah. The email. Right? It it was actually funny to watch the the query over time as it got got slower and slower.

Yeah. That's actually the best part is when you make a fix, and then you get to see the bars go down in terms of, like, yeah, how long it took with latency or whatever. So Yeah. Check it out. Century.io. Use the coupon code Sanity treat, all lowercase, all one word, and you get two months for free.

Man, really, really nice tool. But, yes, that that is mostly it. Another cool thing you can do nowadays in 2025 is you can ask AI to do it for you. Scott, like, to trust it blindly, but you can pass in your whole ass website and say, hey. Am I missing any indexes here? And it it might say, you should consider adding an index for this. I've had really good luck with that because then it's not even, like, writing the code for you. It's just looking at everything and being like, hey. I noticed you're querying off of this, but you're not indexing for it. So maybe consider that or change your query. Rip through your code Bos.

Find all the queries and say, hey. You're you're searching based on these fields fairly often. It's worth adding an x. I have have and, also, you have to ask yourself, like, do I even need this? Like, I have some some queries in, like, an admin tool that I use three or four times a year Yes. For some reporting, and I don't put indexes on that. Those those queries are slow as hell. You know? But it doesn't matter because I only use it three or four times a year. It's not worth the extra cost to To say.

To add that. What is what is the extra cost? The the extra cost is that, like, your your database grows. So, like, you could obviously, you could just index everything, in your database, and it would all be fast. But then the storing of those indexes becomes becomes very large, and you you need more memory or you need a a large database to be able to handle that. So if you got lots of money, you could. Make the whole plan out of the black box. Right? Yes. Exactly. Another question. A couple weeks ago, we did a episode on, like, creating a new project, like, initializing a project. What do you even do? Planning. How do you do that? So we had a Wes, which is following up on that Node. When you're done your initial plan, so you figured out kinda what you wanna build and how you wanna tackle it, what does your actual workflow look like when it gets time to actually write in the code? Do you update your package JSON with everything you know you're gonna be using? Do you start with front end components? Do you start with routes, database structure? Do you tend to scaffold out the whole project first or work on one section front to back and then add the extra pieces along the way? Also, how do you order the work? Is it core functionality first and or do you get things like auth, translation, etcetera, set up first? So that's a really interesting Wes. Pnpm think it breaks down to, like, what type of application it is. So I thought, like, let's break it down, me and you, Scott. Let's talk about two different kind of kind of apps and how we would tackle them. So probably one of them is just like like a CRUD app. Right? You've got a Node. Js back end. You got a, like, a React or Svelte or Vue front end. You have a database. You have authentication.

What's your plan of attack for something like that?

Oh, man. I the the reason why I'm gonna have a hard time answering this question, Wes, is specifically because I the only structure I have in planning things is that that planning process changes every single time. So it depends on how I'm feeling that day. So let's let's break it down. Okay. I tend to take something, especially like a CRUD app. A CRUD app, I'm almost always thinking about data first.

Always thinking about what data I need to have, what the structure of that data is, and then doing my very best to accommodate for the entire app at once. Things change. Projects evolve.

But nowadays, I am taking out and thinking about that entire data structure first, building out that schema.

And then even as far as, like, planning the UI and front end of all these things go, I will build out the route structure in files before writing any of that code if your framework allows for that, creating the files, creating the routes, things go where they're supposed to go.

And then you start at the root and work your way to the leaves in terms of UI stuff and then changing and evolving as you go. And I like to build a lot of things my dang self for some stupid reason. So, inevitably, I'll be writing a form and being like, this should be abstracted. Okay. You know? And just kind of do that as I go. So, starting at the root and then, routing out. So that that's pretty much it. And now more recently, I'm worrying about the UI in Node of Paint at the end because it's easy to change HTML.

And if I don't write any classes on anything, I don't have to, worry about that. And, another thing is is the way I work is with scoped CSS via Svelte components. So, like, man, I can just write CSS targeting specific elements and not have to worry about even, like, modifying classes or changing it or whatever.

So for me, that that's kind of the way I go. An interactive component, three d color those types of things, man, a lot of that stuff I just YOLO. I'm just writing everything all at once. I'm just dumping here and there. Going for it. Yeah.

The database like, I I always talk about, like, bringing a database into this world is like caring for a a pet or a child Wes, like, now you got responsibilities where if I don't have a database, you know, whatever. I I can go off and just, goof around. But with the database, I'm like, let me actually think about this. Yeah. So when I have a plan for, like, a, like, a full stack CRUD app, what I'll do is I'll first install

everything that I need.

So that includes all my back end packages, everything that I think I need. Right? You're not gonna know exactly what you need, but you need your, like, your server framework, your front end framework, all of that, your database.

Then I'll go into database, usually.

Sometimes, I'll try to, like, skirt it, especially if I'm trying to go, like, as fast as possible.

I'll try to, like, I don't know, just store it in a file and whatnot. But, unfortunately, I sometimes I often regret that because then I have to go back and shoehorn it in. So, database, often off if I feel like I need it. And and the reason behind that is because when I'm making features, if you don't have the concept of auth or or or users in your application yet, then it's it's kind of a pain in the butt. Right? It's much easier to get that stuff set up ahead of time. Mhmm. Then once you're, like, sort of foundations is down, then I'll just go simply feature by feature.

I'm not gonna scaffold all all of my routes. I'm not gonna scaffold out any UI components or anything like that. I'm simply just gonna Sanity, I'm working on this feature right now where a user can create, list, and, like, read, update, and and delete all of of those pieces. You know? And then okay. That that those are all on the thing. Now let's go on to the next feature. And then I'll I'll I'll sort of get two or three features out, and you can spend a little bit more time on what the actual UI works. But I do go like, the whole like, the blending of back end logic, server logic, and, like, front end logic JS it's it's just one thing to me these days. You know? Like, when I'm building a feature, I don't necessarily think, like, let's make a whole app API Wes API first, and then I'll go into it. I was like, no. I'm building all of that exactly at the same time, especially with, like, RPC.

Yeah. I feel that for sure.

Mhmm. Also, translation, that is thankfully something I don't have to I haven't done in many years. Like, multilingual, such a pain in the butt. You certainly will wanna have that ahead of time.

Yeah. Because that sucks.

Yeah. That sucks. That's hard to do. Yeah. Next question for mister Rai. I've been working as a front end developer for the past six years with a year of back end.

I mostly do React and Next. JS, and for back Deno, Node, Express, and Postgres.

Currently, I am not sure what to do. I mean, working full time, but not as excited before.

Oh, sorry. Man, I'm reading.

I am working full time, but not as excited before.

I feel like the growth You still miss it up. I am working full time, but not I'm not as excited as before.

Okay. Yeah. Sorry about that, folks. I feel like the growth for me has been stagnant.

What do you think I should do to have the same energy as I have years back? Man, I'm just reading. Okay. In short, I need some guidance for the career path goal. Mister Rai is working, and he's just not as excited before. How about that? Yeah. You know, I think I I we I think we've all hit this, especially when you have long running projects. Those projects, like, can get to a point where, like, yeah, you got stuff to do, but is that stuff interesting or exciting, or is it same thing you've done a 100 times before? Or is it just like it's not calling to you? The cool thing here, mister Rai, is that your ability as a developer opens you up to be able to experience all kinds of different problems, all kinds of different UIs or back end challenges or any of that stuff. And I know that a lot of this is your day to day job stuff, and that that can feel tough.

But maybe there's something else that can be exciting while you do your day to day job stuff. Maybe you can get your day to day job stuff done early so that way you can work on problems that are more interesting. Take on dangerous hobbies.

Take on danger. Can you can, what was that where people were, seeing where they could iron in different locations? Like, they were, tightrope walking and ironing or playing chess.

That Wes, like, some of these things. You could bring your computer while tight rope walking. No. I think, really, what you need to do is is find a way to tap into some bit of tech that is calling you, and that can bring you more interested into the the big, development picture overall. Maybe there's something that exists in your day to day job that could help the org, can help your day to day job without it necessarily being on your task list and something that you can spend some time really diving into. I I really think that is the whole thing is that novelty at the end of the day is always going to be more exciting. And if you can find some way to inject novelty into your work, that is going to go a long ways for improving your motivation.

We talked, in a couple episodes ago about just how motivating Hack Week was and all those things, And we got a comment on the video from somebody saying, oh, we our company instituted a Hack Week, but then soon after, the managers declared that all the projects have to be something that would push the the core product forward. And it's just like, y'all missing the point.

Missing the point.

Like, yes. That's great. And people might find those things, but to enforce that JS gonna squash all the novelty.

It's gonna remove all the creativity from it. Yeah. And, ultimately, it's removing the entire purpose. So you gotta find some way to inject

novelty into your day to day job. Yeah. You gotta have fun. And we get this question quite a bit. And part of the answer is Wes. Like, work on more stuff, but something that is different, something that is exciting. But, also, like, I I agree with that as well. You have to always be having side projects and new stuff and and be dipping into things like that creative flexing that creative muscle is super important to fending off that burnout, where you're you're just like, I'm so so sick of working on this stupid thing Mhmm. Every day in and day out. But, also, like, I think there's probably other environmental stuff. Like, if I haven't worked out in a couple days, I just I just don't feel as excited about the work that I'm doing. And then once I get back in the gym, I'm like, that's that's it. You know? It wasn't that I was using the wrong AI for this thing. It was that I Node to lift weights.

So perhaps there are some Node developer things in your life that are are worth, addressing as well.

How can you have non developer things in your life? What does that entail? Like That's

I it's Yeah. Yeah. No. I I agree. It's it's true, though. Like, I like, my life is very much very much about coding. Like, almost everything I do is is about coding. Right? And Yeah. It's it's hard. It's hard because that's all I wanna do. You know? But then the burnout man comes comes calling, and you're you're gonna get bit.

Yeah. I know.

Loving husband says, hey, guys. My wife needs a website in order to create and publish content for a personal hobby of hers she turns hopes to turn into a nonprofit.

The site will mainly be a blog with educational content, but she doesn't want any of the social features like comments or likes, etcetera.

There will also be a page to donate and eventually, yeah, years down the road, a merchandise store. As a mid level developer, I'm interested in building this for her to grow and level up my skill set, so that I can become a senior engineer. I would love your thoughts on which tech stack. Minh, so many questions about tech stacks today, which would be good. I'm primarily a JavaScript developer looking at future JavaScript jobs. I'm interested in building this in Redwood SDK since Peter came on the podcast, but maybe it is too new. I have some experience in WordPress, but I want to choose a path that will help me grow and make me the most viable candidate for future job opportunities. Thanks for your help. Yeah. This is kind of interesting one because you need to think about, like, your wife and her hobby of, like, you have to build something that is good so that they actually use it, because, certainly, I've built lots of, like, CMSs or I've built lots of apps over the years. But then, like, Node. We're just talking about this with with home assistant, as Wes, where, like, Scott and I are trying to get our home assistants to the wife factor, like, close enough that the family will actually use it, and it's not like a pain in the butt. Right? So you need something that's good on them that half, but then you also wanna, like like like, further your own skill set and and and learn a whole bunch of new stuff, and that's a really good portfolio project as well. So I think think you should break it down into building it on something that is a little bit more stable because, like like, I agree, Redwood is awesome, but it's it's certainly very early. So I probably would not bet the farm on that just yet. And and start asking yourself, like, what do I need? Do I need a CMS? It sounds like you need a CMS for this type of thing. Right? And then maybe look into into something like payload.

Sanity is a paid option, but also a really good option. You could use WordPress and just use the, like, the JSON API and and suck that on up.

But I don't know. Like, what I I always tell people don't build your own CMS because it's that's a that's a hard thing. Right? Yeah. There's a lot of people that need to build their own CMS. Yeah. I built my own CMS, like, 18. Hard. And then just think about, like like, integrations versus building from scratch. Like, ecommerce store, I wouldn't worry about that right now. You Node, when that comes time, you gotta look at it and be like, okay. Am I selling, like, three things and I'm not worried about inventory? Then, yeah, you probably you probably put that together with integrate with Stripe and whatever, and that'll be a fun project. But if it's like you need inventory management and shipping and, emails, something is out of stock when they need to restock, then you're probably looking at, like, a a Shopify or something similar to that. So that's a whole lot of nonhancers of, like, what stack would you pick. Yeah.

I would probably pick a full stack modern JavaScript.

So whether that is 10 stack start, maybe look at some of the new Remix stuff that's coming out next month, Next. Js's, contested option in in that case or go, like like, full stack Nuxt, and Vue. That's probably that's pretty in demand as well. You'd certainly wanna pick something that is fairly established and in high demand. And and and right now, that is that is a a full stack JavaScript.

And then go from there and and figure out what integrations

are are you gonna need. Yes. I'm gonna go ahead and say tech choice does not matter at all in my opinions, whether it's, mature, not mature, whatever. Tech stack, whatever you pick does not matter. What matters is that you make it work and that you make it work well and that you make it easy.

I have done this so many times and, like, have handed something off that, like, works, and then people go to use it, like, because it's a side project. It's just for, like, casual whatever.

And then, oh, here's a bug here and there. Here's a bug here and there. Here's a bug here and there. Next thing you know, you got a whole ass job in front of you. Like, you're you're now tracking edge cases. You're doing this or that. Just make sure you understand exactly all of the functionality that is needed out of the gate. You think about it deeply, and you make it good. I think that's the only thing that matters. Yeah. Beautiful.

Next question from RGV Cycling.

How do you deal with a toxic work culture whose source is your boss? Oh, man. So it depends.

Because where is this boss in the chain of things? Is this boss the Bos, like the boss, or is this boss your boss? Because a toxic boss is a problem.

But a toxic boss is not just a problem to you.

It's a problem for that whole organization.

It's a problem for that company.

If a boss is, being toxic for whatever reasons in terms of, like, not being, like, giving the team the support it needs to complete its tasks and goals, whether that JS, like, being unprofessional, having potential HR issues, you know, those types of thing. That is a different situation. I will tell you this. I have been in two situations with a major toxic work culture because of a Bos, one of each, one of which the boss was the cofounder of the company, and I was a direct report.

That one, you can't do anything about it. You know what I did? I quit. I said, I quit. I've told this story a whole bunch because it's one of the reasons we started Syntax.

They were messaging me on a Sunday at 10:00, the week my first child was Yarn, because of a broken feature in pre alpha software.

I quit on Monday, and I did not have a job lined up. I just had a kid, and I quit because you can't just live with that. Now I'm not recommending everybody just go and quit if you have a, unfixable toxic boss. You probably wanna see if you can line something up, but that will ruin your mental health. It was ruining my mental health, and Wes decision I ever made to quit that job.

Number number two scenario where I've had a toxic boss was a project manager.

I was a part of a team at Ford, and I was working on some experimental interfaces for Ford as, like, a part of this crack team of, like, 30 people.

And we had a boss, and this guy was a nice enough dude, but he was doing a lot of weird stuff, like saying inappropriate things, getting really aggressive at some of the other PMs and stuff like that. He was my direct boss. And at one point, he he he stepped over the line several times.

And he had never stepped over the line to me personally, so I didn't feel like it was my place to step out. And, like, it was toxic, but, like, I was fine completing my tasks.

But he stepped over the line with one or two other folks. Those folks went right to HR. And guess what? He got shit canned, like, day of, out the door. And guess what? We were all fine. It was great. And in fact, it was a huge, huge boost. So, like, if you have, like, very real, like, professional concerns about this person, like, professional concerns about this person, HR is there for a reason. You can talk to them. You don't have to, like, go snitching on minor little things here and there. But if somebody has crossed a clear, gross boundary in some sort of way, talk to HR about it. If this person is at all receptive, talk to them about it. Now only do that if only do that if you you know that, you'd be comfortable with that.

You'd be, like, okay with getting fired potentially for going to them and expressing your concerns about a toxic work culture that they've, created. So, like, maybe you know, I I think, ultimately, if you're looking for a low friction, if it's a professional HR thing, go to HR. If it is something that maybe even, like I I would say going to their boss is something you could possibly do, but, like, you have to be very gentle in how you do that, and you have to be prepared for potentially getting let go or creating more problems.

That's a lot of answers, Scott. But, honestly, I think this this can be dealt with a lot easier JS you you get get as big as you can to assert your dominance. Yes. Arm wrestle. Just beat him in arm wrestle. Assert dominance.

That's done. You know what? Talking about asserting dominance, my kids have decided that they really wanna do thumb wars all the time. And Thumb wars would work as well. Imagine like like, there's no man that loses that thumb war that is not just, like, broken inside.

Dude, I I will tell you what.

I destroy my children at Thumb Rule. They're like they're I don't even let them for one second. Gotta assert that dominance.

Oh, man. Alright. We got another question about Stacks, for building a SaaS project. I wanna help a friend build a SaaS product. We want to dish out an MVP and aim not for so many users at the start, of course. So you're aiming aiming low. That's good. I like that. Yeah. I can't get hung up on hosting, rolling my own out, etcetera. I want to pick a quick and easy solution that would not break the bank, so have a generous free or next cheap paid tier.

What I need is server database hosting, planning on one full stack framework like the TANstack. Okay. So he needs he needs a a database. He needs somewhere to to serve it up. Right? He needs image storage, email sending, and then authentication.

What are some nice providers for each? For hosting, so far, I've used fly.io.

For auth, I've used Clerk, but I have never hosted any images anywhere. Could Cloudflare meet all of my needs? The thing that I don't want to do is go with AWS, and doing that is too much work. Do you have a suggestion for this kind of stack? The goal is to not pay much monthly, but have a functional app that scales. We can start dipping into the bank if we get more users. Yeah. This is the the never ending trap of the free tier. And I have had the rug pulled out from under me so many times that I know that you go, ah, whatever. If we get more users, we'll start paying for it or whatever. But, man, I have some super high bills of stuff where I'm just like, I don't feel like switching this over. I'm just gonna pay the man and and move along. So certainly be very wary of generous free tier because those generous free tiers are often funded by venture capitalists, and those venture capitalists want their money back. At one point, we had one on we had one on the show, and he wants his money back eventually, plus some. So, it's not it's not a, a Node thing that they're doing. So it's always hard. Right? Like like, do you just go and enroll together a million services and then just just YOLO it. And then before you know it, you're like, remember we had that, like, no code guy on, and you said he sent $700 a month on services just clipping them all together.

Yeah.

You can can't find me doing that. I'll be honest. Yeah. Honestly, I'm a I'm a CloudFlare stand. I think that that is probably a good CloudFlare does not send email.

You would have to hook up, but whatever you choose for sending email, choose something that supports, like, an SMTP gateway. Meaning that, like, don't use something that JS, like, you use their SDK Yeah. To send email, and you're, like, totally locked into them. Use something that simply uses SMTP, meaning that you can you can sign up for well, I don't know. What are the ones? I use Postmark, but everyone hates them now because they got bought. And looky looky, the VC's favorite, cousin, private equity, is they just service goes down, price goes up.

What what are the other ones that that people use?

For

email? For SendGrid, Mailgun, SES is he doesn't wanna use Amazon. So, yeah, he can't use that. So yeah. Resend is one that people are using nowadays.

Resend is the one that It does more, though. Yes. Yeah. It does a lot more, but then you're you're locked in to, Yeah. Yeah. Yeah. To their system.

Yeah. I I'm pretty much always using something like SendGrid or or Yeah. Paper Image storage.

Oh my god. The one I've always used. Post something? Post Postmark?

Yes. That's what I'm I've been that's what I've been using for many, many years.

Yeah. I used to use Mandrel until Mandrel got

Yeah. They they took it away.

Image storage certainly use Cloudflare's image storage. It is extremely cheap. The pricing, yeah, the pricing is great on that. They don't charge for bandwidth, but they do charge for transforming them into multiple sizes and for storing those images on their server. So, like, doing the math on these things is is always hard because it's it's it's really easy just to look at, like, $20 a month for this service. But if you're trying to, like, look at raw infrastructure, you have to start doing these weird calculations of how it does. Fly.io, awesome. I think I would probably stick with that. Right? You can you can throw you could go, like, an external database host as well, but, you can you can throw it all all on there as well. Authentication, yeah, this is I I probably what do you think? Better auth, Scott? I I always 100%. Hesitant to use, like, a SaaS that is auth.

Don't ever use a SaaS that's auth. I, like, don't understand that whatsoever. Yes. There are unless you need, like, high end concerns like, what is that, a single sign on? Sign on or Yeah.

Yes. Better auth is is, like, so insanely powerful.

It does everything you need to do.

It doesn't lock you in. Like, I can't imagine paying a service to do auth. And then now you Scott a, now you got another database that's hosted on some other company that's storing just your auth and stuff like that. No. No. Thanks. So keep it all in one spot for me, or at least under my my controller purview. I know you mentioned the images thing. The the CloudFlare images, transform images API JS really good.

So I've been using that lately. That's been something that's been nice for me JS the, CloudFlare images, with their their capabilities there. For database, Supabase is a great host for Postgres. It's a great way to get set up easily with Postgres. PlanetScale does Postgres now.

So you can do either of those two options. Those are types of services that I do off load. We've had we have PlanetScale for the ESLint, and I like PlanetScale. So, I would I would probably use something like that for each of those. Again, we said mail. Again, better auth for me is the choice for auth. Other images

is like, Cloudinary is good, but it it also suffers from that, like, drug dealer free plan. You know? Definitely. Yeah. Very generous, but it it goes to a $100 a month once you go over that. And that's especially if you hit this place where you're like, oh, yeah. We have an app, and I wanna keep it running, and it's not bringing in a ton of money, but, you know, like, you're kinda just maintaining it and and people use it. Those, like, monthly costs can can get out of hand really quickly. You could be $6,700 between all of these services before you before you realize it. Danny Manny says Mhmm. Is REST first GraphQL still a relevant question? Are there any advantages for going for a GraphQL API over a REST API? So this is this is a great question. GraphQL, super popular for for many, many years. Everybody thought it was was the REST killer. And in probably the last three or so years, it's sort of fallen out of love, and I think there's kinda two reasons for that. So GraphQL seems to be still very popular in the corporate world where people are combining multiple data sources, multiple services all into one. So we had, shoot. What was his name? He worked for a a, like, a big BBC or something like that, big TV vendor, and they have 30 different teams, and they need to have a single API for sending data, performing mutations, and and querying all of that data. And a GraphQL layer, that's this is exact exactly where or sort of Gatsby went, with with their whole GraphQL thing as Wes. As a single layer that sits on top of, I don't know, your forty year old COBOL API and your six different Wes APIs and your internal Salesforce weird thing just as a nice single layer.

GraphQL also is is great if you want to have a single API for, like, an iOS app, Android app, web app, TV, you know, all of that stuff. However, it is for most people, it's not that GraphQL JS bad, but most people, I think, found that this is too much overhead.

And you found yourself doing way too much work on the server, GraphQL schema, in your database, and then on your client. There's just way too much stuff, whereas a REST API was fine for a lot of people. Right? Mhmm. So I I would say, oh, go for a REST API, or I would say probably the third option and and the reason why GraphQL fell out out of love JS is RPC.

Yeah. Meaning that people aren't even building Wes APIs anymore. They're simply just using RPC, meaning that they can call server functions from the ESLint, and and you don't have to worry about API endpoints and accepting arguments and whatnot as you're you just define your server function on the server. You can call it from the ESLint. And, obviously, there's authentication and all of that stuff in the middle there that will make sure you're not doing stupid stuff. But that Wes the TypeScript just flows from the back end to the front end is is beautiful if you are building an app that is simply just back end Wes front end.

Yeah. I think the the what we saw with GraphQL was the the hype curve went up, and I I the hype curve went up. Right? And this was all the people being, wow. This is so cool. This solves so many problems I have. And then it gotten to the point where people are like, everyone's talking about this. Therefore, it must be right for me. And then they implement, and then they're like, wow. This is a lot of extra steps. Now I'm hitting n plus one issues. Now I'm, having to write way more code, than I was even with my my Wes API. Or someone like me, I came from an RPC setup before all of this. I mean, Meteor is essentially RPC in many ways. So, like, I went from RPC to GraphQL to Wes, now back to RPC. And I'm like, why did I ever make that jump at all? Right? So I think a lot of people like you said, they discovered it wasn't necessarily right for them. And in turn, what happens is there becomes this, like, pushback, like GraphQL sucks or something like that. When in reality, you just tried to shoehorn it in something that it wasn't made for. And so I think GraphQL, for the use cases you mentioned, are JS, like, great solution. There's a lot of great upsides to GraphQL.

There's a lot of, great reasons to use it in the right scenario. But if you are just, you know, building an app, you got control of the front end, back end, whatever, like, I don't see any reason to do that unless you really need, to build out this API layer that connects it all. So, yeah, that's my thoughts on it. I like GraphQL. Personally, I haven't used in a while because I haven't been building stuff, and I and I'm, like, Key, the type of person who hit the this isn't for me. This isn't for my needs. Right? I'm not building things that need this.

So, therefore, I'm gonna stop using it. But that doesn't mean it's it's bad or not not useful or anything like that. Yeah. Depends on on it it's a tool. Right? And it solves a lot of hard problems for people that have those problems.

But I think a lot of people realized there's a lot of typing for problems I don't have.

Lot of problem. Yes. Exactly. Alright. Next question from Bob, bob.com.

Bob, I think Express plus Vue plus MySQL plus AWS was the best stack I've used in production.

I've built large enterprise apps other stack question. Yeah. Yeah. Now in my job, I've adopted Next 15, payload three, Postgres, plus Vercel.

Although it's growing on me, I sort of hate the direction that Vercel is steering modern web development. Now that React is getting a compiler inspired by Vue inspired by Vue, bro. Vue Vue and how would you say inspired by Svelte, man? Come on. That was the original compiler. Yes. Inspire, but TSX is objectively uglier than Vue templates. Agreed.

And sorry, but Svelte has some ugly templating too. No. That bro, what are you talking about? It's handlebars. Alright. The Vercel stuff gets more complex, more black boxy, and LLMs often suck with newer technologies.

Your opinions.

Yeah. I mean, I agree on a lot of this stuff. I Scott say, it's not like I I don't wanna declare myself a hater, but, like, man, I never understood the Next. Js appeal, and I didn't understand the React appeal. And I don't necessarily still understand it because I was definitely a skeptic of React when it first was announced, and then I sucked it up and used it for ten years. And then I went and stopped using it and was like, what did I gain? What did I gain there? And and, personally, yeah, like, you can do everything that you can do with React easier and oftentimes with less trouble and better performance in other systems. That's just my thoughts, personally.

The Vercel business too, the thing that bugs me the most about Vercel is not like them as a company or or what their goals are. It's the people who act like hosting on Vercel is the only way you can have good developer experience and an easy time hosting anything on the web. I saw, like, a Reddit thread the other day, and, like, there were people being like, I use Vercel because it's the only one with good DevX. And then, there was a response to that being like, oh, there's a lot of other good options too. And they're like, I don't wanna host my own Linux box. Like, that's not the only other option. Like Yeah. Going straight w AWS or running like a Coolify or, like, hosting your own VPS, it's not the only other option than, like, Vercel. There's tons of other options. Wes that I think Cloudflare JS easy as hell to to host on. Railway is super easy to host on. Fly.io, really easy to host on. Even using, SST, less easy less easy and more into getting into the weeds there. But, like, yeah, there's a lot of options to host that are easy. TSX, man, I find I find TSX to be ugly too. I I I'm with you on that one. I I I could rant on this all day, but I'm not going to. So, yeah, how do how do your opinions? Bob, I agree with you on everything except for Svelte having, ugly templating syntax. I think Svelte has some ugly syntax sometimes, but I think the templating syntax is perfect and has never done anything wrong. So Yeah. I think you're wrong on only that piece, Bob.

I honestly think he's right in that, like, sometimes I do think about, like, the good old days of express back end, simple front end, you know, MySQL database.

That was a fantastic stack, and I believe that you probably like that because of the simplicity. You know? You you knew it really well. You can get stuff done. You you can hop into the app and find where it is you want. And there's not a lot of, like, there's not a lot of, like, gotchas in that. You know? Like, having to know Next. Js and like, I know Next and React very well, and I have a swath of weird gotcha knowledge. You know? And then the people, like like, I I love React, but the people that say, like, skill issue, it literally is a skill issue that you don't know these weird gotchas and how these weird things work. And that is fine to have that skill issue because it's not something you maybe should have to spend your brainpower on. I I agree with you there. Yeah. I'd rather have skill issues with the web platform itself Yeah. Than Yeah. Exactly. Than having to figure out how, like like, updates and affect dependencies and and stuff work like that. Right? So, yeah, I I agree with you. And I think, like, what you should do is there are in in every single category, there are very simple, easy to use options in there. You know? Deno, HONO, Vue, maybe even just go full stack Nuxt. You could still use MySQL. You could still use AWS. Still exists. Yeah. All of this type of stuff, you don't have to. And, like like, on the, like, next payload Postgres, like, these things aren't they're not making them complicated for complicated sake.

They're trying to do things where you can build a fast ass website and host it and scale it and and do all of these types of things.

But often, that means you have to do things in a very specific way, and that rubs a lot of people the wrong way because there's, like I said, there's a lot of weird knowledge that you you have to get. So, I don't I don't think that, like, Vercel is intentionally doing any of any of the stuff.

They obviously have a business, and they want it warp it to do well. But I I honestly do think Vercel cares about the future of the web. It's just that, like, Next. Js is, what, 10 old. Right? There's there's a lot of baggage that comes along with a very old framework, especially when you're trying to do things like have dual compilers or you're trying to have a Rust based Webpack alternative, but also still maintain the old one and still maintain, like like, your your pages API and and, like, there's all of this sort of, like, baggage that needs to be supported.

And then when there are new features that need to come to next, they have to consider all of that. How will this work with all of the baggage and how will this work with with everything, which is probably very frustrating to to have to do that.

Yeah. I I think my biggest rub is when, like, they choose to use their own in house, things like walled garden approach. Like, sometimes Vercel really takes the walled garden approach at the expense of the product, the experience, and everything, and that rubs me the wrong way because the development experience is so much better in the extra outside world.

The amount of times I've had, like, a Next. Js question and the answer is a Vercel answer and everyone just assumes that you're hosting it on Vercel, that is very frustrating because, like, those those things are separate. You know? They they shouldn't have to come hand in hand there.

Last question we have here from Sam. Says, have you seen the new TAN stack forms? Aren't they great? Fully typed via inference.

All inputs are totally controlled. So this is awesome. I actually did not see this. So first of all, there's also a TANstack DB, which is like a local first sync engine.

Very excited about that. And then TANstack form is a headless UI for building type safe forms, and I'm really excited about this because when you want to build forms on the web and and this is not just a React thing.

This is It is. Is Wes with with This JS, like, React. Everything. No. This is a React thing. When you wanna build forms, you you have to do a lot. You have to have, like, types, and you have to have validation. Sometimes you wanna bring Zod in to make sure that the data actually looks fine, and then, you often have server side validation, then you have messages that need to come back. And, like, it's very frustrating building forms, and I feel like I've spent my career building that this. So it's just forms. You know? You submit something, it sends data, and it comes back. You could display messages and and whatnot.

And this is just a a headless UI, which means that, like, you still you bring you still bring the HTML, but this brings a lot of the the functionality, and you you would wrap it. So you can still bring your ShadCN or whatever UI component library that you want.

But if you want the functionality of the there's validation, what happens when you have a submit handler, saving data to state, and then, like, fully typed all the way down, so that you can take the data out of the form and use it in other parts of your application is is really good. So I'm I'm glad that TanStack is is the team there is solving forms because I absolutely love the approach that they've taken on so many other things. And now now to see that they're they're tackling forms and form submissions and validation, it's hooked into standard schema, which we did an episode on, which means that it's not just Zod. You know? It's any validation library that adopts standard schema can be used.

Yeah.

I I will say, I think TanStack form I love TanStack stuff. I love, Tanner. I I I love what they're doing. I will say that this type of library is solving a problem that, like, only React has. Because when you get into binding form states to, like, simple state variables, you end up having such an easier time.

I think there's, like, two types of issues with forms. One is that people sometimes control their form when it doesn't need to be controlled, and then, therefore, like, you're allowed to have a normal form and then, like, use the data from form data or use the data from the form itself and Yeah. Control the form on submit if you don't need a controlled form. You're allowed to do that in any framework, and people just don't. People are gonna automatically wire up every single input to a state variable all the time when they don't need to. So I think that's one problem. But another problem is that complex form state becomes so much effortlessly easier when you have a binding state. You got binding Scott. You don't have to do on change events. You don't have the state is just there. It just updates. It's just available.

And then the stuff that this would come into handy for would be like the on change, async, debounce kind of stuff. Like, that's where the Sanity stack form stuff would actually help you out. But so many of these things if if you're bringing your inputs

I don't think you understand what this is. You're saying that this is just, like, a way to bind

state No. No. No. No. To inputs? No. No. Not necessarily. I'm saying that, like, forms in general JS, like, it being a React problem.

And the reason why you need an additional, like, library to do that in forms in React is because to get complex with it, you then start having to take control over everything everything.

Like, what what what exactly what problem is this solving whether I built the submission form on the Syntax website,

which can take in like, there's a drop down of different types of submissions, and then there's there's a data input. You can put your name. And, like, I had to build all of this stuff myself, in Svelte. Meaning that, like, when somebody submits the form, you go to the back end, you validate the data, you send that back, and then you have errors. You gotta figure out where the errors are attached to.

If you have fields that are linked together, password, confirm password, focus management, multi step, forms, all of that stuff is is something I've had to to rebuild. Like, the Svelte doesn't have any tools for working with forms built in other than you can submit it to to the client and, I guess, the the input binding.

What does this do that gives you better multi step forms than just using straight up state and input binding? This is not about state.

This is about validation.

This is about handling submission. This is about when somebody types into, like, a box or maybe have, like, a slider and you wanna check if that thing is available.

I think that this stuff is really handy. That's not just a date. No. No. Like, I I've built many forms in Svelte, and I think that this would be very helpful as well.

I don't get it. I'm gonna say that I don't get a single thing that this would help with that I cannot do with You can do anything you want. It's just that, like What I don't see JS, how is this making any of that easier is what I'm saying.

Okay. I I don't know. I think it's there's a lot of people who build very complex forms, and you want all of the validation built in there. And it's not just a simple HTML form that gets submitted, and then you come back with with any validation that used to happen. You often no. It's not just state.

Node. I built some complex ask forms, and I had no issue,

just doing Wes. Let's see your your complex ass form.

Oh, man. I'm working on one right now. Although, it is I will say it's on my Linux computer. I'm working on one right now for uploading video that then, brings back thumbnails. And then if you have thumbnails, you can Vercel the specific frame of the thumbnail. Otherwise, you can have a a code or an image input, which then changes all the inputs and, specifically, the the types of fields and everything like that. Not extremely complex. Not multi multi but, like, even multi step forms. Again, it's just a big old state object that is like, where what is the status of this form? What is the UI then being shown there? Validation, man. I mean, validation can happen in all kinds of easy ways. I mean, that's not like Yeah. That's not a challenge I have, I don't think. Yeah. Alright. I will say,

like, forms in React are are probably the worst. Right? Like, it makes no sense that you have to listen for a change handler. And when something changes, you have to then go update state in order. Like, that's such a broken, awful, awful way to to do it. Right? I hate doing forms in React, but I think that that this thing would be handy in in anyone because it works. They have examples with with Vue. They don't have Svelte examples, though, so maybe you're right there.

Yeah. Yeah. I I I just don't get it. I I I sincerely hold up that I could be wrong on this. I I definitely think that I could be wrong on this, but I've never personally written a form that was too complex that I couldn't do it with just Bantage State, personally. Yeah. That's that's yeah. Wes, I think this is the first major disagreement we've ever had on this show. No. No. I think I I You okay? I think it's a skill issue. Yes. Yes. No. I'm I'm totally fine.

But alright. Let's get into the last section, which is sick picks.

Sick picks. Hey. I I got a interesting podcast. You know, podcasts for me, I love finding new podcasts, new and interesting ones.

And one of the things that always bugs me JS, like, Wondery podcast. You Node? They're 800 ads for other shows and just, like, how they break up stories. Like, Wondery, good production, all that stuff. But, like, man, some of their their way that they do things bugs me. That said, I was willing to deal with it for this podcast, which I I found to be so fascinating. I had to send it to my wife for psychology reasons. But, this is called Flesh and Code, and it's really about, people falling in love with their AIs in, like, a AI, companionship, app. And, like, the just wild amount of, like, attachment people would have to this AI.

And, like, it's largely people who do not understand how AI works. So, like, the I feel like that's part of it because when they're interviewing this guy, he's like, I don't know. I don't get her personality just changed overnight.

You know? And, like, the his friends are just like, do you not know how any of this stuff works? Like, there's not a person here. There JS not a a there's not an entity here. And and the shocking amount of numbers, like, sheer numbers of people who are falling in love with AIs or, like like, treating them as a real person or getting emotionally invested in these things.

Man, this Wes, disturbing and eye opening podcast for me to listen to. I was like, holy cow. Yeah. We we are there, and it JS, dude, it's wild. Ugh.

Yeah.

It's it may it sounds awful, and it definitely will make you feel a little ugh. But as somebody who works in this space, I I think it's kind of important to understand this stuff, see what's, like, going on with some people because you Scott prepare some of your family members who might be susceptible to this kind of thing. You know? I don't have any personally, but, like, you know, people are getting older or whatever, and the AI is only gonna get crazier. So I I think chances are,

it's gonna become more of a topic of conversation. But, yeah, nasty stuff. I'm going to sick pick something that is not awful like that. Hold on. Let me grab it. I've talked about these in the past, but anyone who doesn't know about Wago connectors, they're they're good for, like like, household wiring, but also good for like, I use them at electronics projects as well.

Wago connectors are the Wes. And the Europeans are gonna be laughing at this because these have not become popular in North America until, I don't know, maybe maybe four or five years ago.

And what it is is you you have a wire in let me let me take one of these out here.

If you wanna, like, connect multiple wires together, you basically just open it up, you strip it, you throw it in, you you close it down. Right? It makes a lot of sense. But in in North America here, we use something called marettes or or wire nuts and just crank them down together. You know? And then if you do wanna take something out, you're twisting the copper. It's a pain in the butt. They're huge to fit, like, behind a light switch or something like that. So if you're doing any sort of yeah. They're they're so good. And I also I recently found these ones, which is they're called ESLint.

Yeah. Yeah. Yeah. Yes. I know about inline. These are awesome. So if you have, like, just two wires that you wanna connect in in in a line, these ones are fantastic rather than having to loop the wire back into the the bottom of the connector. So that and then I also have been printing these, these DIN connectors.

You can buy them that they they mount on this rail as well, but I I'm working on, like, a little low voltage project. I would I would not do this with

Yeah. I was gonna say, these these are exposed.

Yeah. Yes. Yeah. That's that's not allowed with with mains voltage. I'm working on what's called a class two circuit Okay. Which is it that's allowed.

But, yeah, you could just connect two wires together. And and especially, when you're prototyping things, you don't wanna have to solder them together. I used I used that for a lot of my, LED project as well. So big fan of them. Grab yourself some Hue connectors.

Do not you you can buy knockoffs, but I probably wouldn't. They're Yeah. They're cheap. They're, like, 50¢ a piece. I've had the knockoffs in the past, and they're fine for just like, I'd, like, put, like, a vacuum line together, low voltage stuff, but I would not ever ever trust them on anything that has any serious power. And then I would also be very careful where you buy them because I think there are a lot of counterfeits

counterfeits out there as well. Yeah. I I've been using these for any time. I I put a number of, like, smart switches in our our house, and I use those every time. They're just so nice. And they're nice when you're installing things because it all clips on very nicely. You don't have to worry about it pulling out. I do tend to really ESLint, make the light switch. Them in the back of the switch, like a little clip. Give me that. Sorry. Go ahead. Yeah. No. I said give me that. I I just replaced the light switch last week, and it, Wes felt very nice to use my WEGOs.

Beautiful. I've actually never used one behind a light switch. I probably should.

I've always just used my electronics project just and use a stupid wire nuts where you get to jam them behind the thing. It doesn't seem like a great idea. So Europe.

First time, you were right about everything. You got your cheese you're right about, and your pasteurized cheese.

I don't know anything about that. Now your Wes connectors. All the

the cheese in in Europe is much better.

That's so funny. Supermarket crap you get here. Yeah.

Cool. Alright. Thanks everybody so much for tuning in. Please submit your questions at syntax.fm.

We'll answer them in a future episode. We'll catch you later.