The Jamstack Goes Fullstack - Jamstack Seattle

Episode Description

Anthony Campolo explores the Full Stack Jamstack ecosystem, covering frameworks, databases, API meshes, and deployment services reshaping modern web development.

Episode Summary

Anthony Campolo, developer advocate at StepZen and RedwoodJS core team member, presents an overview of the Full Stack Jamstack (FSJAM) ecosystem, a movement he has been documenting through his podcast. He begins by distinguishing Full Stack Jamstack from traditional Jamstack: while the latter focuses on static files delivered via CDN, FSJAM introduces databases and server-side capabilities while preserving Jamstack principles. He traces the concept's origins to Tom Preston-Werner and RedwoodJS, then surveys adjacent frameworks like Bison, Blitz, and Wasp, noting how each approaches the full-stack problem differently. The talk pivots to Prisma as the common thread linking these frameworks, providing ORM and migration tooling essential for owning your data layer. Anthony then tours the database hosting landscape—Fauna, Supabase, Railway, Hasura, and nHost—before addressing the serverless-versus-containers debate and the cold start challenges that arise from monolithic lambda architectures. The final section covers API mesh solutions including StepZen, TakeShape, and the open-source GraphQL Mesh from The Guild, explaining how they unify multiple endpoints into a single GraphQL API. He closes by emphasizing the ecosystem's accessibility for beginners, thanks to generous free tiers and simplified workflows across dozens of combinable tools.

Chapters

00:00:00 - Introduction and the Full Stack Jamstack Concept

Anthony Campolo introduces himself and sets the stage for the talk by explaining his background as a developer advocate at StepZen and a RedwoodJS core team member. He describes how his FSJAM podcast emerged from a desire to document an ecosystem that nobody had yet bundled together into a cohesive narrative, starting when he was still a bootcamp student.

He then defines what Full Stack Jamstack means in contrast to traditional Jamstack. While standard Jamstack revolves around deploying static files to a CDN via git workflows, Full Stack Jamstack asks what happens when you add databases and servers into that paradigm. Anthony credits Tom Preston-Werner as the originator of the term and connects it to the lineage of static site generators like Jekyll and platforms like Netlify.

00:03:08 - Frameworks: Redwood, Bison, Blitz, and Wasp

Anthony surveys the emerging Full Stack Jamstack frameworks, starting with RedwoodJS and its use of React, GraphQL, and Prisma. He introduces Bison from Echobind as the first project outside Redwood to label itself Full Stack Jamstack, and discusses how it differs by offering a more opinionated boilerplate approach with pre-configured auth and deployment.

He then addresses Blitz JS, which is frequently compared to Redwood but takes a monolithic approach without an API layer between frontend and backend, making it less aligned with the decoupled Jamstack philosophy. The section closes with Wasp, a newer framework that introduces its own configuration language, hinting at infrastructure-as-code patterns that Anthony believes will become increasingly important for reproducible deployments across these frameworks.

00:06:48 - Prisma and the Database Hosting Landscape

The discussion shifts to Prisma as the foundational ORM connecting all four frameworks, providing SQL translation, migrations, and recently adding MongoDB support. Anthony explains that owning your data model and database is the key differentiator of Full Stack Jamstack projects versus those that fully outsource their backends to third-party services.

He then walks through the database hosting options available to developers. Fauna represents the early pioneer in globally distributed backends, while Supabase offers an open-source Firebase alternative built on Postgres with built-in authentication. Railway provides a more bare-bones experience supporting Postgres, MongoDB, Redis, and MySQL. Anthony highlights how each service addresses a different developer need while sharing the common goal of making database hosting as simple as Netlify made frontend deployment.

00:11:29 - GraphQL Engines, Containers, and Deployment Challenges

Anthony covers Hasura's GraphQL engine and nHost's approach of bundling Hasura with a Firebase-like experience. He then raises the emerging importance of containers in the FSJAM world, explaining how frameworks like Redwood default to serverless lambda handlers, which can create the problematic "lambda monolith" pattern with worsened cold start times.

