Ep. #79, Rethinking Your Stack with Mike Cavaliere of Echobind

Brian Douglas: Welcome to another installment of JAMstack Radio.

On the line we've got Mike Cavaliere. Welcome, Mike.

Mike Cavaliere: Thanks. It's great to be here. Thanks for having me.

Brian: Yeah. And I'm glad we crossed paths.

We had a mutual connection, which was Anthony Campolo, who's been on this podcast talking about RedwoodJS.

Folks definitely check out that episode.

Also shout out to Anthony who just took his first job at StepZen.

Super excited about him progressing in his career as a developer.

But how about you, Mike, who are you? Where'd you come from?

Mike: Let's see. I came from Queens, New York.

I've been in the software world for some 20 years at this point.

I started at a time when my school was not teaching web friendly languages.

And this was the point of the dotcom boom.

So I learned web family languages pretty much on my own.

Started with a one credit HTML class, started building webpages as a freelancer.

This came up on Anthony's podcast, the first production website I worked on was baywatch.com for the original Baywatch.

Brian: Oh, nice.

Mike: Which is crazy.

Brian: What an honor.

Mike: I know, right? Yeah. Back with the Hoff.

But I did a lot of that for a while and started to learn full stack work back then, which for me was like learning PHP before the framework days and building some database applications with that.

Taking that further, when Ruby on Rails came about, I started messing with Ruby on Rails and building some full stack applications there, but still being really into the JavaScript world like I'd never left JavaScript.

So prior to jQuery becoming this big phenomenon, there was a prototype and script.aculo.us and new tools and even just Vanilla JavaScript back then.

Leverage that stuff during the browser wars, where it was the opponent to Firefox and Netscape and you had to make things look good across browser.

And then fast forward into modern JavaScript age where JavaScript is a Swiss army knife, where you can do everything with it, front end, back end JAMstack mobile.

And for the last six years, probably, focusing on React related technologies.

Brian: Yeah.

Mike: So at Echobind, a particular company I worked for, I've done a lot of React Native work, a lot of web React work, still some Ruby on Rails as well.

But in my personal endeavors, focusing more and more on Next.js because I love it as a framework.

I love it as a toolkit. And the versatility of it is really great.

Cause you can build flat fast applications that are just websites and you can take them a step further, pretty easily into full stack application.

So anyway, that's about me. I love software.

I love writing it. I love teaching it to people.

Brian: Yeah. Are you still based in Queens?

Mike: I'm in Brooklyn now.

I've lived in Brooklyn for 10 years, but I grew up in Queens and I'm there every now and then to see family.

Brian: Okay. What part of Queens?

Mike: Flushing, Kew Gardens Hills area.

Yeah. Do you know Queens?

Brian: I know Queens.

My mom went to St. John's and then my family is from Brooklyn and east New York.

Mike: Okay.

Brian: So I'm familiar with the area, but I'm from Florida.

So I didn't go to New York a lot because my family always came to Florida.

Mike: Got you.

Brian: That's how I grew up.

It's like my family, my mom and dad literally escaped New York in the '80s and then decided to never go back and everybody would come and visit us in our nice little suburbs.

Mike: Nice. Are you still in Florida, still located there or where are you located?

Brian: It's funny because I'm actually in Florida at this moment recording this podcast, visiting my grandma. She's 89 this Saturday.

Mike: Wow.

Brian: But I'm based in Oakland, California.

Mike: Got you.

Brian: Yeah. So Echobind. I'm familiar with Echobind, I've actually taught it with a couple engineers there.

I know a couple of engineers there as well.

So consultancy, you all build a lot of projects for different various organizations.

And you mentioned Next.js.

Mike: Mm-hmm.

Brian: So can you expound a little bit more about what are the benefits of using something like Next.js when you're building projects for clients?

Mike: Let's see where to start. So React, a lot of people love because it's a great UI framework.

It's modular fits into any environment, it's fast. Next.jstakes React a step further when building anything full stack because it does a lot for you that you would otherwise have to figure out in harder ways.

So namely something like routing.

Routing when you're dealing with a Node and React application you go to a URL, it has determined what page that corresponds to and determine whether the state exists on the front end, the back end or both.

If you're just coming to that page for the first time, you might have to do a server-side render.

If you're navigating with JavaScript, you might have to do a push state.

