But really…can it? It absolutely can AND a lot more. In this new episode of JavaScript Jabber, the roundtable sits down with James Q Quick, a software developer, podcast host, and overall future-enthusiast. The team discusses what the “JAM” in JAMstack means for developers, how it’s making integrating features (like payment processing) a breeze, and what you NEED to know about JAMstack going into 2022.

“None of these individual tools are new, but JAMstack just became a new way to combine those things with static content and leverage those concepts.”
- James Quick

In This Episode

Why JAMstack is more than just individual pieces clumped together (and could be replacing how developers do business)
 How the “JAM” in JAMstack is allowing developers to pick and choose the services they want (without knowing all the nitty gritty details)
 James lays out how JAMstack makes payment processing a no-brainer (and it’s not just Twitter hype)
 New features and apps for JAMstack that you NEED to know in 2022
 Where JAMstack is shows its power and ease-of-use (and why you should have some “secret sauce” in your cabinet)

Sponsors

Links

Picks

Special Guest: James Quick.

Sponsored By:

CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel, we have Steve Edwards. 

STEVE_EDWARDS: Hello from a very clear and cold Portland area. 

CHARLES MAX_WOOD: AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. Coming at you live from sunny, beautiful, snowy, pleasant growth. 

CHARLES MAX_WOOD: I'm Charles Maxwood from Top End Devs. And this week we have a special guest and that's James Quick. James, do you want to say hi and remind people who you are? 

JAMES_QUICK: Yeah. What's going on? Thanks for having me. Tennessee weather, by the way, there's no like one piece of weather. It could be 30 degrees and 75 the next day. So I don't even know what to say for that. I'm also a developer, speaker, and teacher. I've done some combination of those activities professionally for about 10 years now, which is pretty cool. I was at All Zero as a developer advocate for a couple of years up until the last month and just transitioned working for PlanetScale as a staff developer advocate, which is a serverless database platform targeted at the Jamstack.

CHARLES MAX_WOOD: Nice. 

 

Hi, this is Charles Maxwood from Top End Devs. And lately I've been coaching some people on starting some podcasts and in some cases just taking their career to the next level. You know, whether you're beginner going to intermediate or immediate going to advanced, whether you're trying to get noticed in the community or go freelance, I've been helping these folks figure out how to get in front of people, how to build relationships and how to build their careers and max out and just go to the next level. So if you're interested in talking to and having me help you go to the next level, go to topendevs.com slash coaching. I will give you a one-hour free session where we can figure out what you're trying to do, where you're trying to go, and figure out what the next steps are. Then from there, we can figure out how to get you to the place you want to go. Once again, that's topendevs.com slash coaching. 

 

CHARLES MAX_WOOD: It's interesting too because- Thanks, Steve. Yes. It's interesting just to kind of talk about where things have come from the Jamstack, right? Because I mean, I remember when we first had Brian Douglas on talking about it way back, what, five, six, eight zillion years ago, when he was talking about, yeah, just the basics, you know, you have a front end, we have some kind of API that we're hitting, and then we have our markup. And it was like, okay, well, I had a few people say, well, how's that different from any other JavaScript app? But and I think the main idea is just that you're not managing your own back end, but it seems like it's gotten a lot more sophisticated than it was back then. Right. And I mean, we had an episode like six months ago with Brian Rinaldi and talked about JAMstack then. And it just, it seems like things are just moving forward much, much more quickly. I mean, you have Versil got funded and then funded again. And you've got all of these, I didn't, I hadn't even heard of the company you're at now until you mentioned them. And I had never thought of using Auth0 with Jamstack until somebody pointed out that, Hey, you know, that's not terribly hard. So yeah, I mean, where does this leave us? Is Jamstack just app development now? Or 

JAMES_QUICK: I think in a lot of ways it is, it's kind of interesting, like Jamstack really started with and people maybe not familiar with the term jam and Jamstack sense, but JavaScript APIs and markup. And the interesting thing about that is like none of those individual pieces are new. Right? Like we've been doing all using all three of those for years. But Jamstack really just became kind of a new way to build stuff. Like a new way to combine those things with a focus on static content. And different people have very different definitions of what static means. And my definition is just kind of a set of files that you could host in a CDN, a content delivery network, which means like front end frameworks, react, any other view, all those, they have a build process. And the output of that is static set of files that you can host on a CDN, which means those are, in my definition, considered static sites, but that doesn't mean static experiences. That's where the kind of the misnomer comes in. And you could do almost anything, like you said, with client-side JavaScript. And so there was lots of tools built around that. Frameworks became really hot to do like the statically generated pages where you go ahead and render all the markup at build time so you're not having to do that on the client side. Things like Gatsby and the React ecosystem and Gridsome and Scully, and there's a bunch of them. And then I think people started to realize, hey, the way we used to do websites with kind of the traditional Ruby on Rails or server-side rendered approach, there's still a lot of value in that. And I think people realized they were missing some of that functionality. And then I think the latest wave of this is getting into these like meta power frameworks like Next.js that can do it all. They can do statically generated pages, they can do server-side rendered pages, they have API routes built into them with serverless functions. So yeah, I think more and more of the tooling is coming, the tooling, the products and the knowledge is continuing to progress where a lot of the stuff that I see being built at least new is leveraging a lot of those concepts. 

CHARLES MAX_WOOD: Yep, absolutely. Well, it's funny too, because yeah, I mean, you get the next JS's before. I mean, it felt like Jamstack was just, you have a static site generator and you drop JavaScript on it and now you have like a full framework like next JS or Skully, I mean, yeah. 

JAMES_QUICK: Yeah. I think what's kind of happening is as people realize limitations in the Jamstack, so just going out there and solving those problems. So like there was like with, I use Gatsby for my personal site. If I needed some sort of like server side components to that, I could do serverless functions on Netlify as an example. Didn't have anything necessarily to do with Gatsby. I could just do that in Netlify. And then Next.js was like, Hey, we could, we could go ahead and just bake this into a framework. So then you got the API routes built in with Next.js with file-based routing. And then you had like the full server side component to it. And then there are things like a downside of the Jamstack is if you have a site with a ton of blog posts, that's kind of a standard example. Each time you add a new blog post, you have to go through a build. So you may be like rebuilding your entire site, going and grabbing all that information, rendering every single potential HTML page, but only one of them has changed. So then another feature in Next.js that I haven't used myself, but I hear a lot about is incremental static regeneration. And the idea is like, you don't have to necessarily pre-render everything upfront to keep your build times low. You could just pre-render some, maybe your top blog posts. And then the first time someone accesses a blog post that isn't already statically generated, it'll go and actually generate that page, serve it to them, and then cache that for everyone else. So it's like every limitation that people find in the Jamstack, some tool or some feature comes around to help solve that and keep making the Jamstack more and more encompassing and powerful and like you kind of alluded to, like potentially just replacing the way that we've done the web application. 

STEVE_EDWARDS: Now is that feature fairly widely available? I remember when that was the holy grill that everybody was looking to. And I know that Gatsby cloud was the first place I had heard of that being implemented, but it was only on the cloud, not just, you know, Gatsby by yourself. So I guess I haven't been paying attention. So what is the status of that implementation across the board? Is it still just in the reactor? Have you seen that in other tool sets as well? Because I don't think I've seen it like in Nuxt and I don't know. Netlify is something like that. 

JAMES_QUICK: I'm not sure right off hand. So I'm not, not very active in the view community. And so I couldn't, couldn't really answer that, but I think there were, like you said, kind of some things in the Gatsby world that were only available in Gatsby file, but the incremental static regeneration stuff with Next.js is less about the actual hosts and more just about the framework. So obviously that's going to work really well in Vercell than the parent company or the creators of Next.js. But there's adapters inside of Netlify as an example, that'll take your next project and convert that into whatever hosting situation happens behind the scenes with Netlify and have that available to you there. So some of that, I guess, would just come down to some sort of adapter support for the different host providers. But yeah, I don't know right offhand where that sort of feature set is in different- 

STEVE_EDWARDS: What about off the top of your head? Do you know there either? Or same thing? That was a joke. Offhand, off the top of your head. I always check both places. 

JAMES_QUICK: Yes, I did not think to check both of those. Next time I will. Speaking of dad jokes that we talked about before. I know that was too much. 

AJ_O’NEAL: That was too much, but the idea of incremental builds has been around since Jekyll since the very first static site generator ever. It just is difficult to do because the the two hard things in computer science are naming things off by one errors and caching right? Maybe a little too much build up on the drum there. 

STEVE_EDWARDS: I didn't do that one. I didn't do that. Not the drum roll. 