Platforms like Fly.io and AWS App Runner are introduced as solutions for developers who need persistent servers alongside serverless functions. This section captures a pivotal tension in the ecosystem: serverless architectures offer great developer experience for getting started quickly, but real-world applications often hit scaling and performance walls that push teams toward container-based deployments.

00:14:50 - API Meshes: StepZen, TakeShape, and GraphQL Mesh

Anthony explains the challenge of stitching together multiple third-party APIs and data sources, which is where API mesh tools become essential. StepZen translates REST APIs into GraphQL schemas and consolidates them into a single endpoint, complementing frameworks like Redwood that already centralize around GraphQL.

He compares StepZen with TakeShape and introduces GraphQL Mesh from The Guild as an open-source alternative capable of handling SOAP, gRPC, and other protocols. While the managed services offer convenience, GraphQL Mesh requires self-hosting, and GraphQL Portal is mentioned as an emerging hosted option built on top of it. Anthony notes that choosing a mesh depends on what integrations are already supported and how they align with a given project's needs.

00:19:10 - Ecosystem Accessibility and Q&A

Anthony wraps up by reflecting on the full FSJAM ecosystem, emphasizing that the frameworks, libraries, and services he covered can be combined in hundreds of unique configurations. He highlights that nearly all of these tools are either open source or offer generous free tiers, making the ecosystem particularly welcoming for beginners and developers on tight budgets.

The Q&A session touches on Fly.io and The Guild, with Anthony explaining how The Guild operates as a decentralized group of developers who build open-source tools as byproducts of paid client work. He praises their community focus and consistent maintenance of critical GraphQL libraries, noting their strong presence in the GraphQL Discord helping developers directly.

Transcript

00:00:13 - Host/moderator

Today we have Anthony Campolo coming to join us to talk about some cool things. I'm not going to spoil anything. It looks like Anthony has been super busy working with Jamstack projects and being a developer advocate for StepZen and for Redwood. And I'm super excited to hear what you have to share with us tonight, Anthony. So if you want, take it away.

00:00:40 - Anthony Campolo

Awesome. Thank you so much. Hi everyone, my name is Anthony Campolo. I am a developer advocate at StepZen and I'm also on the core team for RedwoodJS. And today I'm going to be talking about the Jamstack going Full Stack, or Full Stack Jamstack. And to set some context of why I'm talking about this, I've been doing a podcast that I started about a year ago called FSJAM. And the idea with this is to explore this emerging space of different projects that are happening in the ecosystem. There's going to be a wide range of things we're going to be talking about here, from completely open source tools to completely proprietary tools and a wide range of things along that spectrum. And I have some sort of conflict of interest with like almost half of these, so just a disclaimer there. But I made a bet, kind of, on this ecosystem back when I didn't have a job. I wasn't even on the Redwood team. I was just a bootcamp student learning how to do web dev and what that meant. And I just found that it was a really interesting space and there are really interesting things happening, and it didn't seem like there was much coverage or that anyone had kind of bundled them all together into like a single kind of movement.

00:02:02 - Anthony Campolo

And this is why we kind of started talking about this as Full Stack Jamstack. And we'll talk about how that kind of differs from the Jamstack — this is a Jamstack meetup, you guys probably already have some sort of idea of what exactly the Jamstack is. It's usually delivering static files to a CDN and you do it with a git push. If you think of that kind of paradigm, what happens when you add a database to the mix or a server to the mix? That's a bit of what you get with Full Stack Jamstack. But if you really want to kind of wrap your mind around it, I think the best way to do this is to look at something like RedwoodJS. Because as far as I can tell, the first person who was really using the term Full Stack Jamstack was Tom Preston-Werner, and he's someone who's been involved with Netlify since the very beginning. Netlify themselves and the Jamstack are really based on this whole paradigm of static site generators, which was very, very heavily popularized by tools like Jekyll, which was also created by Tom Preston-Werner. And the idea was exactly what I was saying before — we want to have the same Jamstack paradigms.

00:03:08 - Anthony Campolo