So Next.js has a really great router built in and it's file system based.

So all you do is create a file in the API directory, an API end point exists.

So that's one benefit of Next.js.

It simplifies a lot of chores that it just has paradigms for it, you don't have to go crazy thinking about.

Another is that it works really well for the JAMstack or for speed in general, in that everything comes static rendered by default.

So if your page is just a bunch of content written in React components, then it's automatically a static page and it's just going to load really fast.

If it just needs to get some data when you deploy to the server one time, you just have a method in there for pulling that information and it will still render a static page.

And then even further, if you need to get dynamic data, you can use get server-side props and it'll pull that stuff in and your pages will still be static in performance.

So that's another added benefit is the speed and the paradigms for speed that it has attached to it.

I also just really like working with it.

I like the way it simplifies things for you, but I enjoy the experience of writing it.

Brian: Yeah.

And I guess I've been doing Next.js for almost a year now at this point, but I've always spent quite a few years since it's been around acknowledging its existence, but never using it for any projects.

And then once I ended up using it for a project, I was like, "Oh, I get it. I 100% get it."

You mentioned in passing you've started to work through Ruby on Rails.

You spent some time working in that framework and ecosystem.

Mike: A lot of time. Yeah.

Brian: I also came from Ruby on Rails and that was actually the framework I learned how to program in.

So once I learned the basics of the web, I was like, "I need to build faster."

Someone appointed me to Ruby on Rails.

I was able to get something accomplished with that, actually knowing what I was doing, which is a scary thing, but also it's a novel thing too as well when it comes to web programming.

But I'm curious, back when you ended up using Ruby on Rails, I just want to go back to your story and your origin story.

What was the catalyst that pushed you towards Ruby on Rails? And then what brought you out of that?

Mike: Good question.

I started working with Ruby on Rails when I was at a small dev shop and the other engineers that exposed me to it.

I think at the time I was doing a lot in PHP and still front end, always doing front end, but I had done some service side type stuff in Perl and Ruby on Rails was brand new.

It was version 1.1, I think, that we started playing around with it in.

And they showed it to me and showed me all these cool design patterns, things you can do with it.

They introduced me to the Gang Of Four Patterns, the book on design patterns and how that was implemented in Ruby on Rails.

And I started reading tutorials. And so I had the generators work cause I believe they had them back then.

And I just was like, "This is really interesting." Because it's trying to do a lot of stuff.

More importantly, I noticed that coming from PHP, PHP, when it came out, did a lot of stuff automatically that you had to do manually in Perl.

For example, processing post parameters in Perl you would have to write a regex to translate that data into something that's readable and PHP, you had this underscore post array, which would just give you all variables.

I'm like, "Oh, this is an evolution." It's great.

So Rails was like that to PHP at the time, to me, where Rails took it a step further and yeah, they'll process the request for you, but now they have the controller level for you.

They've got the model abstractions from the database. So-

Brian: Yeah, similar to how Next.js provides the routings, which was a huge pain point in React.

Mike: Exactly.

And that's a deciding factor in new technologies that I start to work with.

It's like, "What are you simplifying that is manual?"

It's like David Heinemeier Hansson talks about he wrote Rails cause he's lazy.

He didn't want to reinvent the wheel.

And each evolution of technology should not reinvent the wheel, right? Unless there's something wrong with that wheel, and then maybe you rewrite it.

But that's also why I use Next.js.

But as far as your question how I ended up moving away from Rails.

Rails is still amazing. I saw just how much JavaScript is moving these days.

JavaScript is moving fast. It's incredibly popular.

There's a lot out there for it. I've always loved JavaScript.

So I just started to get back into writing more of that stuff.

But also I liked that you can write JavaScript full stack and do all the things you need to do with it.

I like the speed that those tools provide. Well, that's one thing about Ruby on Rails.

It's not as suited for serverless, which is very common these days, but oddly enough, Ruby on Rails is like the person that you dated that you compare every future person to.

Rails have so many good programming paradigms.

I'm always thinking, "What does this new thing not have that Rails has?"

And I'm constantly measuring everything against it.

So yeah, nowadays I do focus on JavaScript, but the Rails patterns and the features that they have are always in my head for like, "How do I do that with JS?

Brian: So my introduction into moving into JavaScript full-time, I eventually got there with React was that you started building everything on your own, testing was like an afterthought.