AJ_O’NEAL: Anyway, yeah, I did. It's been around in every iteration of the static site generation since before it was called jam stack or static site generation. But it's just it's a hard thing to do. It's a hard thing to get right because, for example, a lot of blogs have word clouds and they have relevant articles. And so when you go to compute and say, okay, now I've added a new blog article. Well, you have to go back through all the old ones and redo your your word cloud or redo your related articles. Cause now you have a new article that might be better suited in the related articles section and some things like that. So, or if you decide to make a small change to a theme, it's kind of difficult to ascertain, okay, where, where are the pages that are actually affected by this? It's a lot easier to just say, okay, rebuild them all. And then in terms of, you know, go and fetch just this one page. And then once you have that page cache it. Well, we've been doing that since WordPress. So the wheel of time, it keeps spinning along. But these, as far as you know, are these technologies standard? Well, yes and no, because they come and they go depending on the framework and depending on what the desired outcome is, if we want to lean more towards performance, or if we want to lean more towards making sure that we don't have caching errors, etc, etc. 

JAMES_QUICK: Yeah, I think I think that's like, that's the really interesting part to me of where Jamstack just started with like just static stuff and realized all the things that you just said and realized that some of those solutions have been around. How do we kind of bake that into this modern lack of a better word methodology and tool set that we have. And that's where they just keep like whoever they is the community and tools and platforms just keep adding functionalities honestly in a lot of ways to get feature parity with what we'd already done. Right. But the benefits a lot of this is like the biggest thing for me is developer experience like I'm not having to deploy a WordPress backend. I'm not having to deploy a database. There's lots of DB as a service companies. I'm not having to deploy a server at all. I'm not necessarily having to write full server code. I just write these serverless functions and magically things work. So kind of like bringing all those things into this modern ecosystem, I think is, it's kind of the fun of it, but yeah, in a lot of ways it seems like it's just playing catch up with the things that people were already used to. 

CHARLES MAX_WOOD: Yeah, one thing that I'm wondering about here because, you know, as we've kind of been playing catch up, you know, we're talking about cloud-based databases for Jamstack or using Auth0 or something like that for authentication with Jamstack. I mean, I've been building top-end devs, I've been putting things together so people can get courses and series and stuff like that. And initially, I was going to try and put it on like a Next.js and I just, I couldn't figure out how to get all the pieces to bolt on as quickly as I could just build it out in Rails. But I'm wondering, you know, so let's say that we're building a real app, right? I want to go and I want to build something where it's like, hey, you're signed in, you can see what you can see. If you're not signed in, then you can, but you can only see what you're permitted to see. Payments is another thing where I'm going, you have Stripe Connect, which kind of, no, it's not Stripe Connect, it's a Stripe Connect. Anyway, so it'll just link out to Stripe and you pay and you come back. So I guess that just works. But I have my backend generating that link because it has to know the secret. And I guess you could do that with serverless. I'm just trying to figure out like, how do you actually go build a jam stack app? That's actually an app and not just static stuff with fancy frills on top of it. Does that make sense? 

AJ_O’NEAL: Yeah, that's what it is though. That's the J is JavaScript and the A is API's and that's the fancy frills on top and M is the markup. 

STEVE_EDWARDS: Well, now you're starting to see tool sets though, like aisles. Yeah. And there's a couple other ones that we've been, yeah. Yeah. The stuff where you can, you know, have your static and then you're sprinkling areas of interactivity. I think a pop astro, I think is another attempt at that. There's a, there's a number of ones that are out there for, you know, having the jam stack and then sprinkling the app type job. 

JAMES_QUICK: That's where so much of that comes from. Like we talk so much about static and the jam stack, but we forget like most of the time with a lot of these frameworks, you still have the ability to do rehydration, which is like you have a static page and going back to, I think AJ, you brought up like the idea of like related posts and that sort of stuff. One thing you can do is you can have a statically generated page for the content itself, for like just the blog post. And then in JavaScript, dynamically go out and query what should be the related post. That way you don't necessarily have to trigger redeploys. You can have a function on the backend that does a query by keywords and then just sends back the most relevant post. And the cool thing is, while you're loading that information, the user's reading the article. So they don't even see that that data isn't necessarily displayed because they're not at the bottom of the article yet. So there's the ability to take this front-end JavaScript and do anything that you had been doing with a single page app or just with a JavaScript app in the past, but still get benefits of either or both server-side rendering and static pages. And like the building of like real applications, I think what's cool is now like you have these pieces to pick from, because these companies dedicate themselves to security or database or image optimization with Cloudinary or sending text messages and voice calls with Twilio, like there's all these services where that's what they do. And now as a developer, I don't have to do that. I can trust that it's pretty good. And I'm, I'm more like a connector. Like I'm, I'm building my app. I'm connecting in these other pieces and I get to focus on the stuff that's really core to me because I don't need to rewrite those other pieces. And there's like, that's not perfect, right? Like people look at that now I'm dependent upon these other services. So it's absolutely something to consider. But it's really cool as a developer for developer experience standpoint in the Jamstack, I can pick a few different services to do the things I need, pick a framework that I really enjoy working with, deploy this on a place that like, I don't have to do anything but connect to GitHub repository and have a couple files in there. That's pretty cool. All of these products that are good have free tiers that can take me a long way. And so like if you're paying any money to host an application in the Jamstack. Hopefully you're making money by that point because the free tiers are so good that you can go a long way. So I think that's really empowering for people that now they can start to build actual real applications with functionality, not have to know the nitty gritty details of everything behind the scenes, not have to build it all themselves, but be kind of up and running quicker than they have ever been before and cheaper than it's ever been before, too. 

CHARLES MAX_WOOD: So one thing that I'm wondering about, and I'm just trying to figure out how like, because you kind of alluded to this being a connector thing. And I'm kind of liking it. My brain is kind of fitting the little Lego pieces together as far as how this might work. Right. And so I could see something where you have like a serverless web hook for your Stripe web hooks, right? Or some kind of serverless maybe for like getting information out of. Well, I guess you just query out zero directly or query some of these other systems directly. But then as you start to bolt stuff together like this user is on this Stripe subscription and does these kinds of things. That's where the databases come in, right? And so, yeah, at the end of the day, I mean, yeah, you should be in good shape as far as being able to get this stuff. And so then all you're really doing is managing permissions one way or the other and permissions on your database or data source. 

JAMES_QUICK: Yeah. And I'll give you a semi-concrete example of some of the stuff you just talked about. So, John Meyers who is a developer advocate at Superbase, has been doing really, really cool stuff. Superbase is a really cool product. 

CHARLES MAX_WOOD: I was going to say, it's called Superbase? Really? 

JAMES_QUICK: Yes, actually, yeah, Super, S-U-P-A. And I guess we should clarify, it's an open source alternative to Firebase. So I personally think that's just really cool, because it's a pretty small team that's building a pretty kick-ass product. And it's built on top of Postgres. So that was their focus from the beginning, of being built on top of open source, and specifically Postgres for the database for various reasons, but he started putting together some tutorials about building like your own course platform type thing. And he connected and here's a bunch of buzzwords, all zero and super base and Prisma and Next.js and Stripe. And so the different pieces in there, like the all zero set up in Next.js is you do like literally a file config with a couple of lines of code and it gives you this callback route. So after the user logs in, it redirects the user back to this API route in Next.js and you can do whatever you want. So an example of that would be, hey, if that user is logging in for the first time, go ahead and save a record of them in the database, of your own database for you to manage. But before you do that, save them in Stripe, get their ID in Stripe, and then associate that with the record that you saved in your own database. That way you've already got the association taken care of. And then you can have them buy a product that redirects over to Stripe, it sends a callback to Next.js. You've got another serverless endpoint where you can handle that callback. You can take information in there to then update your database with the information that comes from Stripe. So I followed that and build like a pretty simple tutorial slash demo thing that was like, it was like the epitome of why this stuff is so cool to me. Again, all free tiers, most of the logic's done for me. I connect it, hopefully products, most of them have pretty good docs, some of them don't. And that helps make it as easy as possible, but being able to integrate like payments, users, file storage, all that stuff in one place was pretty, pretty neat. That was fun for me. 

CHARLES MAX_WOOD: I really dig it. I really, yeah, it seems like it really does open up possibilities. I mean, I think there's still a place for like a backend or server-side rendered sites as well, but it seems like, yeah, you know, like you were saying, you can get a long way on the free hosting on Netlify or Versal or some of these other ones and just kind of use some of the basic features and then, you know, maybe pay for your serverless time or something depending on how their plans are set up. And yeah, you just took all this stuff up and you run.