And what we all love about the Jamstack, but for a full stack. So for something like Ruby on Rails or Laravel, we also wanted to do that in JavaScript. And Redwood used React, GraphQL, and Prisma. We'll talk about Prisma a little more later. But it's been building now for really close to three years, even though it doesn't kind of seem like that long from the outside, because it was worked on for a while, kind of just among Tom and Peter together for about a year, and then they worked on it publicly, but not really paying attention for another year. And that launched in March of 2020. And since then we've seen a lot of changes in the ecosystem. And what was really interesting and what first kind of inspired myself and my co-host Chris to start the podcast is when we saw this come out. This is Bison, which is from the team over at Echobind, and their CTO, Chris Ball, is the lead maintainer on this. And it says Full Stack Jamstack in the box. So this is the first time that we saw someone else creating their own thing and putting the label Full Stack Jamstack on it.

00:04:17 - Anthony Campolo

And so it then begs the question, all right, what does that mean? What is Full Stack Jamstack and what influences does it take from Redwood? What does it kind of do by itself? There's, I would say, a little bit of a blurry line here with whether Bison is a full-fledged framework or a really well-built-out boilerplate. That line could be a little bit blurry sometimes, but it's more so giving you a fully configured project with auth, with deployment and all of those things. And Redwood gives you the ability to build that out, but doesn't have as many opinions in terms of just giving you a straight boilerplate that already has it all together for you. So that's the main difference between these two things. There's also a lot, lot, lot more people working on Redwood. And Bison is very cool though, and I think other people should check it out for sure.

Something else to talk about — just for the sake of everyone comparing this to Redwood — Blitz is frequently bundled together with Redwood as this other Full Stack React framework that uses Prisma. And this is true, but it doesn't really fit into the FSJAM paradigm in the same way, because one is going for a monolithic development workflow in the sense of your front end and your backend does not have any API between it at all. So it's less Jamstack-y and it's less decoupled. But it is a React framework with Prisma, with the database and all that kind of together. So you'll frequently hear this brought into the conversation as well. But I know Brandon, he's been on the podcast three times and he does not call Blitz Full Stack Jamstack and likely never will.

So this is a newer, really interesting project called Wasp, and people are already comparing it to Redwood, but there's some very subtle, interesting differences here. Because with Wasp it's also using Prisma and React and Node, so it's a similar stack. But what it also gives you is something called the Wasp language, which is kind of like a configuration language. And this is where you get into things like infrastructure as code and GitOps and things like that. And I'm really excited for this because this is actually something that I've been talking about with these frameworks going on almost a year now, which is that it's really hard to actually deploy these things and do it consistently and reproducibly without some sort of infrastructure-as-code type layer.

00:06:48 - Anthony Campolo

So this is definitely one to watch out for. And I think we're gonna see more kind of heavy integrations with infrastructure as code with some of these frameworks. And then Prisma is the one thing that all four of these projects were using. So this is where we kind of get into the crux of what it actually means for something to be Full Stack Jamstack, and why I'm not including things like, say, CMSs in this conversation. Now, it's not to say that you can't use a headless CMS with an FSJAM project, but the idea is that you are not completely outsourcing the backend to a service. You are still building your own backend in some respect. Now, it doesn't necessarily mean you're hosting your own backend, which we'll get into after this, but you have some sort of model. You have a data model, you own the data, you have a database. And so that is the real key difference I kind of see here. And this is why Prisma is so important to this conversation. Because Prisma is an ORM that's very much like Active Record or Laravel — these types of things that do translation from your language to SQL and also does migrations to make sure your schema is always in the right place.

00:07:57 - Anthony Campolo

And it's a very, very nice developer experience and it's been building for many, many years now and has just recently started adding MongoDB support, which can make it possible to switch from SQL to NoSQL backends, which is really fascinating and shows how far this ecosystem has come. Because when this was first starting and we first started talking about this, I remember actually writing a blog post about this — like, what's the status on Mongo and Prisma? And it was just such a huge, complicated project, so many months away. And then they kept chipping away and chipping away and finally we're getting here.

But we also actually have to store our data somewhere. And this is where we get into — what I like to say is they're a little bit like trying to create a backend Netlify, because Netlify gives you a really nice UI, really nice dashboard, really nice workflow for deploying your frontend assets in the simplest possible way. And we want that for our databases as well. And Fauna has long been in this space. And if you look at early projects from a couple years ago with things like Gatsby and Netlify functions and a Fauna backend, you started to see a lot of these patterns start to emerge of how you could have your front end and your back end both on these globally distributed, almost CDN-like things, and you would stitch them together through environment variables.