At least when I started writing JavaScript, there were some testing patterns and there were some tools to get it done.

But if you wanted to have Cucumber or Selenium tests in JavaScript at the time it was near impossible and it just wasn't the same.

So then you just cut corners, you don't have tests, you deal with it, you have to manage all your dependencies.

And if something breaks, you don't have anything to fall back on.

So yeah, I'm with you with that. I love the patterns of Rails.

And I had mentioned off air that RedwoodJS, my introduction from Anthony has got me hooked. RedwoodJS plus JS Next.js, I like having those patterns and not having needing to discover those every single time I start a new project or try to convince the rest of the people working with me that my pattern's the best pattern because at the end of the day, it's going to be harder to convince people to say, "This is my file structure. This is how I do routing."

It's going to be so much easier to say, "Let's just use what Next does, so that way we can hire easily. We can pass off projects. We don't have to be stuck with constant tech debt."

And I don't know if you could speak on that with the Echobind by how you approach shipping projects for clients.

Is there a lot of handoff and education that has to happen when you leverage Next.js or the JAMstack for these client projects?

Mike: Good question. I'm trying to think of examples.

I think that in general, it really depends on the team that we're handing it to, right?

Because we work with such a variety of clients.

There are teams where, like this project that I just come off of, pretty intelligent tech team that knew or at least the people that built a large chunks of the app knew Next.js really well, for example.

There was education towards the end of it because the new engineers in the project didn't have the background that the original engineer did.

So in that case, there was some education around. It definitely happens.

And definitely Next.js is a little bit on the newer side.

So I would say that on our projects where we're handing it off to an in-house technical team, if they aren't super savvy with the particular framework and we're introducing it to them, then there's definitely some knowledge transfer, but we're prepared for that.

We write documentation really well.

We give people verbal walkthroughs to make sure they understand certain concepts and comment their code well enough, concisely not ridiculous amounts of comments that don't mean anything after a while, but we'll put information in there and try to make things really self-documenting.

So just being in a consultancy and having done it for so long, we're very good at the handoff process.

So yeah, there's definitely some of that.

I wouldn't say particularly with Next.js over anything else, we have to do it with React Native projects where we're handing React Native work off to a team that has less expertise in it than us too.

Brian: Yeah. But I imagine the benefit is the fact that you did use something that it's a known property and it has a community around it.

So folks can find their way, which leads to my next question, which is, I'm curious more into the book slash website that you have, Cut Into the Jamstack.

Do you want to talk a bit about that?

And some of the findings that are the learning tool can to share, but also hear from other folks?

Mike: Yeah, sure. I'll tell you first why I put it together.

So the book walks people through using the JAMstack to build a full stack application from inception to production.

So what I noticed out there is typically, traditionally when you're shipping a programming book, it's usually focused on one technology, right?

Either it's you're learning JavaScript or learning Next.js or you're learning Python, it's either language or framework most of the time.

A lot of people have the goal in mind to ship an entire project, right?

And that's one of the best ways to learn the program is to ship a project because it's a small project.

There's not as much out there for like, "This is how you build a software as a service application in this particular stack," or at least I didn't find it when I was searching.

And I felt that that's a particular piece of knowledge that is really valuable, particularly in the JavaScript world because if I want to ship something with React or Next.js, there's still plenty of other tools that I have to interact with.

I need something for creating a React based form, which there's a tool for, there's many tools for.

I need to figure out state management across the application, which there's a bunch of different ways to approach.

I need an ORM or query builder, something to interact with the database.

And then I need to know what happens when I am interacting with the database, but I need to associate that data with something from an API.

So there's a lot of particulars in the process of building particularly a software as a service application, but pretty much any full stack application that go beyond one piece of technology or another.

So the book's about tying these technologies and seeing patterns for how they work and also for how you deploy them.

So hosting is talked about in there as well.

And it's also tailored around one thing I know if I'm shipping a personal project, I don't want to spend a dime on it.

So I'm using free hosting providers for both the database and the serverless function.

So that to me is really appealing because the way you get better at stuff is shipping it, shipping, shipping, you don't have to spend 30 bucks a month every time you ship something just to learn that nobody wants it.

Brian: For sure. And I'm right there with you, not spending money on personal projects, side projects.