JAMES_QUICK: Yeah, absolutely. That's like developer experience and just like speed to building something is definitely my two favorite pieces. And I think we're seeing more of that. Like I've seen more products just like it's a developer out there that had an idea for some sort of product. And a ton of those have been shipped. Like some of it's just COVID people will have more time, but the tools are getting better they are able to build something quicker. And if it's a product that they sell, like they're in that free tier and scale up. And then by the time they're actually having to pay something at that point, they've made money to cover those costs easy. And that's been really fun to watch. I haven't really done much of like the entrepreneurial side myself yet outside of like content and selling courses. But that's one of the things, one of my goals, I mean, not like right now, but to build some sort of SaaS product at some point and try to kind of scale something out that people end up using and get value from.

CHARLES MAX_WOOD: Yeah, well, and I mean, when you use you're talking about like, like pushing stuff up, I mean, you know, just my experience with deploying applications that I've built in Rails or Express or something like that, you either wind up having to figure something out like a Heroku or something like that. That's kind of the easiest way to go Heroku. I think I'm using digital lotion app thing for some of my backend hosted stuff. But this stuff, I mean, you almost literally just push it into the Git repo, just like you would do for a Heroku, except Netlify just picks it up and builds it. And like you said, it's free, right? I mean, if I put something on that platform on DigitalOcean or on Heroku, I usually have to pay for it as soon as I'm putting it up. And the other thing is, is if my app builds just slightly different, then I have to go customize it. I have to go tell it what to do differently. Whereas most of the time, if you're setting up a Next.js or something like that, they've solved all these problems in a way that's fairly universal for people on the front end to just take advantage of. And so I definitely see this as a, as a really interesting and viable option in those ways. 

JAMES_QUICK: Yeah. And not to mention, I think it's where like, there's this mix of what you see on Twitter and what you see on blog posts and videos of people just staying with the latest and greatest and, uh, kind of talking about how it's going to replace everything. Like that's, it just doesn't actually work like that in the real world. Like as excited about this as I am, like real companies don't move this quickly. But the more you see it progress and the more you see people, like developers on their personal time trying this stuff out, that's when they come with ideas to their company to say, Hey, like this thing's gotten a lot easier. There was a good example of that for me at FedEx was there was like the best developer I've ever been around, um, would would basically just write everything from scratch. And we were using Java and Spring Boot, uh, or we were moving to Java and Spring Boot from just, um, Java. And there was so much built into the framework of Spring Boot that replaced like a ton of this person's code and they didn't want to, they would still rather build it out themselves. But we were just looking like we don't need to do that anymore. Like this is taken care of for us. So yeah, I think the more, more people see it, the more people try it out. People take ideas and they go to work. And that's how you kind of see that momentum starts to build and build, especially as companies start to adopt the different technologies. Look at something like React. React was something that so many companies stayed away from just the idea of a spa framework for so long. And now every app that I hear of that's being rebuilt is built with React or a single page application or framework. Whereas five years ago, people were still really debating about that. 

CHARLES MAX_WOOD: So I think we've established that you can build real apps, quote unquote, real apps with Jamstack. I guess my next question is, is where are things going from here? I mean, what, what capabilities are being added to just kind of take things to the next level? Is it sort of the some of the hardware features like Bluetooth and stuff like that? Or is it are people building a different kind of app that we just don't think about? Or are they incorporating blockchain? I mean, I'm real curious to see what you're seeing coming next. 

JMES: Yeah, blockchain is a topic that is I've never spent any time with well beyond me. So I don't have any guesses or insights there. One of the things I don't know that this is necessarily changing. But one of the limitations in the Jamstack, specifically with serverless functions, is the ability to have like a socket connection for streaming data to and from a client. That's one of the use cases that I have come across in a couple of kind of demo apps that move me away from the traditional serverless function route and go to a full Node Express API back in Heroku or something. And the reason is that these serverless functions spin up and spin down. So they like come up, they answer your request, and then they go back down and disappear. And they do that constantly. Like every request that comes in, it's like, all right, here's a new function and now it's gone cause it's done with its job. So it doesn't really have that ability to do those persistent connections. So that's one of the things that I am kind of curious to see like how and when that gets solved in a reasonable way. Another aspect of that, this is kind of relevant to PlanetScale, the company that I worked at from a serverless database connection perspective with these serverless routes, serverless functions, again, they spin up and spin down. And so you're not maintaining this database connection long term. You're having to kind of connect and drop over and over again. And potentially as your app scales, that's like lots of connections happening at a time individually. So one of the things that PlanetScale does is kind of abstract the idea of connection pooling. And you're not having to manage any of that stuff itself. And it can handle, I think we advertise kind of like infinite connections. But like tens of thousands have been tested in some of the stuff we've done, connections. And so I think technologies, whether it be database or anything else, that help support this idea of serverless functions and update the way that they work or the way that you work with them or the API or whatever to support building all those gaps, potential gaps that we have. That's one of the things I think that, I don't have like specifics, but I think that would be a goal for a lot of companies. It's just how do we integrate into the environment that people seem to be moving to? 

AJ_O’NEAL: Yeah. So two things. One, there's actually a really cool example of a static site using persistent connections, which is Snapdrop.net. It's essentially an airdrop for everybody. So it has a very airdrop-ish interface. The only server component is that it tells you what other computers are on your network based on your IP address and the port that you're connecting from. But it's all the file transfer and messages happen between using WebRTC. So there's no back-end component necessary for it. So if you're building a game, well, if you're going to scale out to thousands of users, it probably wouldn't work. But if you've got, you know, a small game or something like that, where you want to have a few persistent connections, the WebRTC model will actually work for that, depending on your use case. And then the other was the thing that you just said, which now I don't remember. I wanted to know more. What, what, what do you mean by the, you said something to the effect of as we build these things out, we. We're trying to figure out who knows how to move toward it or something like that. But what do you think about that? 

JAMES_QUICK: Yeah, I guess the idea of like, we kind of talked about Jamstack in some ways. It's just been like working towards feature parity. So moving people in this new direction, hopefully with a lot of benefits, but not having all the solutions that were previously available in regular server side rendered compo or projects. So I was saying like, as, as we start to see more apps moving the serverless route, the potential limitations of using serverless, like my perceived limitation of socket connections, which I have a question about SnapDrop in a second. And then a few other things like connections to databases and that sort of stuff. I think more products are going to evolve themselves to match the needs of people that are in a serverless architecture. 

AJ_O’NEAL: All architectures have servers. 

JAMES_QUICK: That is true, which is one of like, and I talk about this when I give talks on serverless, the serverless doesn't mean that there isn't a server, right? There's always servers behind the scenes. The serverless aspect of that is just from a developer perspective, I don't care about the server behind the scenes. I don't have to patch it. I don't have to update it. I don't have to deploy it. I don't have to take it down. I don't have to write code specifically for the server. I just write like a function in the magical case of like Netlify and Vercell and other hosts that do this really well. And that function is literally hosted as an API endpoint for me without me having to worry about it. So serverless in that case is just I don't have to worry about it, which again goes back to developer experience. If I'm learning to program and want to build something that's less that I have to learn and that much quicker for me to get to the point where I have something that I can share with people. 

AJ_O’NEAL: I say this in every episode where we talk about these things. So, so my obligatory pushback on this is the complexity of learning how to do simple express apps on digital ocean is so incredibly low. I don't think it's worth the additional complexity of learning a dozen other services to save $5 a month. Because if you're worried about saving $5 a month so you can use something that's free, but you're gonna take on all that additional burden. And I guess maybe it's different because maybe you're coming from a perspective where you only wanna focus on HTML. I'm from Node. So for me, if I wanna be able to do something custom and I have to read all this documentation, I have to figure out what these workarounds are, and I have to figure out how to tie these things together. I'd rather just put up a route, write a function or two, have the thing do what it's supposed to do, you know, and be happy. So I pushed back on the idea that serverless is less complicated, because to me, serverless is more complicated. It's more magic, there's more stuff hidden away. You know, just putting up a simple, caddy web server up on DigitalOcean with Express is just, it's dirt simple and it's dirt cheap, and I'd much rather pay $5 a month than have to deal with. You're just so much extra stuff to avoid paying five bucks. 

JAMES_QUICK: Yeah. I'll reverse pushback if that's allowed. 

AJ_O’NEAL: Yeah, you totally can. 

JAMES_QUICK: Yeah. So I don't think it's, 

STEVE_EDWARDS: please, please, please. 

JAMES_QUICK: I don't, I don't think it's a direct correlation between saving five bucks a month and like doing all these integrations. Right. So there are certainly some differences of doing an express server yourself and doing not doing express and just doing serverless functions, but the idea of having to integrate with all these other services is that's if you want to, like you don't have to. You could still do feature parity of what you would do in Node Express almost the exact same way. There are limitations, but almost the exact same way in serverless functions. And I think one thing to consider too is like, that would be, this would be your approach coming from your background. So you are very comfortable with Node and Express. If you're looking at someone who's never done backend, instead of having to teach them here's how you set up a node server, here are the different components that's going on behind the scenes. If you're able to show them, hey, there's some magic that's going on, but for you to get started, create this file on this directory, and now you've got that server-side component. I think from their perspective, that is easier to get started because there's less to learn. And this doesn't by any means mean that I don't think people should have that experience because I absolutely think they should, but I'm just looking at getting started. So for your perspective of moving to service like that is more for you to learn because now you're doing it a different way than you've already gotten used to. 