00:09:21 - Anthony Campolo

And this is where we start to see this becoming more of an actual thing, because we're seeing many, many, many more ways to actually host that backend. One that I guess a lot of people here are already familiar with is Supabase. Supabase is meant to be an open-source alternative to Firebase. And this gets at the same thing of we want to actually control our backend. Even though we don't want to have to go through all the pain of configuring it and hosting it and serving it, we still want to actually have control of the data. And so building on something like Postgres instead of a proprietary Firebase database allows your data to be much more portable. And so most of the things we'll be looking at here will be doing Postgres, but not entirely. And then we also see that this gives us things like authentication as well. And that's a really key piece here, is that we are building our own backends. And if you're building your own backend, that also means you're responsible for securing that backend and for making sure that it has the right authentication, the right permissions and all that.

00:10:22 - Anthony Campolo

And that's where you bring in things like GoTrue, which is Netlify's authentication library, not a service. And then you have things like all these plugins for GitHub and Twitter. There's a lot of auth that's being built out with Supabase, and it's been cool because when they were first starting out some of the Redwood developers started building stuff with it and were like, this is really cool. And now Supabase has blown up and everyone's talking about them. So really happy to see them getting some well-deserved attention.

Myself though, personally, I host almost all of my stuff on Railway. I'm a really, really big fan of Railway because it's a lot more of a bare-bones experience than Supabase, in that it gives you the ability to spin something up really fast and access it and get some metrics on it and it's just like, do what you will with it. It's also really cool because it doesn't just give you Postgres — you can also use it with MongoDB or Redis or even MySQL. MySQL is something that I've always had the hardest time figuring out.

00:11:29 - Anthony Campolo

Like, how do you host that if you're not just doing AWS? Because Heroku ClearDB is the closest thing that I could find, but this is one of the only ways you can actually get a MySQL database, which can be really useful if that's the kind of thing you want. Both of these, though, don't really have an opinion on how you're going to access that database, versus these other options where they're giving you a GraphQL API already on top of that database. And Hasura is also using Postgres and they built out their own GraphQL engine for accessing it. And Hasura has been around for a long time and they've been kind of the backend of choice for lots of developers that were doing this before, if there was ever any such thing as FSJAM. So they're huge pioneers in the space and have done a lot of really great work, especially focusing on open source and building up their open source tooling, which is really cool. And that's enabled then other companies such as nHost to build a level on top where — this is like Supabase, it's the open-source Firebase alternative, but with GraphQL — and the way they do that is by bundling Hasura with it.

00:12:38 - Anthony Campolo

And so you already have the database set up, you already have the GraphQL API set up as well. Now the one thing though that we haven't really talked about in this talk is containers. And the reason why is because containers are not that much of a thing yet in the FSJAM world. But this is going to change very, very soon — it's kind of in the process of changing now — because projects like Redwood have been built to be serverless by default, in the sense that you are building an API that is being hosted on a lambda handler via something like Netlify functions, although you can deploy straight to Lambda if you want. And that can be really great for DX and getting it up and testing it really fast. But there's a lot of problems that come along with this, mostly because you don't actually want to shove your entire application into one single lambda handler. This is a thing that serverless people are constantly talking about — the lambda lith, or the monolithic lambda. It leads to a lot of problems because the larger your functions are, the slower they will start up.

00:13:44 - Anthony Campolo

And so the cold start problem is already a well-known problem in the serverless world. But it's exacerbated by these frameworks that have these architectures that are already leading you down the path of having a lambda lith. So you then ask the question, okay, well what if we just host these things on an actual server like we used to, and there's now going to be ways to do that very simply along with the kind of serverless functions. And Fly.io, I think, is a good example of one of these platforms that lets you host Docker containers. You can host Postgres on Docker containers, you can host all sorts of stuff here, and I'm not seeing a lot of other similar container-like services. But you're also seeing a lot of innovation here, even in just AWS with things like their App Runner. So people are in situations where they just have to have some sort of persistent server for all sorts of reasons. And having a really nice container deployment service can be a huge help there. Now we're getting into the how do we actually stitch all this stuff together?

