001 — Default to Stacktion

Hey. How's it going? This is Ryan Hefner, and this is the All Play podcast. So in this episode, I wanted to talk about kinda where I'm at as far as, like, a potential crossroads that I'm kinda, running into right now. So I don't know.

In the intro, I mentioned that I'm trying to kick start some projects right now. And over the last 3 years or so, or actually even longer, I've been predominantly working within, like, the Next JS React space. But prior to that, most of the apps that I was building were utilizing Laravel. And, I mean, I think the Laravel ecosystem is amazing. There are so many advantages to using it.

There's so many, like, I don't know. The it's really endless. I mean, the various supports for different payment providers. So, like, whether you wanna use Stripe or Lemon Squeezy or Paddle, and having that just be basically a configuration that could be made in your app. Obviously, a few other, like, little integration pieces, but for the most part, pretty much done for you.

Authentication and the story there, all the additional tools when it comes to just having, like, a general admin or being able to track, queues and, I'm trying to remember the name of the recent dashboard thing that they just came out with. But, I mean, it's endless. And, actually, they're just they're also coming off Lyricel Reverb, which handles, you know, the whole story around WebSockets and IO and and just making sure you have, like, these, like, live interactive apps. And, you know, that's where I wanna take I think the majority of the stuff I wanna work on actually has that kind of requirements in it. So so, yeah, that's, obviously, all the pros for going with Laravel.

My the only downside is and that's not even I can't say a downside, but the counterpoint to that is the fact that I have been working in Next and React and the pros that I feel, like, exist there from, you know, just composability, I mean, also simplicity, the DX around, you know, deploying to either like Vercel or render, Netlify, and having these previews and being able to kind of spin those up and and review them before you merge them in and deploy to production. And the whole cycle there is just so nice. The and granted in the past, the the way that I was building, Laravel projects was primarily, you know, Laravel was being used for the auth and the API, and then I would have some blade pages that would basically spin up a React app, and and from there, it was basically an SPA. But, you know, I'd I there's I don't know why I have I have these, like, reservations on it now. I think, for one, I just think there's better ways of doing that.

I think the story around having your whole front end be really optimized for delivering this stuff with the server side rendering. And, obviously, there's, React server components and stuff up, but at the same time, I'm not there yet. I'm I'm actually mostly using the page router, via Next. Still, I just feel like there's too many quirks with, the app router stuff. It just slowing me down too much right now, so I'm just gonna go with what I know.

But, yeah, you know, it's it's it's this thing, and and I don't wanna be this, like, analysis paralysis of not getting something done just because I'm hemming and hawing about, you know, tech stuff. Now granted, there's reasons why I'm hemming and hawing is because I have some apps that I've written that are based in Laravel that are kind of a bear to go back to right now. I mean, when I started them, I was on a Intel based Mac, And so I had everything in virtual boxes and I thought I was, you know, having, like, a really clean local dev environment. But then once the, you know, once the Apple chips came out and I I migrated to, you know, those systems, Now I can't use VirtualBox. Now all those local m's and those databases tucked away within within those environments are are, like, inaccessible.

I have to, like, go spin up some old laptop that is, you know, it's there's a reason why I stopped using it to you know? It's slow. It's it's you know, the hard drives are all filled up on it. It's just, it's it's just another mental barrier to have to get through to get to, you know, making progress. And then, obviously, there's the whole upgrade story where I could definitely just pay Laravel Shift to just do those updates, and I probably just should, especially for the ones that I wanna keep alive and want to keep working on.

But, there definitely is a story there where, you know, I think the one thing that kinda makes these, I guess you could call maybe Nexus more of a meta framework over React and, you know, add some additional stuff. But the amount of stuff that it, like, actually blows into your project as far as anything is actually I mean, I guess it's like the the pro and con of of the JavaScript world. It's like it's not really much there. Like, updating to next is, like, relatively straightforward. They might change something or as far as, like, get server side props or maybe the the config gets some updates or some things get deprecated, but updating that stuff is actually relatively easy.

And, you know, thankfully, they're probably doing the hard work of of of hiding a lot of those complex changes from us. But at the same time, the it's not like it's blowing in, like, you know, a 100 files that then you know, like, I mean, some of my Laravel projects are still on PHP 7. And, I mean, p the whole PHP world has changed so much to literally, everything every single file that's in one of those in those projects probably has to be updated with all the type and, class based stuff. I mean, to be honest, I don't even really know because I haven't really worked in Laravel for a really long time other than just, dipping it dipping a toe in and and vetting whether or not it's something I want to, like, recommit to. So that's kinda where I'm at.

And, you know, I could I I could be sitting here and debating this choice or or where where I wanna go, but I think what I'm gonna do is I'm actually just gonna make action my decider. So I am spinning up a project that's actually it's gonna be all just JavaScript. It's, I'm gonna be using NX to manage the monorepo because I just really love. I've been using that for over, like, the last 3 years or so and the ease of, you know, adding on additional apps as well as building out libraries and having those potentially shared between multiple apps and having everything in a single repo, but yet not necessarily like a single monolith. I just really love that the, you know, managing packet, like, library updates is super straightforward.

Everything gets updated all at once. Your own libraries instantly get shared and are the latest, between the projects that are using and the apps that are using them. And so I really like NX. I'm probably gonna continue to use Next and obviously react for the actual, like, front end clients. At the at this point, the way that I'm kind of thinking about scaffolding out these these projects is really just like one one app for the site, which would mostly be just static.

You know, for the most part, just a static site popped out. Maybe there'll be some light off library or something shared between those just to be able to reflect login status or whatnot, but for the most part, pretty light. There'll be an app, app running, which would be the, you know, the actual, like, admin dashboard, whatever you wanna call it, for the app, and then the API. And this is where I I, you know, I think is another kind of diversion, but, obviously, Next has support for API routes. I there's a I have a just a hesitation on actually using those for, like, a production API.

And I think if your app is it doesn't expose that if if you're if the thing that you're building doesn't that to the world, I think that's a totally great way to go, especially if you're allotting out third party stuff, and you don't have any other things like background jobs and, you know, long running processes and all this other stuff. But I just think there's, like, too too much limitation with that. So the the direction I'm actually gonna go is I'm gonna actually use Nest for the API framework. One things some of the things I like about nest is the fact that it's really just there is no assumption that there's, like, any sort of views, being rendered via it's it's really API first, so I really like that. I think the ecosystem around it seems to be pretty robust.

It supports all the stuff that I would need to do. So we're gonna see where that goes. And I'm gonna I'll get into the project that I'm starting on, but I just wanted to lay out some of my thoughts around stacks and where I'm kinda at and what I'm thinking about. And, yeah. So I'll be, you know, posting up some more updates as far as what I'm working on and how things are going with the different things that I'm choosing.

I'll also get into more detail as far as some of the other sub things that I'll be, picking, or choosing to use within within this initial project just to kind of vet this setup and see how it feels, see how fast I can work in it. But, gonna leave it there. So once again, this I'm Ryan Hefner. This is the All Play podcast. You can follow me on Twitter at Ryan Hefner, and you can follow the show at all play f m, and you can also find the show at all play dot f m.

So, alright, see you next time. Have a great one. Later.