AJ_O’NEAL: Well, and you lose all the control and I just don't, it's six to one, half a dozen of the other. I mean, if you're going to say, Oh, well, all you have to do is serverless is put this file in this folder and then push. Well, that's, that's all you have to do anyway. Right. I mean, whether you're doing it with serverless or you're doing it with digital ocean or wherever you do it, all you got to do is put a file at a folder and push something and in the case of if you're running the node service yourself and you don't have something to have it restart automatically, you either have to set something up for it to restart automatically when you, when you add new files or you have to manually restart it. But a lot of that stuff again, I've said it before, so I won't drag on too long here, but you know this idea that servers are complex and you have to do all these updates and that's not the way that it is anymore. You know, it just like the way that front end code has changed. We don't live in the eighties anymore. Well, I guess the nineties anymore. We, we it's a server is not this thing that you have to constantly keep. It's if you set it and forget it, everything's containerized. Everything's virtualized. So a server instance is standalone. It's going to be secure. It's, it's not like it was back in the nineties where. There would be a mail server and a time server and 60 services that are all open to the public internet. If you remember back in the days, I don't know if you're old enough, but you remember back in the days when you used to get online on Windows and then Windows messages would pop up because the Windows messaging service on the computer was exposed to the public internet. We just don't live in those days anymore. Now when you spin up a server, it's an isolated thing it has the node service that you need on it. It probably has a time client that's built in. And then that's basically it. You don't have to manage all these security patches and whatnot because those things aren't, if you're running a node service, node is the only thing that you have to be concerned about. That's one of the great things about node and Go and Rust to some extent is the abandonment of shared libraries so that you don't have to think about, oh, what are the 600 possible things that could go wrong? It's just, no, if you need to install node, you install node. If you need to update node, you update node. And the other stuff is literally not important because you're not using it. So I went out longer than I, than I intended to there. 

JAMES_QUICK: Yeah. Well, I think that I think you are absolutely correct. And it is easy from the perspective of, of preaching about serverless to over dramatize what it is like. Right. So like most of us, depending on where you are, are probably not doing patches and that sort of stuff. But there are instances where if you just get a VM on the node and you're managing your stuff that way, like you are having to do that. You're having to do everything is yours, right? Like you have a VM. If there's no needs to be updated, that's your responsibility. So there are some there. Things like Heroku are- 

AJ_O’NEAL: The same thing though. You still have to update node even when you're doing serverless because you go in your config file and you reapply. So you type three lines here, you type three lines there. That said, I do want to agree with you. There's a lot of good stuff that's happening in the jam stack space. For example, I think the best use case is stuff that you totally don't care about is intellectual property independent, not a core part of your business. Like comments on a blog. No one cares about comments on a blog. It's nice for, you know, it's, it's a nice to have, but it's completely unnecessary. It doesn't, it's not where the value is. It's just an ancillary way to interact with people. So it doesn't matter if you use discus or if you build your own or whatever because it's so generic that there's no intellectual property value or business value in it. And so why not outsource it? 

JAMES_QUICK: Yeah. As long as, as long as that piece works, that's at that point, like all you care about, cause then where you make your money or where you do your secret sauce or whatever cliche you want to use as the stuff that you actually do build yourself. 

AJ_O’NEAL: Right. And the one thing that I tend towards is you should have secret sauce. And if all you're doing is just linking up one API to another, you might not have any secret sauce. 

CHARLES MAX_WOOD: Yeah. Which is easier to rip off that way. Right. 

AJ_O’NEAL: It's fine for a blog. You know, if you just personal blog, I think that personal blogs are the most awesome case for jamstack because you're not running an application. You don't need to know anything about the database. You don't need to query anything in a database. You don't need any custom logic. It's just like, uh, yeah, would I like something to do a machine learning analysis of my posts and, uh, give me a related box or give a comment box and sort comments. Yeah, that's great. So I love that stuff. I think that's that's awesome it's just what we start talking about applications. That's where I get a little defensive and say whoa Whoa, let's not just pretend that we can magic one wave we're gonna create business value that's gonna lead to a product that is somehow successful and we're not gonna have any intellectual property to back it 

 

Time is of the essence when identifying and resolving issues in your software and our friends at ray gun are here to help their brand new alerting feature is now available for crash reporting and real user monitoring to make sure you're quickly notified of the errors, crashes, and front-end performance issues that matter most to you in your business. Set thresholds for your alert based on an increase in error count, a spike in load time, or new issues introduced in the latest deployment, along with custom filters that give you even greater control. Assign multiple users to ensure the right team members are notified, with alerts linked directly to the issue in Raygun, taking you to the root cause faster. Never miss another mission-critical issue in your software again. Try Raygon Alerting today and create a world class issue resolution workflow that gives you and your customer peace of mind. Visit raygon.com to learn more. Their simple usage plans start from as little as $4 per month with unlimited apps and users. That's raygon.com to start your free 14 day trial. 

 

CHARLES MAX_WOOD: Well, and I think this is where the trade offs come in, right? Is that, yeah, James also said, you know, you're gonna have some secret sauce, right? Or at least you probably should. I agree also that, yeah, I mean, if you're just bolting all the open internet stuff together to create your product, somebody else can come along and do the same thing, right? You're pretty vulnerable in the market, in my opinion. But the flip side is that, yeah, if you have some kind of stuff that's proprietary, you can do it. The other thing though, and this is something that came to mind while you were talking about like static blogs and stuff like that, is that I've seen people build like a blog post and then they have some little snippet in there that actually does something. So it's like here's how to save money on your health insurance, right? And so they'll put a little form in there that hits a serverless on the back end and it's real fast and easy and it only gets hit a handful of times a day but it's useful and people care and so you get it. And I see that as kind of an easy next stage for the Jamstack stuff and then as you fold stuff in. You can figure more and more things out and bring in more services if you need to. But the other thing that I've seen both from web frameworks and from a lot of these services is that they all have some kind of limitation somewhere, right? You're going to run into a place where, gee, I really wish that my online database did this thing and it doesn't. Or I really wish, I really need kind of this weird custom logic and there's not really a good place to put it. And so I can kind of shoehorn it into this serverless and hope that it kind of does the right thing in most circumstances. But, and I think that's where you start getting into the place where it's like, maybe I ought to just go build a custom express app, right? Or maybe I ought to go just build this service and go or whatever, right? That, that looks really good. And there's nothing wrong with that. Right. And eventually you are going to move, I think, into a place where you have some of these microservices out there that are kind of a step above serverless that you're actually saying, you know, I've got some real logic behind this and I'm providing these couple of microservices. And so I don't see any of this as necessarily highly competitive. It's just really understanding your problems, understanding what solutions exist, understanding what the limitations are, and then picking the right thing and either custom doing it or customizing what you're pulling in. 

JAMES_QUICK: Yeah, I think that's a great take and to go to kind of reiterate, I think we do, we glorify everything that's new. Like people, and I do this too, right? And not necessarily intentionally. Yeah, guilty. Yeah, it's just so easy, right? Like it seems like yes, yes, yes. But two examples of this from my experience at FedEx doing enterprise software, we got to the point where like, two things were really important. CI-CD, which was brand new. Like we had basically had nothing CI-CD at the point that I was there and we never done microservices. And these were buzzwords that were kicked around and it was never 100% taken seriously of like, it's not just that easy. Like there are benefits to them, but there also are complications with building applications with a microservices architecture versus doing a monolithic architecture. Like there are differences, probably a lot of, probably more if you're doing it right benefits than not, but there's still a lot of learning that goes into it. And so even with those, the services in the JAMstack space, like you said, there's probably more integration pain points than we talk about as a collective dev space. So we do glorify and kind of gloss over. There's still work to be done here. And then that like, I think AJ, so like all of your points too, like if that still works for you to not do that, or if the regular developer, like it works for them to not do that, or it works for them to do it. Like having that tool set and ability there is the benefit, right? Like you have the ability to choose and leverage some pieces here and build your own there if you need to do that custom logic. 

AJ_O’NEAL: And also it's just, it's often oversimplified in, in the sense of, and this is where I don't have a good counter argument, but it's oversimplified in the sense of you, all you have to do is learn this one thing, but then you actually have to end up learning dozens of things. But that's true no matter which one you do. 

CHARLES MAX_WOOD: Welcome to dev.