00:14:50 - Anthony Campolo

And especially how do we bring in other third-party APIs as well. So if you do want to then include a CMS like GraphCMS or Storyblok or something like that, you would need to figure out how to hook that into your application. You do that through things like Node Fetch or GraphQL requests and make GraphQL queries from your project. But that can get really messy and very unmanageable as you have more and more endpoints that you're querying. You're bringing data from more and more places, and that's what makes API meshes and these types of things — and we're going to hear a lot more about this for Jaden's talk. StepZen and TakeShape get compared fairly frequently. Usually when I tell people that I work for StepZen, they'll ask me kind of how it compares to TakeShape. And I think me and Jaden are also in a competition to see who can speak at the most Jamstack meetups of all time. We've been at quite a few of them. I think this is probably like my sixth or seventh that I've done. And the thing you want to think about is what do you actually need to stitch together and then what capabilities does your mesh have?

00:15:52 - Anthony Campolo

So for StepZen, we give you the ability to hook directly into REST APIs and you can translate that into a GraphQL schema, and then you also can consolidate all of those schemas into one single endpoint. So you get something kind of similar to a one-graph idea, and then you are able to have a frontend that is just querying your one giant graph. And this goes really well with something like Redwood, because Redwood already gives you one giant GraphQL graph at the end of the day. So it's a cool model to kind of centralize on because it lets everyone lean into the things that make GraphQL so great, which is standardization of language and standardization of how you send queries and mutations and how you deal with variables and that sort of stuff. So this is what I spend the majority of my day-to-day work on. I'm a developer advocate at StepZen and I won't talk too much about TakeShape because Jaden will give you a whole kind of explanation of this. I believe that probably the biggest difference right now is that I don't think they do databases yet.

00:16:59 - Anthony Campolo

They said it's on the roadmap. Whereas we do a lot of databases. And the flip side is that we're still kind of getting into really connecting the different GraphQL APIs together with GraphQL directives. So when you need a mesh, you're going to want to look at what is supported in the mesh already, what's on the roadmap, how does that map with your specific kind of project. And they're both really, really fantastic services with really great teams building all sorts of cool stuff. So both are very much worth checking out for anyone who finds this stuff interesting.

Both of them though are services, and sometimes you want an open-source project for any number of reasons. And this is where GraphQL Mesh comes in. GraphQL Mesh is from The Guild, and Uri Goldshtein is really big into this and has done lots and lots of talks about it, because it is — like we've been talking about — a way to take lots and lots of different endpoints and smash them all together into one big GraphQL endpoint. GraphQL Mesh, though, is on a whole nother level in terms of the stuff you can do with it.

00:18:00 - Anthony Campolo

You can use SOAP, you can use gRPC, you can do all sorts of stuff. And things like TakeShape and StepZen are certainly capable of that. And I think you're going to continue to add more of these. It's probably just a question of who are the users, what do they want to do, and how much demand is there for these different languages at any given time. And so you can look at all of them and kind of see what they offer. But then the flip side is you would have to host your own mesh if you were using GraphQL Mesh. This is something that a friend of mine has actually done and has hosted it on PM2. And it's absolutely insane — it's a jerry-rigged kind of setup and it works, but it's not fun. And that's why you then would want to check out something like StepZen or TakeShape, or something that is interesting and I know really nothing about, but for the sake of completion is worth mentioning. GraphQL Portal is a hosted service that is building on GraphQL Mesh. So they are trying to take the open-source project of GraphQL Mesh and then build kind of a service on top of it, so you get a little more visibility into what the actual underlying tech of your mesh is, which would be a little hard to do when you're using a service that has proprietary technology.

00:19:10 - Anthony Campolo

You can't really get into the codebase. And so that's kind of always a challenge for me. And I would probably end up checking this out in a little bit, just to kind of see what it actually is like. I've talked to the founders a little bit, and they seem like a cool bunch.