My biggest concern is shipping something, forgetting about it.

And then walking away, a year later taking like, "What was his $500 bills?"

The annual subscription that I forgot to cancel on a project that was literally a joke that I thought over the weekend.

I was like, "Oh, I'm going to buy this domain and ship a project to it and pay for it forever."

And yeah, that's always my concern.

So I'm curious of, I guess what is your ideal JAMstack? That would be a good question to--

Whether it's covered in your book or in the blog posts you've done. I'm curious.

Mike: I'd have to think about ideal JAMstack. Right now, what I've got is working pretty well.

The stack that I'm using and the JAMstack is my preferred set up right now.

It could change as does things do in the JavaScript world quickly.

So Next.js and React, Prisma is the ORM that I'm using, which I like quite a bit.

There is React-hook-form for the form management.

There is a Cloudinary, which is an image API.

Brian: I've not heard of that.

Mike: So Railway is the database technology that I'm using.

They're a newer start-up and they have a really great interface.

And I had a free plan where you get two different environments.

I highly recommend checking them out.

And I'm using Vercel for the hosting, which the cool thing about Railway is it integrates seamlessly with Vercel .

So you click a few buttons to get a Postgres database in Railway, you click another button it transfers all the environment variables to Vercel.

So you're up and running very fast. So that's particularly awesome.

And then another tool I'm using is NextAuth, which authentication is another one of those things that if you're working in Next, you have to think about at a full stack level.

Next off is great library. It connects single click authentication to any provider you can think of Google, Facebook, Insta, Discord, Slack, email, Magic Link, sign up, all that stuff is built into there.

Oh, and Stripe. Yeah. I'm going to be using the Stripe API in there because the app itself is going to have a billing component.

So that, to me, is this pretty great stack to work with.

I'm always looking at new tools and what are the ideal ways to work, particularly for shipping like a micro SaaS?

When I was early in the stages of building this book, I was thinking, "Well, do I want to do GraphQL on Apollo Server?"

Then there's something like Azura out there, which you create a Postgres database and it creates a GraphQL API for you.

There's Supabase and Firebase, all interesting tools.

I opted to go with this route because it was versatile.

Postgres is just great general purpose.

And by plugging into something like Prisma and free hosting on Railway, you have a good, a bit of versatility without adding too much work.

And I didn't want to make the book so complicated like I'm touching on a million different topics.

Maybe in a future book, I'll do more with the GraphQL world, but this works really well.

And I would use this setup to ship another initial SaaS after the topic.

So I like this big batch of technologies that I've got here.

Brian: Two follow-up questions.

One, is there anybody else who's competing with Prisma and their ORM space for at least the JavaScript world?

Mike: Yeah. There's other ORMs out there.

Much more mature ones too.

So there's SQLize, which has been around the longest, which it probably gets closest to Rails Active Record.

They follow similar patterns for a lot of that.

They have less TypeScript support, but they've added it in recent years.

I haven't worked with it recently, but they have definitely established and it probably has the most functionality overall type of ORM is there, it's pretty stable.

It's all TypeScript based. It's a good ORM. Prisma itself is newer, but there's funding behind it.

There's a big community behind it. They're moving very rapidly.

And they have certain things that are very new that are stand out.

Other than the interface being really clean and easy to use, they have this notion of their migrations are declarative rather than imperative, which is really interesting paradigm.

I mean, instead of being, "Okay, do this to the database and do this, do this, and then you're going to production run all of those and sequence."

It's more like, "Okay, this is what I want the database to look like. Here's my schema, let the computer do the work."

And that to me is an evolution on database migration thinking, which I think is a killer part of a good ORM, the migrations.

Another way Railway spoiled me is their migrations were very far ahead of their time and really established over time, really sturdy. So having that level of control over your data is really a valuable thing.

Brian: Yeah. I was spoiled by Rails being my first introductions to databases Postgres, all of the above by the time I actually was building more than just standard HTML pages, Rails was it for me.

And I didn't realize how great it was until I went to go to the React world and had to rebuild that stuff from scratch.

Like SQLize, I'm very familiar with that, but it also, it always felt like it was missing something that I thought Active Record gave me.

And I think Postgres has given me that again.

And again, something I only just recently I've been using Prisma for the longest time, but I've never actually pulled back the curtain or started from scratch on any project.