AJ_O’NEAL: So it's, it's, yeah, it's the promise is, oh, all you have to do is this one thing, but then you actually have to do 12 things or 100 things. But the good news on the JAMstack side is because these are all services that are designed to capture your intellectual property so that they can turn you into a subscription customer is that they're making sure that they have good documentation that's relatively up to date. Whereas, but those skills aren't really transferable. You don't learn the real terms for things. You don't learn how things really work. You don't, so you don't, you don't learn what, what it is that's actually happening. It's just, it's just magic, but there's a tutorial that tells you the incantations. Right. Whereas on the other side, the tutorials really suck because it's not profitable to teach someone how to do something that's going to be cheaper, faster, and better that that they could do themselves without you. Right. So, so there's no marketing team that's, Hey, you could use our jam stack service. And we're going to take all your intellectual property. We're going to put you in a, in a proprietary vendor lock in, or, Hey, here's our other great tutorial on how to do this in the same amount of time or less with traditional technologies where you don't have to worry about any of that. No one's going to do that. Right. It's it just, it doesn't make sense as a business model. So although on the, on the one side, if you learn the core technologies, you're better off because you're going to be able to understand how things work. You're going to be able to to get what it is you're doing and what you can do, what the possibilities are. You're gonna be better able to make decisions on when you should choose one thing versus the other. So that's the benefit to it. But the detriment is, well, it's tough to find good tutorials because nobody, no company is out there saying, yeah, you know what, don't use our product that's gonna lock you in and take your intellectual property into our system. Here's the escape hatch that makes everything easy for you. Just, you know, it's, nobody with a marketing budget's gonna do that. And so the marketing on here's this one thing wins out on the 12 hour Amazon course versus what I know only takes 60 seconds to do in DigitalOcean. And if you read my blog post on it, yeah, there you go. You can do it in 60 seconds too. But if you're just Googling, you know, you come across, there's not enough brand strength. And here's the right way that's easy to do that gets you done in 60 seconds. And that's where I totally concede. And I have no, no counter argument. 

JAMES_QUICK: Yeah. Yeah, I'll give you a good example of that. I think from my experience in developer relations at all zero, and I think developer relations anywhere, like the goal of all zero primarily is for you to not have to care about security. Like for us to just, or for them to do the majority of the stuff for you and do it well and make sure you're secure and all these things. So there's this really interesting balance of like, part of my job is just showing people, here's how you get set up and react with all zero. Might mention very intimidating terms like OAuth 2 and OpenID Connect, but it- Like I'm not going to go into detail to teach you exactly what that is behind the scenes because it doesn't matter. But the caveats of that is, and I think this is something you alluded to, it's very important to understand how those things work so that when you have issues, you know how to address them. If you have custom integration problems, or if you're building stuff yourself, and then you can make an educated guess at which way it makes the most sense. So that's one of the things that I always do or try to is if I do use the service. I want to do some sort of investigation to see what that looks like to build it myself from my learning perspective. And I like people have different opinions on what's the best way to get started with web development. Do I start with vanilla JavaScript or do I go right into React and just learn it that way? I recommend learning vanilla JavaScript because you can learn React and then you're that much better off learning any other framework because you know how JavaScript works. So I will always encourage people no matter how good tools are out there with abstractions that investing some time and understanding behind the scenes is going to benefit you and your career and your development skills going forward. 

AJ_O’NEAL: So curious, what did, what was your path? Did you learn react first or did you learn JavaScript first? 

JAMES_QUICK: I had no structure to my learning process. I didn't really, I learned very little JavaScript. Well, I guess I learned JavaScript first. I was kind of all over the place. I didn't know where to start or what to do. So I started looking at the way. 

CHARLES MAX_WOOD: I wish that were less common. 

JAMES_QUICK: Yeah.I did the web developer bootcamp by Colt Steel on Udemy. So I got a lot of good JavaScript there, mainly backend stuff with Express and then bounced around with WordPress tutorials and Ruby on Rails and came back to the Express route and eventually got into React. So I had written a decent amount, but I realized also I was still missing a lot of core React. So things like JavaScript 30 from WestBoss are just fantastic to just really understand how JavaScript works and how to write JavaScript and then to combine that in React. Now, another thing I've done is I've kind of simulated what React does and demoed tutorials that I do and vanilla JavaScript and kind of build my own React thing because at surface level, it's not that complicated. You take some sort of string and you're gonna put variables inside of it every time you re-render. So I think that sort of stuff is really good practice to actually understand the basics of how a framework or a tool will work for you. 

CHARLES MAX_WOOD: All right, now I get to derail us. Okay, so going back to Jamstack, one thing that I have found that is really nice about Jamstack, and it's interesting too, because like, like I said, I'm building like top end devs on rails, right? But I'm pulling in cause it's all server rendered. I'm pulling in a lot of these kinds of things anyway, right? Like Auth0 I'm using for top end devs, you know, I'm pulling in other services. But one thing that I've been working on doing a little bit better, and you've kind of alluded to it with like streaming and stuff is doing a lot of the PWA stuff, right? And you know, I'm going, you know, I want web workers where it makes sense. It's funny cause I don't think they're like the the solution to all the problems, but they are pretty nice in certain circumstances. I want push notifications coming out of my system. I want... And so you kind of get the idea that, you know, there are certain things that come pretty nicely. And again, just coming back to this idea of connecting stuff, I found that in a lot of cases when I'm pulling in the kinds of services that we've talked about for Jamstack apps, building your app into a PWA is really really convenient. And so I'm kind of pulling two ideas together because usually we talk about PWAs or JAMstack, but I really think that they dovetail really neatly together. 

AJWell, yeah, I think nowadays with, yeah, today it's all coming. It's all come into the same place. Obviously the economic incentive is for you to not own your data. So they're, it's going to move that way. Yeah. 

JAMES_QUICK: PWAs I feel like are kind of similar to how some of our conversation has been people kind of push back and they're like, why would I need that? I've got the web app and it works great. And then some people like PWAs all the way. And I think some of that discussion by people creating content, including myself around PWAs is not necessarily addressing the question of like, how needed is this? How helpful is this for users? And as much as I think it can be useful for users, I actually don't use any PWAs myself. 

AJ_O’NEAL: Okay, so let's define what is a progressive web app. What would you contrast the due? Cause to me at this point, they're just, it, everything's flowing together in terms of front end is just you throw JavaScript and script tags and magic happens. And it seems like every, how is Jamstack not a PWA? 

JAMES_QUICK: Yeah. So a couple of specifics, like I think the one thing that's most relevant to me is a PWA typically, whether it's Android or IOS has the ability to kind of save that address as an icon on your phone. So you can kind of open it just like an app and it basically runs in a web browser that's contained and looks like a regular app. So it gets rid of the Chrome, other browser and that sort of stuff. And although that may seem super simple, like if there's not a native application in the store for your app, but there's a really good mobile website, having that icon there and being able to open that directly is actually nice because you're separated from the browser. You're not having to type in the name every time. And then you get some benefits, like if you're doing what's it offline capabilities or whatever, where if you're making changes to your data, you can kind of cache that and service workers and update that when your network comes back. Again, that sounds really nice. Like I like the idea of having that I've still I've yet to actually experience that struggle where I've needed it. So as as cool as that sounds, I actually haven't leveraged that capability myself in any apps that I use. 

CHARLES MAX_WOOD: Yeah, I mean, to get that I think you just need the manifest for the PWA. 

JAMES_QUICK: Yeah, there's Yeah, that's basically the difference. 

CHARLES MAX_WOOD: But the offline storage, which if you're pulling the data in with your JavaScript or your framework anyway, it's an extra step or two in a lot of cases. Sometimes it's more complicated than that. Fair. That's a fair point. But you know, in a lot of cases you just pull it in and you store it in your offline storage, you use your service workers to speed it up. You, a lot of these others are really kind of optional, like, like the push notifications and things like that some of the other sort of hardware integrations that you can do out of the browser. But for the most part, I mean, you could do some pretty powerful stuff. And what's nice is that, yeah, it gives you that nice experience on the phone because you are playing in a little bit more performance constrained arena there. And the experience people expect is different. But I've been able to find services that basically fill in a lot of those gaps. 

JAMES_QUICK: Yeah. I guess one cool example is the Twitter app. Pretty sure the one that's actually on the store is a PWA or maybe specifically Android. I'm not 100% sure, but I think Twitter app specifically is a PWA. So from a developer perspective, and we've had this promise for years, like every new thing promises right once deploy everywhere. And that's never quite the case. Um, but that is the way it's like, yeah, but that, that is the case for the most part. Like Twitter wrote a good website that's responsive and more or less you slap on like the manifest and now you've got a native application on the phone and there's like a little more to it. But for the most part, they add a little bit. Now they've got their mobile app experience and they're not having to maintain two code bases. So like, I feel like that's almost cliche because every time that comes up, there's always more to it. But there is a benefit where if you've already got a good website, now you can add a little to it and you get this mobile experience that works as good as the native website. That's kind of what it is. 