So that is all of the projects. And now going back to the original FSJAM point of the podcast — talk about the frameworks, the libraries, and the services. It is all of these things together that kind of make up this larger bundle of things we call FSJAM. And among these things I've shown you, you can combine them in literally hundreds of different unique combinations of technology to build all sorts of things. Almost all of these, if they're not already open source and free, have a generous free tier. A handful of them are a couple dollars a month if you do want to use them, but those are ones that are very, very featureful. So I think that this is a really great way for beginners to get in, because it's aimed at trying to simplify these workflows and it's also aimed at doing that in a really cheap way — not getting you into a position where you accidentally deployed a Kubernetes cluster that costs $70 or something like that.

00:20:24 - Anthony Campolo

And that is really big for me as someone who came from this whole bootcamp world and who was also very, very broke when I was going to bootcamp. And it's such a crazy group of sophisticated technology that is being offered at such low prices. And this goes back to the pioneers of a lot of this stuff, which is things like Netlify and Vercel and of course Heroku, who gave you the ability to spin up these kind of hobby dev free projects that are limiting but powerful for what they're giving you for free. And once you start mixing and matching these, you'd be amazed the type of things you can start building with them. So that is pretty much my whole talk. If anyone has any questions, feel free to let me know. Happy to answer any of them.

00:21:13 - Host/moderator

Cool. That was great. Anyone have any questions for Anthony? That was so cool to see. So many things. There's a few things that I haven't heard before, like Fly.io or like the Guild thing. I didn't know that there was an open-source mesh thing that Jaden's gonna be talking more about, but open source — I didn't know that existed.

00:21:39 - Anthony Campolo

Yeah, The Guild is awesome because Uri Goldshtein was one of the original founders of Apollo. And before that he was on Meteor. So he's been on this GraphQL journey almost longer than anyone, except like probably Lee Byron and those guys. And he left Apollo, and now they call themselves a group of decentralized developers that work together in a bunch of interlocking tools. So most people who do GraphQL know about things like GraphQL Codegen and GraphQL Tools and lots of these kind of like libraries that are really common in the GraphQL ecosystem. But there's like kind of an underlying group of people that are basically maintaining all of these things. And there are a bunch of repos under their individual names, not under one group — Guild's GitHub. So it can be kind of hard to see it as a group, but they all share the same values of maintaining your open source and continuing to respond to issues and helping people actually work with the tech. You'll see a lot of these people in the GraphQL Discord, answering questions, helping people out. So it's very community focused.

00:22:46 - Anthony Campolo

It's very cool. So I'm a really, really, really big fan of The Guild.

00:22:48 - Host/moderator

That's cool. Do you know if they have support from a company or something?

00:22:54 - Anthony Campolo

So they do. They build their own tools for client projects and so that's kind of what sustains them. So the tools are a byproduct of the work they're being paid to do. They're not necessarily being paid to create the tools, but being paid to solve problems. They solve the problems by building these tools that are then open source.

00:23:12 - Host/moderator

That's cool. That's very cool.

00:23:14 - Anthony Campolo

Cool. Thanks so much for having me.

00:23:16 - Host/moderator

Cool. Thanks, Anthony.

00:23:19 - Anthony Campolo

[unclear]

Related Links

• Bringing Fullstack to the Jamstack with Tom Preston-Werner - Interview with the RedwoodJS co-creator and originator of the "Full Stack Jamstack" term cited at the start of this talk
• FSJam Roundtable with Chris Ball, Brandon Bayer, and David Price - The maintainers of Bison, Blitz.js, and Redwood discuss Prisma, serverless deployment challenges, and their frameworks' differences—directly covering three of the four frameworks surveyed in this talk
• RedwoodJS the JS App Framework - JavaScript Jam - Live demo of RedwoodJS with Railway for database hosting, covering the same GraphQL and Prisma stack described here
• Blitz.js and Fullstack React with Brandon Bayer - Deep dive on Blitz.js, the zero-API fullstack framework contrasted with Redwood's decoupled approach in this talk
• Prisma with Austin Crim - In-depth look at Prisma ORM, the common thread linking all four FSJAM frameworks discussed in this presentation