I've always been in a position where I inherited a project that already had Prisma.

Mike: Got you.

Brian: So that was my expertise for Prisma, at least Prisma 2 itself.

One point that you did make too as well, Postgres being versatile as well.

Even if you choose Railway, which when I googled Railway, of course, Anthony Campolo's step-by-step tutorial on deploying RedwoodJS apps includes Railway.

So I have to dig into that and learn more about that after.

But just being able to take your database and own it and move it wherever you want Postgres is a great solution and not needing to be locked down to whatever the fancy database providers that are out.

Mike: Absolutely. And it's so multipurpose, I mean, internally we talk a lot about this many different types of databases out there, right?

There's traditional or relational databases like Postgres, there's NoSQL databases like Mongo, there's Graph databases.

I think they all have use cases and strengths and weaknesses, but the reason we use Postgres NoSQL and also I use it personally as the starter one is just that you can go in any direction with it. Right?

You want to scale it up for speed, you can do a lot of that.

You want to scale it up for relational data, you can do that or you can transfer it to Graph database if you need to.

It's just a great starting point, no matter what you decide to do.

Because you never know where the app is going to go, am I going to really need something that needs a document type storage of NoSQL, that really is optimally for that?

Maybe. And I could transfer it if I need to. It's hard to make that decision in the early stage though, when you're shipping an app.

So this takes the thinking out of it, right?

Just start with a relational database and do what you need to do and then figure out where you're going to take this at.

Brian: Yeah. Excellent. I love it. I'm looking forward to digging into it.

I'm curious, do you have a timeframe for when the book will be available for people to read and get their hands on?

Mike: Yeah, the preview release of the book is going to be out within the next two weeks.

So it's going to be a 30 to 40% chunk of the content. And then later in the year--

My wife's giving birth in the next few weeks.

So I'm going to have a little bit of a hiatus, but then I'm going to go back to working on the book and fleshing it out and also taking feedback from people.

Part of the reason I'm doing a preview release is I want people to see what it feels like and tell me what they thought they learned from it, they thought it was missing.

I want to iterate on it based on actual feedback.

But yeah, the pre release is going to be coming out pretty shortly.

Brian: Cool. And that's cutintothejamstack.com

Mike: cutintothejamstack.com.

Brian: Cool.

Mike: You can also just find it on my Twitter profile and such.

Brian: Excellent. I'm curious of what you're using to distribute the book or what are you planning?

Mike: All right now it's just ConvertKit.

Brian: Okay.

Mike: Once I have the product loaded into ConvertKit them and see if there's better ways to promote it.

And because they have integrations with Gumroad and there's plenty of other ways to do that too.

Right now I'm so close to getting the initial chunk of the book done that I just want to finish that and then leverage up the promotion of it afterwards and see what works and what doesn't.

But yeah, if you have thoughts on that too, I'm always open to suggestions.

Brian: Yeah. Honestly, I have no thoughts.

I've not actually shipped the book myself, but I know I'm curious to know about your path because in the event I do ship a book, I love would just a knowledge and taking advantage of all the knowledge that we have here on the podcast.

So Mike, thanks for the chat, talking about Cut into the Jamstack.

I do want to transition us to pick, so these are jam picks, things that we're jamming on. It could be music, food, gaming.

A lot of people are playing games these days, got a lot of free time.

I don't know where they find it to be quite honest, but you've mentioned you're having, is this your first kid or is--

Mike: Second.

Brian: Second. Okay. Yeah. Well, two, your hands are full at that point.

Mike: Oh, yes.

Brian: You've got to play man to man.

But with that being said, let's transition to picks and I'll go first if you don't mind.

Mike: Sure.

Brian: I actually got two picks.

The first pick is a YouTube video I just shipped, titled everything I thought about developer relations was a lie.

Mike: Nice.

Brian: And it was an experiment really.

I've been experimenting with YouTube since I've had time to create content for work.

And I have experimented the thumbnails, experimented with the titles and this one actually struck the right nerve of YouTube algorithm versus community people who are interested in clicking the video.

And it goes into the current state of DevRel with my perspective and how I've been shifting to live streaming.

A lot of people on this podcast know I do live streaming on Twitch.

I also have a YouTube account, which I've mentioned a couple of times in this podcast and it's been a great experiment to do that, but also summarize my experience for the year.