AJ_O’NEAL: And if you don't cripple the website in the first place, it can just work as good as the native website without ending anything. My least favorite thing is, well, it is responsive websites. I hate them. Part of it's because I have an iPhone SE and no one stops to think. Maybe I don't carry a full-size TV in my back pocket. Maybe I actually have a phone because no one sells phones. Everybody sells phablets, but. 

CHARLES MAX_WOOD: Hey, my phablet fits in my front pocket. Thank you very much. 

AJ_O’NEAL: Right. 

JAMES_QUICK: I mean, also I'm confused by that because this isn't like, isn't this exactly what responsive design solves is so that it looks good on your screen and not just the bigger phones? 

AJ_O’NEAL: It makes it so that when the page loads, the page is aesthetically pleasing, maybe, if you're lucky. Now, in Twitter's case, it actually works out. But the problem is that, no, I prefer back when the iPhone first launched, I think websites worked way better than they do today. Because if you needed something, if you needed to get into a feature of something, you just double tap or zoom, pinch and zoom, and you could do whatever you needed to do. And nowadays, nobody has the resources to actually test whether or not their website works well on mobile and there's no automated frameworks for it. And so people design on a desktop and then it gets deployed to these different sized devices. And you've got to have had this experience where it's pop up with three popups and you can't click out of them because they're all overlaid on top of each other. There's the cookie popup. And then there's the subscribe now pop up and then there's the have you checked out our latest thing pop up and and you literally can't click the X's because it's just off centered by you know 10 pixels and so the X is off screen and then you try to rotate your phone and you you can't click the X that way because now it's too many pixels up and you can't scroll because the pop-ups are in the way. So this is my experience with 50% of websites are completely unusable on an iPhone SE so I can go to Twitter Twitter is one of the websites that works really, really well. And it makes sense, because Twitter is really stupid. It's just a wall, or a feed. What do we call it? 

CHARLES MAX_WOOD: I think you said a couple of things that are important. But I think AJ just wants a new internet for Christmas. That said, I think the biggest problem that you're running into is that, like you said, they're designed on the desktop. And anymore, people use their phones primarily. And so what they should be doing is the main view should be the mobile view. And then it should be the mobile view be responsive from there to the bigger screens, not the other way around. And I think that's where you run into those issues. Um, but, but it's a design issue. It's, it's not, I mean, it's not Jamstack. It's everybody. 

AJ_O’NEAL: Well, it depends. It, if you're doing something like Twitter on or Instagram, yeah, it should work on a phone, but if you're doing something that's productivity or that is useful for getting work done and something that's important. No, no, like who, who in their right mind is going to sit on their phone and spend 20 minutes like fat fingering with their thumbs when they could get on a computer and get it done in 30 seconds. You know, I, I do it sometimes, but I hate myself because I don't like why am I? 

CHARLES MAX_WOOD: AJ doesn't have teenagers. 

AJ_O’NEAL: Well, but that's the thing. Instagram and Twitter, right? Teenagers aren't doing anything that's, they're not doing something that is part of business value, right? 

CHARLES MAX_WOOD: My kids will only get on the computer if they have to. I did want to get into one other thing and so I'm going to take the conversation over again. And James, this one's a little bit more probably your arena than mine. But if you're, if you're pulling together a Jamstack app and it connects to all this stuff, I'm wondering, because I'm a big fan of writing tests and making sure that you have a CI that works and what's like, Hey, this stuff actually does what it's supposed to. Right. I set up my permissions. It pulls the permissions out of the database or out of Auth0 or out of what have you, and then that actually shows the right thing or it says, uh, uh, uh you're not getting in or you know it says hey you're an admin what where do you want to use your godlike powers I mean how do I test that how do I how do I pull together a Jamstack app and actually test it so that before I deploy it right because I'm building a real app now in Jamstack when I deploy it I know it's gonna work right instead of oh I deployed it and I can't I can't use this and now I have to go and debug it in production which is painful.

JAMES_QUICK: I'm not sure, I'll talk a little bit. I'm not sure if it's actually that much different than what you do in a regular server side rendered app. I mean, like thinking about like Tames: esting pyramid, right? You start with unit tests and you write a ton of those to try to catch as many small things, just logic wise as you can. And like designing your functions to be functional or pure functions or whatever, where you pass all the inputs and you should get the same design output and all that kind of stuff. So you write all your unit tests and I don't, I don't 

CHARLES MAX_WOOD: Or predictable side effects if you can't improve your functions. 

JAMES_QUICK: So yeah, I mean, that I think relatively stays the same. I think what's really interesting to me is doing end-to-end testing with something like Cypress. And I'll first caveat by saying I actually don't have much experience with testing. I could probably talk about it, but I don't have a ton of hands-on experience. But let's say you go through your CI-CD pipeline. I'm going to shout out PlanetScale again, just because this is a neat feature. PlanetScale has this idea of branches for databases. So they're very similar to what your branches would be with code. So in your pipeline, you could go spin up a branch, you could go populate it with data, and then connect to that thing in your deployed application with an environment variable for database URL. So all that's being created on the fly. So you're deploying your app as part of the build process or before the build process, you create this branch in the database, populate it with dummy data, and then run your end-to-end tests on the front end before you actually deploy this thing so that from your application that you're running, or you deployed in kind of a staging environment or whatever run end-to-end tests that's actually connecting to a database. You know what the expected inputs and outputs are. You know what the data is that you populated into your database. Now you can run those end-to-end tests just like you would have for the most part in kind of your regular server-side rendered applications. Have that be a part of your pipeline and then yes or no, did it work? Decides whether or not it actually gets deployed to production space. So you can help me understand if there's pieces of that that are different that I'm not addressing, but I think a lot of those same concepts still apply just in it's just a little bit different application that you're working with. 

CHARLES MAX_WOOD: No, that doesn't sense. I don't naturally reach for Cypress when I'm testing. I tend not to write those as much, but yeah. 

AJ_O’NEAL: Cypress is the new one. It's only been around what two years? Well, popular, so many popular, maybe one or two years. 

CHARLES MAX_WOOD: Longer than that, 

AJ_O’NEAL: but still popular though. It's a, it's a big one now. How long has been popular? People have known about it now, you know, but also I think that's another one of the benefits of the jam stack is that do you really have to do that much testing? Okay. Because you're not writing anything custom and these APIs that have been written. Well, they've already been tested by the other 10,000, 100,000 million customers that are using them. So how, how much, how much testing 

CHARLES MAX_WOOD: I'm cringing over here? Oh, I want to know what works. 

AJ_O’NEAL: Well, well, yeah, obviously you need to go. I guess as you build it, as you build it. Yeah. You get to a point where, okay, I built it, it works now. How much testing do you need other than that? Once you know, okay, I got this data from the user, I passed this data to the API, the API gave me a 200, okay, I'm done. What else? I mean, I guess all the testing at that point would be, can I put it in a virtual phone simulator that makes sure that it's actually possible to click the buttons?

CHARLES MAX_WOOD: Well, that's a usability test. I think what we're boiling this down to though, and I really like the idea of the Cypress tests or something like that. I mean, I use something else from my Rails apps because it's mostly server rendered and so I can intercept it in different ways. But yeah, that makes a lot of sense to me from the Cypress point of view, because it's like, hey, this is the journey that the user's gonna go through and I gotta make sure it works. And so, yeah, then it goes and it logs into Auth0 and gets the token back and any other data back and sets up the user or identifies the user and then gets the permissions and does all the right things and okay, I expected to see this. I didn't expect, I expected not to see this and yeah, I think that's totally doable. And yeah, you don't have to test the entire, every single course I have, I have to test, no, but you, you can figure out what kind of the journeys you're going to take your user on are going to look like and you can script those out.

JAMES_QUICK: Absolutely. Yeah. 

CHARLES MAX_WOOD: Make sure everything's talking to each other. 

JAMES_QUICK: Mm hmm. I think that's exactly the point. Like you, you said, like you pause and you're like, but I want to know what works. And I think the difference is you don't have to test the things that have already been tested by these other platforms. Like you can. 

CHARLES MAX_WOOD: Right. 

JAMES_QUICK: Balance of like, do I trust these things? Yes or no. Well, if you do, you trust that they've done their testing and their product is good, otherwise they're going to lose money, but then it's your responsibility to test that the things that you do work that way that they should. And that's where that integration layer comes from. And you can mock out, right? Like instead of doing a login, you could just send a username and password that you know has these roles and permissions to Auth0 and not actually even trigger typing in a username and password, just like manually enter that. And then based on that, does the admin page or admin tab show based on those profiles that I know that user has because I created that user and that's part of my test data. So you're not having to test the things that they do for you, but you're having to test all the pieces that fit together that include the things that they do for you. 

