Ep. #60, Building Fullstack React Apps with Brandon Bayer

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got Brandon Bayer coming in live from-- Well, it's live for me but not live for you. But, coming from Thailand.

Brandon Bayer: Hello.

Brian: Hey, Brandon.

Brandon: Hello. Glad to be here.

Brian: Cool. Do you want to tell us what you do and why you got here, and also maybe if you want to mention why you're in Thailand?

Brandon: Sure. I came to Thailand for a work-cation, and for a month I was going to be here, but then the whole Corona thing happened and I decided to just stay here indefinitely.

So, here I am several months later. As of recently, I'm a full-time open sourcer, but before that for the past about three years I've been a full-stack consultant.

An independent consultant doing freelancing for multiple different companies and different startups.

Brian: Awesome. So full-stack consultant, we're here to talk about Blitz.js, which is the project I think that you're working on full time, is that correct?

Brandon: Correct.

Brian: Do you want to talk about that a little bit and how that was created and why?

Brandon: Sure. So Blitz.js is a full-stack framework for React, and it's built on Next.js, which if you're familiar with Next.js it's a really awesome framework for building React apps.

It gives you server-side rendering and client-side rendering, and static generation which is a fairly new feature similar to Gatsby.

The problem is that to build a full-stack application today, there's a lot of complexity that goes into it. Just think about how you would do that today.

Let's say you want to use Next.js for your front end, and then you need to pick a back-end.

You need a server of some sort to connect to your database and provide an API.

There's just a lot of complexity and you have to figure out which technologies you're going to use, and other communities have solved this with frameworks like Ruby on Rails.

But we don't have anything like that for JavaScript, so Blitz.js is exactly that.

Brian: OK. Excellent. Listeners are probably super familiar with Next.js because we talk about them as of recently they've come up in natural conversation quite a few times.

Ironically, they've never been on this podcast.

I did chat with Tim actually on another project I work on, which is Open Source Friday.

I'm curious how you arrived at building this total technology or encompassing this on Next.js, because I'm seeing a trend of React projects, or not even React projects, but basically React "Frameworks."

I think one of the things that React first came out of the gate was "It's not a framework, it's a library." But there's all these pieces to put together to make it a framework, so we started talking about the data layer or doing storage, Redux came out of the lead out of 100 different options. So now we're at the point where now we've figured out if you're going to do something try Redux, or if not maybe try Gra phQL or Apollo or whatever it is.

It sounds like with your framework you've made the decisions for the individuals, so that way any of the developers can get started really quickly.

I'm curious that we can run through the-- We got Next.js, what are the other components that make all these things work?

Brandon: Next.js, you can think of that as your front-end.

If we go all the way to the other end, to your database access, we have Prisma 2 by default, which just came out of beta so it's general availability now.

Prisma, if you're not familiar, is a type-safe database client.

You can connect to Postgres, MySQL, SQLite, and they'll be adding support for other databases.

It is fully typed with typescript, so you get automatic types for all of your database tables and columns and everything.

That's another relatively new technology that is just now there available, and so it's one of the key components of making Blitz.js really nice.

Brian: How would I even approach getting started, or even leveraging this?

Brandon: This gets at the heart of what the secret sauce is for Blitz.js.

Blitz.js provides this new data layer that I've never seen anywhere else, and it basically takes your API, your HTTP API and abstracts it away into a compile step.

Until now, anytime you build a React app, you have to have an API of some sort. A rest API, GraphQL API, etc.

That's a lot of complexity that a lot of apps don't need, so today tons of apps use Ruby on Rails so there's no API.

It's more like a monolith, and so there's still those same type of small business applications still exist today.

A lot of them want to use React, but then they have this API thin g, so what we've done is we abstract your entire API into a compile step and the resulting developer experiences that you write your server code--

We call them "Queries" and "Mutations," and it's just a plain function that acts or runs on a server, and then you import that function directly into your components.

Then at compile time that direct function import is swapped out with an HTTP API call. So when you're building a Blitz.js app, you don't even have to think about an API. Rust or GraphQL, nothing. All you do is focus on writing your server code, your front end code, and that's it.

One thing that's really nice about this is that for typescript, you get static, "Is this fully typed statically end to end?"

You have Prisma database access, so that's typed.

Then you have your functions that are typed, and then when you import them into your React components you have the types there too, because it's just a direct function import.