So that's what the video is about.

DevRel has no-- I'm not sure you're familiar to the practice of DevRel.

Mike: No, not really.

Brian: But yeah.

Developer relations people who just make it their job to get on stage and talk about their products.

A lot of folks at different companies or organizations will do this.

I think previously a lot of consultants from a lot of the popular Rails consultants in the world, they spend a lot of time speaking at conferences and being cutting edge and talking about stuff that you're talking about.

So you'd be a perfect DevRel use case or a engineer role or whatever you--

The caveat is that you scale back the engineering a little bit. and you do way more content production, but that's the video.

I hope you all check it out. Let me know feedback, leave a comment.

Mike: I'm definitely going to check it out. It's awesome.

It makes me think because I just planned to do a lot more DevRel, I guess later in the year, because now I'm creating something I guess I got to talk about it.

So people will actually look at it. So cool.

As far as my pick, I can give you a book that I'm really, really loving.

Brian: Oh, nice.

Mike: The book is called Limitless Mind by Jim Kwik, who is a brain coach of sorts, a learning coach, I should say, who got a traumatic brain injury as a kid.

And over the course of many years, he figured out how to correct it and then train his brain to learn much faster than it would has, and then he's coached even some celebrities on faster learning methods and such.

Personally 14 years ago, I learned that I had a learning disability and that there were things about my brain that just were not optimal. My brain is like Ferrari that goes very slow. And there are certain things that are really strong about it. Certain things that leave a little to be desired. So I went down the rabbit hole of finding all the ways that you can improve this. You can improve the hardware of your brain to the point where things like this aren't a problem anymore and you can take it a lot further.

So I've been really obsessed with that over the past 14 years.

And I blogged a little bit about it on one of my blogs, adhdtechies.com, where I talk about some of the more interesting methods that I've used to improve certain brain facilities.

There's one thing called, what was it called?

Integrated listening systems, which uses bone conduction, headphones and Gregorian chants and Mozart music combined with balance exercises and visual stimulation.

But actually I did before and after measures and it actually had a significant improvement.

Brian: Wow. Excellent.

Mike: Yeah. So this book is phenomenal.

I'm in the initial stages where he's talking a lot about the thinking and the passion behind how you do some of the stuff that he teaches people to do, but I'm starting to get to the meat and potatoes of the how, which is stuff I'm always fascinated in.

Brian: Yeah, I love it. And I'm going to add it to my list.

I love this creative thinking and thinking differently as well.

I've been talking a lot with a lot of my closest colleagues and friends, mainly because I've been trying to rethink how to get my job done, rethink how to segment my day as well.

So I'm always looking for new opportunities to improve my best practices because I think--

I was actually listening to a podcast about the amount of people who read books after graduating high school. The drop-off is significant.

Mike: Wow.

Brian: That people just don't read. Continue education, doesn't stop it after college, it continues forever.

And the folks who can always continue to their education or just learn things like you learned of your learning disability, but also you learned how to, I don't want to use the word cope, but empower it, I guess would probably be a better term.

But a lot of folks could get down about maybe limitations, maybe some ceilings that they have to hit, by being able to understand how to empower themselves to work around the system is really encouraging to hear.

And I'm super happy that this book has impacted your life and your workflow too, as well.

Mike: Yeah. I love talking about that stuff too.

Brian: Yeah. Yeah.

Mike: Tons of stories.

Brian: Yeah. I do a lot of stuff. If you follow me on Twitter, you know I'm constantly--

I did a TikTok, actually I should mentioned I have a TikTok, but I did TikTok mainly because I'm mid thirties.

So I think that I know enough, but I don't know anything about that.

So I spent the time to go and learn how the kids are making TikToks and I made one and it was minorly successful, not even close to minorly, underwhelmingly not successful, but I know how to edit on TikTok now.

Mike: But you did it. Yeah.

Brian: Yeah. I did it. And I think that's the name of the game. It's just try things.

You tried a bunch of tools to build a full stack JAMstack applications that you're building and I'm benefiting from your knowledge.

Mike: Oh, yeah.

Brian: Yeah. And I appreciate that, but we could probably ramble and talk about this forever.

Mike: All day.

Brian: But we do have a time limit and I appreciate you again, Mike, for coming on and chatting. And I also appreciate you, listeners. Keep spreading the jam.