CHARLES MAX_WOOD: Yeah. Yeah, that's, that's absolutely true. Right. I don't have to test that the login works. I just have to test that if the app thinks I'm logged in as an admin, it does admin things. 

AJ_O’NEAL: Yep. Absolutely. So the thing that was surfaced there, I think is you should definitely, absolutely 100% test the happy path. The thing that your ideal user is most likely to do. 

CHARLES MAX_WOOD: Yeah. Well, the other thing that I push for, so you have the happy path, you have the, you can pay me path. Those should be tested, right? And then the other thing is that the happy path is sometimes hard to figure out or is hard to understand. And so you should have some analytics in your application that allow you to say, when people log in, they all go use this, they all go use this. They're not really using this one as much, right? And that way, you know that the critical things are the three things that they're probably doing on your app on a regular basis. And paying you, and paying you. 

AJ_O’NEAL: If you, yeah, but the...The happy path should not be hard to figure out because that should be the reason that you created the thing. And if people aren't using it, 

CHARLES MAX_WOOD: sometimes you're surprised. 

AJ_O’NEAL: Yeah, but it, it shouldn't be hard to figure out. It should be a matter of proof by contradiction, not proof by exhaustion. 

CHARLES MAX_WOOD: Yeah. 

JAMES_QUICK: Well, that's, that's why tests are constantly evolving too. Right? Like if you have, if you think it's one thing, and then there's all these other ones that you continue to write your tests and never have to worry about that scenario again, unless something else changes.

CHARLES MAX_WOOD: But the thing is, is that, yeah, I mean, you change something underlying in your react components or something on your serverless end, and you don't realize, Hey, it's expecting something that it's not getting anymore. Or it's it. Yeah. Anyway, it's changed the functionality in this critical way, or maybe it just changes the functionality slightly. And as your test traversed the DOM, there's just, it's just, it's not finding it. Right. So your test is broken, but your stuff works. It you at least have the peace of mind that you can confidently move forward and know that, hey, I changed this little piece of this lower level thing like permissions and everything still works. And for me, that's what it's about, right? Is I don't want to have to go and worry that I goofed something up, find out two days later because everybody's pissed because they can't log in. So anyway, we're kind of getting toward the end of our time. Do we want to talk about anything else or should we hit picks?

JAMES_QUICK: Oh, it may be a longer like I I'm just imagining that it's actually still making a front end request for a socket connection to a regular back end that's not a serverless function back end. But I don't know that and I don't know if you know that. 

AJ_O’NEAL: So what it has is a connection pool on the back end. So it keeps a list. Basically, it takes the IP address that things come from. And it keeps a list of everything that's at that IP address and it serves that to the front. And so that is something that is persistent that could not be done in a function because it doesn't, there is no guarantee as to when it is done. It is done when all the people on that IP address have closed out all of their tabs and that's when it's done. So that part, that requires 

JAMES_QUICK: a regular server. 

AJ_O’NEAL: Right, but the socket connection, I mean, I guess technically, technically, you don't have no, you don't have to have a regular server for that. No, you don't because you can just take the IP information, stick it in the database. You don't need any socket connected out there yet. You could totally do this on a, on a, on a function because you just, you stick it. I was thinking stick it in memory because it's so short lived, but if you wanted to scale it out, I mean, I think the guy runs it on a single server because you could literally serve millions and millions of clients because all they have to do is make one API request. Here's my IP address. What are the other identifiers that are on the same IP address as me. That's it. Right. So, so his load is so low that if everybody in the world use snap drop, and I don't know that he'd need more than one server for it. 

JAMES_QUICK: But I think, I think it has to like the actual socket connection that gets created. And again, I think this should be for later on. I'm just curious from a technical perspective, I think that has to be like your traditional server. Because if you know have a server, a socket connection and serverless function, it's gonna go away. 

AJ_O’NEAL: No, there is there is not a socket connection on the server side. So what happens is there's two things that the happy path, everything's going the way that it ought to go, is that you get back the URL of the other, the WebRTC URL of the other client, you get that back and then you just connect to them. And so then you're connecting from your computer to their computer on the same local network. So you don't have to worry about firewalls or any of that because it's all local network stuff. So you're behind the NAT, you're behind the firewall, you don't need to do any NAT traversal or or UPnP or TURN or any of that. However, there are situations where your local computer has a local firewall on it and the other person's computer has a local firewall on it, in which case it will use Google's free TURN server to do the firewall busting and then relay that way. 

JAMES_QUICK: Yeah, so you're doing WebRTC, like peer-to-peer type thing. 

AJ_O’NEAL: Yeah. 

JAMES_QUICK: Versus, I think the problem, it still doesn't solve I have a server that I need to maintain a connection with someone directly and I want to pump out data to them. 

AJ_O’NEAL: But that is that happens over WebRTC. So if I'm sharing a file with you over, over SnapDrop, it's because we're on the same local network. That's how it ties them together is by the public IP address. So if I was at a university where 10,000 people have a one single shared public IP address, then using SnapDrop would not be as optimal of an experience as it would be where two of us are sitting in the same room at the office together, which is how I typically use it. But if I were to use it at a school location, there might be 10 or 20 bubbles up rather than just being the two of us bubbles up. But the socket is between you and the other local computer, because every computer is a server. Every computer is a client. This is how Xbox works. This is how Skype works. I guess that's another thing is the term server often gets misunderstood. A server is simply a program that answers the phone. 

JAMES_QUICK: Yep. So I think I enjoy this stuff. I think it's fun. The one thing, the one separate thing that it doesn't solve is listening for building a discord chat bot, which is the specific example of where I went for, where the code registers a socket connection to discord itself. So you're not guaranteed of any same local network or anything and streaming in those messages as they come. 

AJ_O’NEAL: So you could still do that with long polling. You could still do that in a function with long polling. You would just be keeping your functions around a little bit longer, because you would put in there a timeout of, say, 10 seconds. And so you would long poll, and you'd wait up for 10 seconds before you disconnect. So I think in that instance, it's going to be more expensive and more complex to try to do it over a function than it would be if you just did it in Express, but you can do it in a function. 

JAMES_QUICK: You still have. You still have potential drops, right? Unless you're long polling every nine seconds for 10 seconds, you still have potential drops of that time in between. And you'd have to find some way to like ping that thing to start it up yourself. 

CHARLES MAX_WOOD: So I'm going to push just to picks. 

AJ_O’NEAL: But wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, wait, but what level of millisecond delay is, is unacceptable? Are you saying that 20 milliseconds of quote unquote drop is unacceptable? 

JAMES_QUICK: I mean, it goes against. All right. I'm going to go against the idea of of the socket, but all right. It's in the mix. 

CHARLES MAX_WOOD: It's all good. 

 

Hey folks, this is Charles Maxwood from Top End Devs. And lately I've been working on actually building out Top End Devs. If you're interested, you can go to topendevs.com slash podcast, and you can actually hear a little bit more about my story about why I'm doing what I'm doing with Top End Devs, why I changed it from devchat.tv to Top End Devs. But what I really want to get into is that I have decided that I'm going to build the platform that I always wished I had with devchat.tv and I renamed it to Top End Devs because I want to give you the resources that are going to help you to build the career that you want, right? So whether you want to be an influencer in tech, whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever, I want to give you the resources that are going to help you do that. We're going to have career and leadership resources in there, and we're going to be giving you content on a regular basis to help you level up and max out your career. So go check it out at topendevs.com. If you sign up before my birthday, that's December 14th. If you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's topendevs.com. 

 

CHARLES MAX_WOOD: Hey Steve, you wanna start us off with picks? 

STEVE_EDWARDS: I would be ecstatic to start us off with picks. So first actual pick before I get to the high point of any of my podcast episode. Saw this tweet a couple of weeks ago on Twitter, obviously. Oh, using the web app, by the way, you know, not any other app. It's called a dad bent calendar was apparently this kid who was a 12 year old, uh, react developer. So I'm, I'm sort of letting the fact that it's react and not you slide, uh, for the moment. It's a dad bent calendar. Kids name is rebel Carlberg West. And so what is an advent calendar and every day, uh, a new one's on block. But when you click on it, it shows a dad joke and then you can show it or you can hide it. It's truly amazing. For example, did you hear about the mathematician who's afraid of negative numbers? He'll stop at nothing to avoid them. So not all of his jokes are up to my high standards, but it's really a cool little app and anything with dad jokes I like. So dadvent.revelcw.com. I'll put links in the show notes. Now for today's dad jokes. I was in a hotel recently and I met some chess enthusiasts that like the game of chess but they just kept bragging about how good they are at the game. There's nothing worse than chestnuts boasting in an open foyer. You got a chuckle? Thank you. Then in the news, I read a story about a huge food fight that took place at a seafood restaurant. There was battered fish everywhere.And then finally, the other day I was walking along and I saw a man getting mugged by two dudes so I stepped in to help. He didn't stand a chance against the three of us. Thank you, I think so. Those are my picks. 