You don't have to have a separate process that's compiling or generating the types for you, like you do with GraphQL for example.

Brian: It's fascinating because I come from doing Ruby on Rails quite a few years ago, and we chatted offline about how we got into code.

We both learned through the program, which is Block, which teaches--

Taught Ruby on Rails, I'm not sure what they teach today, but having that experience and being able to just spin up an app really easily and not have to think about how to connect the back end to the front end was a great experience, especially for learning.

I was just able to manipulate my pseudo-ERB HTML and then my site worked, for the most part.

But I like the fact that the API itself is abstracted away so that when you get that same experience, and with my knowledge of Prisma you do get a schema upfront.

So, you can get a very similar way of--

Brandon: Prisma 2 is totally different. It doesn't have anything to do with GraphQL.

Brian: That's true. But they do have the schema file.

Brandon: Yes. But it's not a GraphQL schema file, it's more like a database schema file.

Brian: Thanks for the clarification. So, I just got gifted a Prisma App, an app that is leveraging Prisma and Vue.

This week or last week, so my first actual touching of Prisma 2 was literally yesterday.

I do see in Rails you had the migration file, or the migration files, but you also did have the schema file to be able to get an idea of what your app was orchestrated as.

I think they've taken some cues from that or maybe somewhere else, but it looks very familiar to me when I look at it.

So I'm curious though, one of the biggest things about Rails and the thing that I adopted really quickly because it made my life easier was just the scaffolding.

I'm curious if Blitz.js actually does any scaffolding and builds some of the files out for you?

Brandon: Yes, you guessed it. It does.

We're definitely taking a lot of inspiration from Ruby on Rails for all the scaffolding so that you can scaffold out all the code that you need end to end for a working model.

For example, you're going to run Blitz.js generate all and then a model name, let's say like "Task."

Then you can pass in the attributes, like name: strength, and then you run that and it'll generate all your Blitz.js queries and mutations.

It'll add your Prisma schema, it'll add all your pages for that, and so then you can run Blitz DB migrate and then open up your browser and you can click through and it works all the way end to end.

Brian: OK.

Brandon: Then one thing that we're doing, even beyond what Rails does, is the problem with Rails scaffolding is you don't get to choose what is scaffolded.

It's whatever Rails gives you, that's what you get. You can't really customize it, so that limits its usability over the lifetime of your project.

It's good for prototyping, but when you're building applications it's not as good.

So we will add ability to write your own templates or eject the templates, so to speak, the default ones.

Then you can customize them and even add new templates down, or customized for whatever you're building.

Brian: Excellent. I'm really intrigued on the actual framework itself, just on this space in general.

I'm seeing quite a few other, I don't know if Redwood.js comes up in conversations quite a bit.

But Redwood is another one, I think the evolution of Next.js I know it's really focused more on the front end at the moment, but there is a lot of next evolution of React applications.

So I'm curious, are you seeing this on your end or are you seeing other projects also trying to next level React as well?

Brandon: Definitely. I'm also seeing a lot of people saying that they want a Ruby on Rails for JavaScript.

They're like, "Why don't we have this? It has been so many years."

I think it's because for the first so many years of React, there was a lot of freedom and a lot of experimentation and trying all different types of things.

Now we've had time to figure out a lot of the fundamental patterns and libraries and ways to do things.

So now all the choices aren't as beneficial, like a lot of the projects we choose the same things over and over.

I think now is a good time to bundle all these things together in somewhat of an opinionated framework.

Brian: What's interesting is I didn't write Ruby Code.

We keep talking about Rails because that's our common ground at the moment.

I didn't write Ruby Code fifteen years ago to know all the different flavors of Sinatra or whatever is powering Rails at the moment.

I don't know what we came through out of that, I just knew that Rails was the way to go if you just want to get started really quickly.

I think we could debate if React is the right choice for the front end layer, I think that's a welcome debate. It's an interesting time too, as well.

Because I personally tend to-- Because I've been doing React so long, I've been doing Create React App for everything.

I haven't done a new React app in a while, but the ones I've worked on are all Create React Apps because that's what was available to me.

Then I usually choose an Apollo, because GraphQL is something that I'm highly interested in, so I will shoehorn Gra phQL into an app just so I can continue to use it.

Whether that's a good choice or a bad choice for my future development or my pain, we'll figure that out in a couple of years. But I think I agree with you.

I think we've for the most part figured out a lot of different problems and things have not become stagnated, but I think people have popularized certain tools. But what I do like about the flexibility, and why I always choose Create React App is because if I do want to make a new decision on something or try one new thing, usually it happens in the whole CSS side.

I'm a big fan of style components, but if I want to try something new or I just don't want to care about the actual design of the app or UI, I'll just grab off the shelf components to use and they make a decision for me.

I don't really care. I'll just move on or delete a bunch of CSS in the future.

So I'm curious, is there a plan for flexibility for Blitz.js?

Maybe I'm just asking for the CSS side, because that's usually the thing I change between different apps.

Brandon: Definitely we don't have any CSS libraries by default, and one of our foundational principles is loose opinions.

We have a lot of opinions, like opinions on the file structure and different things.

But most of the opinions are loose so we don't enforce most of the opinions, and then other things like styling, there's not enough consensus really to have a default.

But we will probably have various-- When we run Blitz.js new app, we'll probably add some prompts to be like "Here is the top three most common styling libraries. Do you want one of these?"

And then "If so, it'll come preinstalled for you."

Brian: OK. As you were talking I was thinking of the decisions to be made, but I also was thinking about a newer project actually that Ryan Florence, the React Router folks have shipped too, as well.

I'd mentioned Redwood.js, but also they're shipping Remix?

Brandon: Remix, yeah. It's not out yet, so all you can do is look at what they've written.

But from what I can tell it is basically the same level of Next.js, so at least as of yet they're not solving any of the database access or scaffolding, or any of the other higher-level features.

Brian: Gotcha. I mentioned that because I know Ryan comes from Ember.js world.

Years ago, back when I first was doing Ember.js, and it looks a lot like Ember.js to me as well.

I think that's what triggered that thought for me, which is the folder structure and how things interact with each other.

With the React Router folks or Reach Router, or whatever. I can't keep up on what they're working on.

Brandon: React Router is the official one.

Brian: "The official one?"OK, so React Router is very heavily into how the page interacts when you go page for page in the refresh, that's also heavily influenced in Remix from what I've watched in the videos, but also the way Ember approached that.

I believe it's heavily inspired, but one thing that I-- I didn't even finish that thought too, as well.

But what actually triggered my thought process to actually bring them up is the file structure.

A lot of times, I don't know, "Is this a component? Is it a container? Is it in this folder? Should I break all my folders into similar folders?"

I'm curious what the decision is for Blitz.js, because I haven't used it yet, of how you decide on the structure? Or, the "Loose opinion" is what you mentioned.

Brandon: Sure. The application code goes inside a top-level app folder, similar to Rails.

Then inside you have a pages folder for your Next.js pages, you have a queries folder for Blitz.js queries, a mutations folder for mutations, and then a components folder for components.

As of right now, that's the extent of our file structure opinion.

Then we have a few top-level things like integrations, but while we're here one thing to bring up that is different than Next.js that we provide is Next requires all your pages to be in one single pages folder.

But in a Blitz.js app you can have multiple pages folders all throughout your app, so you can have--

Actually, the default for Blitz.js is to have app /model name, app/another model name.

Then inside the model name you have another pages folder and queried folder and mutation folder, so you can organize all your pages by model.

Brian: OK.

Brandon: Or context, like domain context or anything.

It's up to you, but you can have pages folders all throughout your app and then at compile time we compile those down into a single pages folder for Next.js to run at runtime.

Brian: OK. Very cool. One thing we didn't actually cover too, as well.

How do I even get something like this in production? Am I making--? Am I shipping the Prisma, the data layer separately?

Am I shipping the front end separately as well, or is there a one command or one-stop shop?

Brandon: Sure. Great question. Blitz.js is deployment agnostic, so you can deploy at serverfull or server less. It's up to you.

Brian: "Serverfull," that's a new term.

Brandon: I'd like "Server"better, but anyways. You deploy it like a monolith, so everything's all together.

One code base, one deployment, and then you can deploy to Vercel or AWS or anything and it's one deployment.

You can also deploy it to things like Render.com to have it running as a server, so it's up to you.

Brian: OK. Could I deploy the API separate from the front end?

Brandon: No.

Brian: No? OK. So it's all tied together?

Brandon: Yes. It's like a monolith, but if you deploy it serverless, you don't have a lot of the constraints of a monolith.

Because the traditional monolith server, to scale it you have to duplicate the entire server to multiple instances.