CHARLES MAX_WOOD: All right, AJ, what are your picks? 

AJ_O’NEAL: All right. So first of all, Snapdrop, because we talked about that it's an airdrop alternative, it obviously cannot do beam forming antenna transfer, like airdrop does. So you're not going to get gigabit speeds over Wi Fi with it. But for transferring files that are less than a gigabyte, it's pretty darn good. Also gonna pick The Expanse. I've been listening to that and then also started watching it as well. I will have to say, you know, if you want something done well, get Netflix to do it. Amazon is all right. You know, the gist of the story comes through, but the special effects, ugh, Stranger Things just puts TV shows in a whole another world that's closer to movies. And Amazon doesn't quite do that. But yeah, I think the book on this one might be a little bit better than the show, but it's interesting to see the show for context and in season one seemed pretty good, season two. But anyway, yeah, the expanse of the vines and wakes pretty cool. Definitely some language there. That's something you can listen to around the kids, unfortunately, some other things on the show. But also, so we talked about this a little bit. There's there's a video Kai Hendry did that's called Happy Paths Should Be a Video. And he's just kind of rambling around some ideas, but I think that his ideas are good ideas. So I'm going to say, you know, check that out if you're interested in it. He's just venting frustration about an experience that he had with a website where it seemed that the goal wasn't clear and the way to do the thing that it seems that most people might've come there for or that you're or whatever it was you were expected to do wasn't clear. And so I thought he had a cool video on that. And then I picked up some new monitors while a new monitor and other ones on the way and the Dell S2721QS. It's I guess their S series monitor 27 inch, the 2021 edition and then QS because it has an adjustable stand instead of a fixed stand or something. But basically I'm moving away from my Apple Thunderbolt displays because they are starting to show their age, especially with the M1 computers. And Apple is just not doing a good job of making sure that things are staying backwards compatible. And who knows when they're going to come out with an affordable display again. And the Dell S2721QS is basically, I think it's the same panel as what's in the ultra fine that everybody loves, except that instead of paying an extra $400 to have it pre calibrated and to have a hub inside of it, you just, if you want to buy multiple of them, you just buy a calibrator and then you buy a, uh, you know, a hub so that you can connect to it. And then you're only paying $300 for the monitor instead of paying 700 or a thousand dollars for the monitor and you're getting pretty much the same monitor just you know It just less less money and not all the fluff that you don't need if you're setting up multiple monitors because we're setting up three monitors you certainly don't need the USB Thunderbolt USB C hub or whatever in each single monitor, right? Anyway, and then on that normal stuff just for anybody that is looking how to simplify the developer experience and get it easier to Install the tools that you love web install dev. I've got creeds of craftsmanship comm for stuff that I'm, I'm putting up the curated list of talks and presentations and, uh, just materials that are based around solid, solid programming principles and engineering principles from top engineers. Uh, feel free to add to that list and then, you know, you could follow me on the YouTube, the Twitch's, the Twitter's, the, all the things, um, for live streams as well as, uh, as, uh, uh, teaching content, probably not as good as James though. So you'll have to check him out for, for his stuff.

CHARLES MAX_WOOD: All right, I'm going to jump in here. Like my shtick, I guess, is the board game pick. I'm going to pick a card game this week. It's called family business and effectively each player has mob family and you play cards to put out contracts on other people's. Cards, other people's, uh, mob family members, and it puts them on the hit list and you know, other cards, let you take people off or swap theirs with yours or all kinds of stuff, right? And then once you have six mobsters on the hit list, then the mob war starts and you start offing them, starting with the first one and you just pull them out of the game. And whoever has, it's basically the last mob family standing, right? And so when you run out of mob members, you're out. And it's, it's a pretty simple game, but it's a lot of fun. It's a little bit different than a lot of the other kind of competitive games that you play because a lot of times what you're doing is you're just trying to get there before anybody else. But, in this one, at least the way that I played it with my friends, you wind up making deals with people and ganging up on other people and boy, if they smell blood in the water, they'll put like four-year people on the hit list and then you've got to figure out how to save them. But anyway, it's a super fun game so I'm going to pick family business. And then I just want to let people know a couple of things have changed with Top End Devs. I was doing the pre-launch sale up through my birthday, which as we record this is actually And 

AJ_O’NEAL: happy birthday. 

CHARLES MAX_WOOD: Oh, thanks. Anyway, the deal is, is that it's just taking me longer to get crap together for it. So I'm going to extend the pre-launch deal up through the end of the year. So if you're listening to this before January 1st, I haven't checked to see when this goes out. You can still get the pre-launch deal. Otherwise just go to top end devs and you can start getting in and setting that up. I will probably actually put up a special episode, like right before the pre-launch ends, just to remind people. But yeah, we're getting all the stuff together there so that people can stay on top of the five things that will get you to be a top end dev. And then other picks. I've been listening to the Expanse books as well, just because the last book came out last month. And so I'm going to I'm going to back AJ up on that. The books are really, really good. The TV show is actually, in my opinion, a fairly good adaptation of the books. Like they've stayed close enough to it to where I've enjoyed them. You know, I'm not having these, oh, that's wrong. I've been watching Wheel of Time with my wife and I've read those books and love them to death. And they have, uh, drastically changed the story there. So anyway, so it's yeah. So I've enjoyed the series. I just have to be fine with it being a different story with the same characters. Anyway, so really been enjoying that. And then last, lastly, one other thing I'm going to throw in to the mix. And I put, I put some stuff together for this before, but I'm going to have the podcast bootcamp available. It's not going to be part of the regular subscription for top end devs, but it'll be something you can add to your subscription within top end devs. So if you're interested in learning how to podcast or start your podcast, putting out regular content every week is one of the five things you have to do to be a top end dev, then you can go do that. It'll walk you through how to launch and grow. So anyway, those are my picks. I did pick a whole bunch of my own stuff, but I've also been enjoying a lot of this other stuff. One other thing I guess I should throw out there, I've also been reading Think and Grow Rich, and I've been really, really digging that. I'm actually rereading it again. So anyway, James, what are your picks? 

JAMES_QUICK: Yeah, one of my favorite items of all time is the charger from Anker, and it doubles as a charger that you can plug in, and it has the USB, and the link I have in here has USB and USB-C. So you plug it into the wall, you charge your stuff at night, but then it charges itself so you can take that out and then carry it around with you as a portable charger bank as well. So that's basically the only charger that I take with me on trips. And it's absolutely fantastic. It's one of the coolest things I've ever bought. So I highly recommend people, if you do any amount of travel, to check that out and take it with you. Other thing, I just got a new MacBook Pro for work, the M1, and I just, I can't say enough. Like I won't even waste your time, but it's absolutely incredible in so many ways for developers and content creators. Like it's just fantastic. It really, it's incredible. Yeah, he's one of those too. Mm-hmm. Yeah, it's really amazing. So that's really cool. I'm super excited to have that. And the last thing I'll share is my podcast co-host and I have created two Advent courses. We talked about Advent earlier, Advent of JavaScript or Advent of JS.com and Advent of CSS.com. That's where we do a challenge each day. And even though it's past December 1st now, if people sign up for free, they'll get all the challenges later on to work through and then solutions if people want to pay for them. So that's something we've been working on and are pretty excited about. Admin of JS.com and Advent of CSS.com. 

CHARLES MAX_WOOD: Awesome. Well, you probably have to tell people where to get your podcast and then any other places that they can find you online. 

JAMES_QUICK: Sure. Yeah. I feel weird shouting out a podcast on a podcast, 

CHARLES MAX_WOOD: but now we're all friends. 

JAMES_QUICK: The podcast we run is compressed.fm and it's a weekly episodes about web development and design. And then I am James Q quick on most things, tick talk, Twitter. That's my YouTube. Uh, that sort of stuff. Yes. We refer to those as shameless plugs. Everybody else can be too. 

AJ_O’NEAL: I'm shameful, but I'm shameless. 

CHARLES MAX_WOOD: All right. Well, this has been fun. Thanks for coming, James. 

JAMES_QUICK: Yeah, absolutely. Thank you for having me. Appreciate it. 

JAMES_QUICK: All right, folks, we're going to wrap it up here until next time. Max out. 

STEVE_EDWARDS: Adios. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c-a-c-h-e-f-l-y.com to learn more.