But the serverless, all your pages and your queries and your mutations and everything are all their own individual functions, so those can scale automatically and independently.

You don't have the limitations of a traditional monolith.

Brian: Gotcha. It sounds like if you go the serverless route there is a bit of orchestration that has to be done, or does Blitz.js--?

Brandon: No, Blitz.js does all that for you.

Brian: Excellent. Intriguing.

Brandon: Ultimately it's Next.js that does that.

Brian: Gotcha. I know historically Vercel, previously Zeit, they did something with functions.

When I checked the site it seems like they are now focusing more on the front end.

I'm actually confused on what their focus is today, b ut are you still able to deploy a full-stack app to Vercel today?

Brandon: Yes, you still can. The official word directly from them is that they still support, they still want to be a good deployment platform for full-stack, but I agree with you that the marketing messages are confusing.

Brian: OK. We didn't even talk about the open source side, so do we have time to mention about the open source?

Like, do you have a team behind you? Also, as far as Blitz.js the company, is it a company or is it just--?

Brandon: No. It's just open source right now.

Brian: OK.

Brandon: I started it myself, but then we've had I think it's getting close to 70 other contributors so far.

There's three of us on the core team, there's a couple level two maintainers and then almost 10 level one maintainers, I think.

So we're having quite a nice little community and we're making continual progress, and that's pretty fun.

Brian: OK. Very cool. Then if someone wants to get started with Blitz.js, or even maybe contribute, what's the first step someone can take?

Brandon: Go to Blitzjs.com, we have documentation there for how to get started, documentation for how to use Blitz.js, and then we also have a "How to contribute" documentation page that goes over how you can contribute.

We definitely love anyone to contribute, we're happy to help you get started.

Brian: Awesome. Cool. I appreciate you talking about Blitz.js, but if you don't mind I want to "Blitz" us into jam picks-- Sorry, that was forced, but we'll move on.

Let's transition to the jam picks, these are things that are keeping us going, things that make us happy.

It could be technical, it could be food-related, it could be music or movie related.

With that being said, I have a pick, if you don't mind me going first.

My first pick is going to be BLK and Bold. It's a distributor for coffee and tea, but it's black-owned.

I went through a reflection period in the last couple of weeks and wanted to support black businesses and found them, so I ordered a bunch of tea from them.

I highly recommend the peach tea. It's definitely really good if you're into cold brew coffee or cold brewing tea, the peach tea is actually super excellent for cold brewing.

It adds a nice sweet taste, but there's no sugar added, obviously.

I definitely enjoyed that. BLK and Bold, if anybody's trying to search for that frantically.

Brandon: Cool. Sounds good.

Brian: When you get back to the States, I don't know if they ship to Thailand but when you get back to the States definitely check it out.

They also are now sold in Target, though I've not been to a Target in the last three months so you'll just have to take my word for it.

Then I had one other pick too, which is Octavia Butler.

She's a black author, has since passed away, but she wrote a lot of science fiction and I really like her approach to it because the science fiction is from a black perspective.

Imagine time traveling back to the 1800s as a black individual, at least in the US as well as some other countries, slavery was a thing.

So there's a book specifically which is also-- I have the graphic novel which is called Kindred, and she basically transports herself back and forth through time travel, going back to be a slave, basically.

It's interesting and eye-opening, so I highly recommend if anybody wants to see science fiction through the lens of a black author, definitely check it out. Brandon, any picks?

Brandon: Sure. My pick is Kindle Paperwhite.

Brian: Excellent.

Brandon: I feel like I'm late to the party, but I just got my very first Kindle ever a few weeks ago, and I've really been enjoying it so I'm reading way more than I was before.

It's just so easy to buy any book and read it. One thing I wasn't sure about was I like the feel of a real book, but the Kindle Paperwhite basically feels like a book.

It's totally different than reading on an iPad or something. I definitely recommend the Kindle Paperwhite.

Brian: I would use my Kindle pretty heavily when I was traveling, I have not traveled in a bit but also I love the fact that you can get any book.

Just you think of it or you see it on a shelf, like "I'll just throw it on my Kindle," instead of walking around with seven books in my suitcase.

Brandon: Exactly.

Brian: So, there we have it. Again thanks for coming on, talking about Blitz.js, talking about this full-stack React revolution that's happening at the moment and going into more details.

Hopefully listeners, you'll check out the project and contribute. Keep spreading the jam.