Bison with Chris Ball

Episode Description

Chris Ball, CTO of Echo Bind, discusses Bison, a full-stack Jamstack generator with built-in CI/CD, and the tech stack choices behind it.

Episode Summary

Chris Ball joins the FSJam podcast to introduce Bison, an open-source full-stack Jamstack starter that Echo Bind extracted from their real client work. The conversation opens with a look at how the remote-first consultancy operates, including their migration from Slack to Discord and the developer tools they use for pairing and collaboration. Ball then explains how Bison emerged from the team's desire to generate production-ready apps with sensible defaults already in place — not just scaffolding code, but also CI pipelines and deployment configs via GitHub Actions, something the hosts note as a distinguishing feature compared to Redwood JS and Blitz.js. The discussion moves through Bison's opinionated stack — Next.js, Prisma, Nexus, Apollo Client, Chakra UI, and React Hook Form — and Ball explains the reasoning behind each choice, emphasizing speed of delivery and the ability to swap pieces out when needed. The team's preference for Prisma over TypeORM, Postgres over other databases, and Nexus over a traditional Apollo Server setup are each explored in practical terms. The episode closes with a look at Bison's roadmap, including a forthcoming CLI upgrade process and a more flexible project wizard, plus a plug for open roles at Echo Bind.

Chapters

00:00:00 - Introducing Echo Bind and Remote Work Setup

Chris Ball introduces Echo Bind, a remote-first consultancy that builds web and mobile apps for clients ranging from two-person startups to large healthcare companies. He explains how the team of around 20 gives developers dedicated investment time each week to explore new technologies and propose workflow improvements.

The conversation shifts to the tools Echo Bind uses for remote collaboration. Ball describes their migration from Slack to Discord, the appeal of Discord's audio channels for spontaneous pairing, and the team's interest in tools like Tuple and VS Code Live Share. The hosts share their own experience with Discord bots for scheduling, time zones, and GitHub changelogs, setting up a broader discussion about Discord's growing role in developer workflows beyond open-source communities.

00:05:23 - Discord Bots, Webhooks, and the Slack Migration

The group discusses the practical challenges and benefits of Discord bots, including data privacy concerns and the appeal of writing custom bots in JavaScript. Ball notes that Discord's support for Slack-compatible webhooks eased some of the migration, though deeper integrations still require custom work.

Anthony highlights that while many open-source communities have adopted Discord, it remains unusual for companies to make the switch from Slack. The conversation touches on how organizations surface work across channels and the broader difficulty of understanding how remote teams actually coordinate day to day, setting the stage for the main technical discussion about Bison.

00:08:22 - What Is Bison and Where Did It Come From?

Ball explains that Bison is a full-stack Jamstack generator designed to produce production-ready apps with CI, deployment, and sensible defaults already configured. Unlike projects conceived as frameworks from scratch, Bison was extracted from real patterns Echo Bind had assembled manually across client projects, starting around the time Next.js introduced API routes.

Anthony provides historical context by comparing Bison's origin story to those of Redwood JS and Blitz.js, noting that all three emerged around the same period but from different starting points. The hosts emphasize that Bison's inclusion of CI/CD opinions — specifically GitHub Actions configs generated alongside the app — represents a layer of practical sophistication the other frameworks hadn't addressed, making it a distinctly operations-aware tool.

00:15:14 - GitHub Actions, CI as Code, and Deployment Defaults

Ball walks through how Bison generates GitHub Actions YAML configs so that tests run automatically from the first push. He describes how the setup handles common pain points like spinning up test databases and running end-to-end tests, removing decisions developers would otherwise have to make from scratch each time.

Anthony draws a connection between this approach and the broader infrastructure-as-code movement, asking about Terraform and CloudFormation. Ball explains that Bison keeps complexity low by piggybacking on existing GitHub Actions for deploying to Vercel or Heroku, using conditional logic in the YAML based on choices made during the initial project wizard. The discussion highlights how these defaults can evolve as a project's needs change.

00:19:33 - Stack Choices: Abstraction Philosophy and Chakra UI

The hosts explore how Bison relates to its individual pieces — Nexus, Chakra, Next.js, and React Hook Form — and whether developers who know those tools already effectively know Bison. Ball clarifies that Bison avoids wrapping libraries with custom abstractions, instead generating standard code that uses each tool directly, making it easy to swap components by updating generator templates.

The conversation turns to why Chakra UI was chosen over Tailwind or Bootstrap. Ball values Chakra's ready-made accessible components as a productivity default, while acknowledging that no CSS choice is permanent. The hosts debate whether standardized-looking websites are actually a problem, with Anthony arguing that most users care about clarity and function rather than visual uniqueness, especially for early-stage products.

00:28:00 - GraphQL Tooling: From Apollo Server to Nexus and Prisma

Ball explains that Bison originally used Apollo Server and Client before switching to Nexus after adopting Prisma. Nexus's ability to open up CRUD operations and deep relational queries with minimal code was a major draw, and the fact that it generates a standard GraphQL schema provides an escape hatch back to a traditional Apollo setup if needed.

The discussion then covers why Echo Bind chose Prisma over TypeORM and Sequelize, citing Prisma's schema-first approach, its pleasant API, and concerns about TypeORM's stalled version roadmap. Ball shares that Postgres has been the team's default database for years, carried over from their Rails days, and that while they're open to options like DynamoDB, relational databases suit most of their projects.

00:36:45 - ESLint, Bison's Roadmap, and Echo Bind Hiring

The group briefly discusses Bison's bundled ESLint plugin, which Ball says will become an optional recommended config rather than a requirement, acknowledging that developers have strong opinions about code style enforcement. The hosts note that adopting linting rules mid-project is far more painful than starting with them.

Ball outlines Bison's roadmap, including a CLI upgrade process and a more flexible project wizard inspired by AWS Amplify that would let developers pick and choose stack components — including different databases and deployment targets — while still getting generated CI and deployment configs. The episode wraps with a plug for Echo Bind's open roles in React Native, React, Node, TypeScript, design, and account strategy, all fully remote.

Transcript

00:00:00 - Christopher Burns

I wonder how Twitter does the swap over of POTUS. Do you think they have a cron job? POTUS to POTUS 45 and swap all the accounts over? Or do you think it's one person editing them all?

00:00:17 - Anthony Campolo

It's just POTUS increment one, right? Or plus? Plus POTUS. Awesome, get right into it.

We got a bunch of stuff to talk about. All right. Welcome to the FSJam podcast, Chris. We're really happy to have you. I'm going to refer to the other Chris as Bernzy in this episode, just so we don't get confused. I usually call Bernzy actual Chris, but now we got two Chrises here, so this might get a little nutty. But why don't you tell people who you are and what you're working on? You are the CTO of Echo Bind, so I'd love to hear a little bit about what Echo Bind is and what stuff you guys are doing.

00:01:00 - Chris Ball

So first of all, Echo Bind is a consultancy, and we help clients build web and mobile apps. Right now we're really big on the mobile side of that coin, but it flips back and forth. So we do a lot of web, which is how we got into the Jamstack and full-stack Jamstack.

We're kind of dispersed throughout the US, and from day one we've always been remote. That kind of helped us when this whole corona thing kicked off.

We have lots of different clients we work with. We work with a lot of healthcare companies. We are currently getting into a lot of food delivery apps, which is really interesting.

What I like about what we do is we work with two-person startups up to really large healthcare companies and large corporations. So it's nice to have not only different industries that you work with, but different sizes of companies and all of those types of things, because you bring the learnings back to everyone else.

00:01:48 - Christopher Burns

So how many people work at Echo Bind?

00:01:50 - Chris Ball

So we are back to 20 at the moment. We're also hiring right now, so we're in a really nice period of growth, kind of kicking off the year. That's been both good and bad — great from a company standpoint, bad from an open-source time standpoint — but it's really nice.

We're pretty developer heavy. We've gotten more into design in the past few years, but we started primarily as a developer-focused agency. That's still the core of most of our team. Then we have some account strategists that lead projects, and we also have some people running operations and things.

00:02:24 - Anthony Campolo

Do you have a developer advocate division or people doing content creation or outreach, or any of that kind of stuff indirectly?

00:02:31 - Chris Ball

So that's an area. With all of our folks, we give investment time. We don't work on client work the entire week. Up to eight hours, kind of a full day for some people, is dedicated. For some people, that's spread throughout the week, but it gives them a chance to level up their skills on a new tech they might have to work with or do a spike for something where they're like, "Hey, I've always wondered if this is a good path to go," or propose differences in workflows and things like that.

00:02:59 - Christopher Burns

As you say, you're distributed across the country. It's a really interesting conversation, and I've been working these out myself because we hired a developer who lives in LA and we are based in Britain. Could you just talk through some of the development tools you use to keep your devs in sync?

00:03:20 - Chris Ball

Yeah, we have migrated from Slack to Discord. A lot of open source communities are on Discord now, and we decided to as well. A big one for us has always been pairing. Screen Hero was great back in the day. Slack had calling for a little while. That was a failed experiment because they bought Screen Hero, and that whole thing ended up way worse than anyone thought it would.

00:03:40 - Anthony Campolo

Have you tried Tuple?

00:03:42 - Chris Ball

That's been on our list to try, keeping a close eye on it for sure. The one thing we haven't really figured out yet with that particular product is it's focused on pairing, but it's not focused on group pairing as far as I know. I don't know if that's on the roadmap or not.

00:03:56 - Anthony Campolo

One person's screen. So if you're calling into someone and need to see their screen, that kind of thing.

00:04:02 - Chris Ball

And it's really great for that. But one thing that is kind of nice that we like is we have audio channels set up in Discord, and you can just see people in them. So if you have some downtime, you're like, "Oh, what's this person doing?" You just hop right in. It's a little bit of a different workflow. But I love the tech. I know a lot of the folks behind that product, and it looks really great.

00:04:20 - Christopher Burns

One of the actually interesting ones we've tried is Visual Studio Code's Live Share. That's it. That's mental. If you've not tried that, we have.

00:04:35 - Chris Ball

Yeah, it's great. We have a couple people that don't use VS Code that we keep trying to push to it, just because the tooling is so nice and eventually Microsoft is going to take over everything. But that's been really solid as well.

00:04:47 - Christopher Burns

So you use chat via Discord. I guess you use GitHub.

00:04:52 - Chris Ball

GitHub is a big one. Clubhouse is what we use for all of our project management and running that whole workflow. This is not the social Clubhouse that's floating around at the moment. This is clubhouse.io, just to be clear.

00:05:05 - Christopher Burns

The clubhouse.

00:05:07 - Chris Ball

The clubhouse. Exactly. It's funny because we've used that for a little while, and when I first heard people talking about this new Clubhouse thing, I was like, "Wait, what? You're joining this community and it's for project management?" I don't understand it. I'm the old guy in the room.

00:05:23 - Christopher Burns

I guess my last question is, do you have any Discord bots set up? Because this is a whole interesting thing about JavaScript: Discord bots. There are thousands of them now.

00:05:37 - Chris Ball

Yeah. So here's the interesting thing about that. You don't know what they're doing with your data. It's one of those things where it should be fine, but you don't know. I mean, who knows? Most of those, you give full access to your server, and they're listening to every message that's there. I'm not usually the tin foil hat type, but you don't know, right?

So we definitely consider writing our own because Discord does make it really nice to write bots yourself in JavaScript. It's been a good platform for that.

00:06:05 - Anthony Campolo

You're saying that self-hosted Discord is a startup idea?

00:06:10 - Chris Ball

Yeah. It'd be interesting to be able to plug into almost like in Heroku, if you've seen that, the add-ons that you have there. It's just like, "Hey, I want to add this thing and this thing and this thing," but it's all sort of your hosted stuff. That'd be interesting.

00:06:23 - Christopher Burns

Three Discord bots we have: one called [unclear].

00:06:31 - Anthony Campolo

Yeah, we're using that in the React podcast Discord. Ben has taught us a lot about how to use that.

00:06:36 - Christopher Burns

To help do meetings. So you can say, like, "Do a meeting in two hours," and people can click attend. Time Zone Bot too, obviously: when you add someone, it tells you what time zone they're in, and also one called [unclear]. The GitHub bot that basically you attach to your read-only GitHub events, and then it will produce a changelog for you in Discord.

It's an interesting one because Discord is not like enterprise work product, but it's slowly just become like, "This is cooler than Slack now," slowly migrating everything over.

00:07:17 - Chris Ball

They did the smart thing, I think, where they allowed Slack-compatible webhooks. If a company just has a Slack webhook, then you can reuse it. But if they don't and they have this deep Slack integration, it's like, crap, that doesn't work. So now we have to write it. That's been a little bit of a point of contention for us, but we're figuring it out.

00:07:36 - Anthony Campolo

Interesting. So they have to figure out how to get people to migrate from Slack to Discord, because the fact that you guys did that is actually a little surprising to me. I have seen, as you say, a lot of developer communities using Discord and a lot of open source projects using Discord. I don't see as many companies doing it. They all still seem to have stuck with Slack for the most part, but I do think that could potentially change. And the fact that you all have done that, I think is really interesting.

Is there anything else you want to talk about in terms of that kind of stuff, Chris, before we get into the Bison chunk?

00:08:12 - Chris Ball

Not really. It's just making sure that we're surfacing everything we do. All of these things send notifications to various channels, and everybody's looped in.

00:08:22 - Christopher Burns

No, it's just super interesting. It's sometimes hard to know how organizations are managed when it comes to code, because that's one area that, with remote work, everybody's like, "Yeah, we're remote working," but they never say how they're remote working or how well they're doing it.

Yeah, we're here to speak about Bison and what Bison has been up to and how it is a unique, I would say, middle ground between Redwood JS and Blitz.js. We're going to have some spicy opinions for sure on things like Nexus, so let's get into it. Where should we start?

00:09:05 - Anthony Campolo

Well, before I do this, let's first set the stage of what Bison is because we have had you on the show. You're here for our roundtable. This is the first time you've really gotten a chance to speak and give the high-level explanation of what Bison is. I've spent a lot of time telling everyone I can possibly get to listen to me about Bison. I think it is so cool, and it is just an awesome project. I've enjoyed poking around through the codebase and trying to wrap my mind around it. I'm getting there slowly but surely.

So I've got a bunch of questions, but first let's just say: what is Bison, and where did Bison come from?

00:09:40 - Chris Ball

So basically what we wanted to do is provide an ability, like you've seen a lot of boilerplate-type projects. The first step in this is generate me a new app in a way that I don't have to think about a lot of things. But we decided to take it further than that: let's also think about CI and let's think about deployment. It's not just "let's start off a new project," but let's start off a new project with a lot of these things that everyone wants to think about already there. You can deviate from them should you need to, but the idea is, "Hey, here's some good defaults that have been working for us along the way." So that's part of what it is.

We said Jamstack in a box; it's full-stack Jamstack in a box because we care about the database and the API side of things, as this podcast does.

[00:10:27] The other piece of this is how it came about. We've been thinking in this space for a while. I don't actually remember when we first started doing it, but essentially it's when we realized that Next.js by itself had API routes. So could we, especially to start with as an experiment, take one of these? Sort of like I mentioned, we work with two-person startups, and there's a certain level of potential risk that those clients could take on, provided that it's still a good decision to do so.

It's not like, "Hey, we want to just try this crazy, outlandish thing," but we've used our investment time and spiked some stuff out, and this seems like a very, very good path to go down. This was before I even knew that full-stack Jamstack was even a term, because I don't think it was around, but I had heard it was kind of around the same time of Blitz and Redwood.

[00:11:21] I think most of those projects were announced not terribly far apart from what I remember.

00:11:26 - Anthony Campolo

Yeah. Just to give the timeline real quick, Redwood was worked on kind of in the background with no one paying attention to it from June 2019 to March 2020, and then March 2020 is when they announced it, whereas Blitz was announced in February, but it was announced from Ground Zero and hadn't been built at all. So Redwood had been building for much longer. But if you saw the quote-unquote big announcements, it seemed like Blitz came first. So it's a little bit of a confused history there, but that's the timeline.

00:11:55 - Chris Ball

Good to know. So yeah, we were kind of doing this background development too. We were trying to figure out what this space could look like. We started doing a few applications with it and started evolving those pieces over time.

We were trying to optimize for speed. We want to be able to deliver something as quickly as we can that's still production ready, can scale, and works really well. But where are some areas that we don't have to waste time on? When we talk about why Nexus is in there as a default, we'll probably get more into that. That was one of the guiding lights. But then it was also, "Hey, I see these other things that seem to look like an overall community, similar but different takes on things. So let's get our opinions in that mix too." Whether or not anyone cares, we'll see.

[00:12:44] But I think it's important, especially in the earlier stages of communities, to get as many ideas around as we can and then start to converge on what makes the most sense. That was the real reason why it was like, "You know what, let's actually just open source this thing and see what we can do."

00:13:00 - Anthony Campolo

Yeah, it's really cool. And I'm really glad you did because I saw it when it was first announced. I think it was August when you did the big release for it, and I wrote a blog post about it and we talked about this on the FSJam roundtable episode.

For me, what I found really interesting is that you're able to separate the stack into categories that each of the three had an opinion on. Each of them had an opinion on CSS, even if that opinion was "we don't have an opinion on CSS." Then they each had an opinion on how do we do GraphQL or "I don't do GraphQL." Then they each had an opinion on what's the database. They all picked Prisma, which I found really interesting. That ended up being the one kind of unifying layer I found between all of them. I think Prisma was essentially the only one, and then React. React and Prisma are kind of the only main unifying things, I think, that run throughout all of them.

[00:13:54] Everything else, there are differences in the stack, but like you say, they're all full stack. But what I want to hone in on is the CI stuff, because this is something that was the first thing that I found interesting and different. I wasn't able to fit it into the stack that I'm talking about here. You had all the pieces of the stack, but the CI stuff was a meta layer. It wasn't the stack; it was how the stack is actually being deployed. That's a whole different question at the end of the day.

So the fact that you had opinions on that and the others didn't was like, okay, this is actually a level of sophistication that the other ones aren't even close to. That's why I found it really interesting. And hearing the history of it, it made sense that it was more extracted than the other two, because the other two... people always talk about whether a framework is abstracted out of a real thing, or it's thought up out of the brain of some quote-unquote genius architect person.

[00:14:47] And so really, Redwood and Blitz, they're both based on developers who've had real experience and built real projects, but they are, at the end of the day, things that just kind of got thought up and they're like, "This is how I would want to structure this thing." Whereas it sounds like Bison was actually extracted from a real tool you were using to build real client projects. You think that's accurate?

00:15:06 - Chris Ball

Yeah. Essentially it's stuff that we had just put together manually, including how do we deploy the app and packaging that up.

00:15:14 - Anthony Campolo

So let's get into that. Is it GitHub Actions is how you do it? And it's a big YAML file that is all the actual actions? Like that's what it is, right, at a base level?

00:15:25 - Chris Ball

Yeah. This wasn't even a thing before. Typically in the past we'd use CircleCI as our go-to. But even when we're doing React Native apps, we're now using GitHub Actions.

00:15:35 - Anthony Campolo

And with CircleCI, is it also defined in a YAML file? Is it also code?

00:15:40 - Chris Ball

It's very much the same idea where you have the CircleCI config that has a YAML. What you write in the YAML is going to be different for sure. But what's really beautiful about having it in GitHub is it's right alongside the code. As soon as you open up a pull request, you can see all of these things that are just there.

By having the ability to do it with GitHub Actions, it allowed the app to get generated with the configs already there. As soon as you push the first branch from that repository, you should get tests running. There might be some things that you need to still address to make that work.

What's interesting, I think, is that typically when you go to set up CI, at least from the apps that I've done previously, it's always this thing of like, "Okay, we have to start the API, we have to start the front end." Especially thinking about end-to-end tests and how do you run those and how do you deal with a database that's actually just a test database.

[00:16:33] There's all these ways you can approach it. So just trying to take that question off the table: it's there. If you want to change it, you can. But by default, you don't have to go through that whole mess of figuring out how the database works and how you spin it up in memory.

00:16:49 - Anthony Campolo

Yeah, to me, this is very connected to this whole idea of infrastructure as code and that you can define your infrastructure as artifacts within your code. Because this is the same idea, except this is CI as code to a certain extent. And the two are very intertwined because the CI is for the infrastructure.

So you're really thinking about the actual steps that are required to deploy, not necessarily the assets or the resources that are being deployed to. Do you have any sort of infrastructure-as-code opinion in terms of Bison or the stuff you do? Do you use Terraform or CloudFormation or any of that kind of stuff?

00:17:30 - Chris Ball

We typically don't, just because we try to keep complexity as low as we can to start. Some of our larger clients have definitely used that type of stuff, but I think here the thing was to... I mean, we're piggybacking on other GitHub Actions as well. If you look at how we're deploying to Vercel or how we're deploying to Heroku and the other potential options, it's basically just if statements within that YAML we just talked about that are saying, "If you chose this from the wizard at the beginning, this is the action that's going to be your deploy action."

Then as the app changes, it's like, well, that may not fit anymore. So now we might need to add our own in there. Maybe we write our own GitHub Action that eventually calls this thing or something like that. I don't think this was as in-depth as mentioned.

00:18:14 - Anthony Campolo

So yeah, no, I didn't think it was. That's why I was curious because I don't think it's necessary for every project.

What I find interesting is that with something like CloudFormation, you can define a very minimal stack. You can just say, "I want an S3 bucket," and that's it, and you can have a CloudFormation template that's just a couple dozen lines. So I'm thinking of starting from there and building out more and more complex things from there.

To me, that seems like the smartest base to build from because it's mapped to actual real physical infrastructure somewhere in the world. That's probably what makes all this so confusing, is that so much of our stuff is getting deployed to the cloud. What is the cloud? Where is your cloud? Your cloud is somewhere, whether you realize it or not, so you should probably know where it is and how far away it is from you and all that stuff.

[00:19:05] And if your cloud is made up of a bunch of different things talking to each other in different parts of the world, all this stuff is just so important, and it's getting so hidden in all the layers of abstraction. That's why I like infrastructure as code, because it's like, "Here, I have this bucket in this part of the world." It's at least simple and declarative in a way that is physical and a declarative way of declaring the reality.

00:19:30 - Chris Ball

Yeah, absolutely.

00:19:31 - Anthony Campolo

But yeah. Anyway, you want to hop in here with anything?

00:19:33 - Christopher Burns

Bernzy, how far have I missed?

00:19:37 - Anthony Campolo

Basically, we lined up what Bison is, and we talked about all the CI stuff. How much have you looked at Bison, Bernzy?

00:19:44 - Christopher Burns

Quite a bit, but indirectly. I've used Nexus, I've used Chakra, I've used Next. I've used React Hook Form.

00:19:56 - Anthony Campolo

So you've used all the pieces that made up Bison, but you haven't ever used Bison, is what you're saying?

00:20:01 - Christopher Burns

Yeah. No.

00:20:02 - Chris Ball

That brings up an interesting thing, actually. We've had this internal discussion of, "Is this a Bison app, or is it just all this stuff that you're already familiar with?" It's actually interesting that it changes the way you approach it. We actually had some people on our team say, "Well, I've never made a Bison app. I haven't had a chance to do this yet, so I don't necessarily know what to do." And it's like, well, you have used all the pieces or at least some of the pieces, and so that gives you some immediate comfort and reduces your learning curve.

00:20:34 - Christopher Burns

When you use all these pieces, do you abstract them or do you just add on to them? For example, with Redwood and Redwood forms, they abstract over React Hook Form. I don't like that abstraction personally. I like raw React Hook Form, so I choose not to use that part. Does Bison abstract over or add on?

00:21:02 - Chris Ball

The only thing I think that we were trying to help with was the configuration in Nexus and those things. I've spent more time than I care to admit getting that correct. So that aspect, more of the config and setup stuff, yes. But in terms of wrapping other libraries, no.

The goal there is, at the moment, it's all generated. Take React Hook Form, for example. If you run a generator in this project, it's going to generate it with React Hook Form. Those are going to be the imports. The actual page that is rendered, or the component, is going to have the typical React Hook Form stuff in it. And if you ever want to change that, you basically can remove it from package.json and update your generator templates, which are right in the project, so you don't have to hunt down how this thing is going to generate. It's all right there in the root.

[00:21:55] That's another area that I think has been really nice for us. I know a lot of people are doing generator pieces, but talking about bringing it to different teams and evolving it, that's an area that I think is good too. But I think it's important to not abstract too much. There are certain things where you hit the wall frequently and you get enough pain. It's like, okay, this needs to be an abstraction and we need to not have people deal with it.

00:22:22 - Christopher Burns

Why did you pick things like Chakra over Bootstrap or Tailwind? Was it just a design choice in the agency, or was it more that it has everything we need at this stage?

00:22:39 - Chris Ball

We were previously, before moving to Chakra, using styled-components, basically doing a lot of what that provided us manually. It was a question again of what's our default. What can we start with and then move forward from there.

So being able to start with a similar idea to why you would choose to use Bootstrap or Tailwind. Same idea of we need a good base, and we need to build from that. We don't need to write for every single project, "Let's go make an input component," because chances are that's going to look almost exactly the same every single time.

We basically picked what we had been using. Will it be Chakra forever? No.

00:23:20 - Anthony Campolo

Chakra does have a focus on accessibility that I think is really cool. This is something that I don't see as much with other CSS frameworks. I don't think other CSS frameworks are necessarily worse at it than anything else in this whole ecosystem. But I think in terms of actually making it a priority, making it into the framework and the documentation, Chakra is one of the few that I've seen that has done that.

00:23:40 - Christopher Burns

One of the things that I think is really under thought about is that when you come to picking something like Chakra or Tailwind, one of the things that is so different is Chakra gives you a button component that you can then customize. Tailwind gives you class names. You still need to build your own component. Then you need to pass props, type your props if you want to do all of the accessibility on top of that, and then standardize it between multiple libraries. That's probably one of the big selling points of Chakra to me personally, is my button component is already defined for me.

00:24:32 - Chris Ball

Yeah, I totally agree. That's the thing that you're just going to end up defining yourself. It's one of those preference things, right? Just like CSS in general is a preference thing. A lot of React developers like it, but there are certainly multiple ways to go about it. I'm on the same page as you, though, as a personal opinion.

00:24:50 - Christopher Burns

The thing that we're seeing with Tailwind a lot, I don't know if you see this with Chakra as you're more in line with that. A lot of the products that we see coming up right now, you can instantly tell that Tailwind, like it's almost like you could instantly tell a Bootstrap framework, and now you can instantly tell a Tailwind framework. Can you instantly tell Chakra off the top of your head?

00:25:14 - Chris Ball

They're actually kind of similar looking, which makes it hard. But yeah, I think so. I can't say I've actually sat down and had that thought, but I feel like it definitely has a look.

00:25:26 - Anthony Campolo

I have very strong opinions about this. To me, when people talk about this and say all these websites look the same, that is from the eye of a developer or a website designer. You are a very special breed of person in this universe that represents like 1% of all people in the world. When everyone else sees that website, they see a normal-looking website that has the information they want to see on that website.

People don't go to websites to have aesthetic experiences. They go to websites to get information or to complete a task. If your website puts the information in a way that's clean, easy to understand, is in all the right places, makes sense, is familiar, those are all good things. Those are great things for your site to have.

Standardization is like... look at our podcast website. Every Transistor website looks the same, and that means every Transistor website looks good.

00:26:18 - Chris Ball

No, it's a good point. Especially if you're talking about 0 to 1 of a product. Should you waste time having a fully customized UI that looks absolutely amazing? Is that the biggest value for your users? The answer almost always is no. If you have unlimited runway for that 0 to 1, then maybe you could make that argument. But generally speaking, especially when we're scoping out projects, it's like, is that something we should focus on? If we just start with really good defaults and move forward from there, then great.

Another one we're looking at actually is Base Web, so that's also in this conversation.

00:26:53 - Anthony Campolo

Yeah, I have no idea what that is. What is that?

00:26:55 - Chris Ball

I had not heard of it. Hopefully I'm not wrong on the history here, but it was abstracted out of Uber. I think Uber is kind of running part of the project along with some other companies. It's supposed to provide similar accessibility in mind there. It's a little bit less of a default look, I think, and it's a little bit more flexible. So the downsides of that are part of what we just talked about.

00:27:19 - Anthony Campolo

It says it's built on top of a CSS-in-JS engine.

00:27:22 - Chris Ball

That's one that we're just kind of looking at as well, because there are some projects where if you have to significantly override what Chakra gives you out of the box, you're suddenly adding a bunch of CSS and then it's like, well, where do you draw the line? Maybe in some cases it's better to start with less and build up from it. But generally speaking.

00:27:43 - Anthony Campolo

Yeah, I would definitely check this out because Prometheus came out of Uber, which has become the de facto monitoring tool for a lot of people. So there's some really serious open source that has come out of Uber. I'd be interested to check that out.

They have a cool website, but let's get into the GraphQL stuff here. This is a huge ecosystem of tools and things to choose from. We talked about this a little bit on the roundtable episode. You guys have Nexus, which is kind of your server component, and then you have Apollo Client, which is the client component. So how did you evaluate those two tools against whatever else was available in the ecosystem?

00:28:25 - Chris Ball

Before we opted into Nexus, we actually had Apollo Server and Apollo Client, much like what I believe Redwood is doing. You're defining those in the typical fashion where you're defining your schema and your resolvers in separate places, typically, and a lot of times duplicating some code.

The reason that we moved away from that specifically to Nexus is because we had already opted into Prisma. That was step one. Now that we were in Prisma and had this really nice way of querying things and operating on databases, which before that we had used TypeORM, we decided to look at Nexus.

One of the biggest things, for example, is you open up... they call CRUD kind of CRUD endpoints. When you open up your typical "I need people to do CRUD operations here," they made that a one-liner. And what's interesting is you have hooks for authorization on each thing.

[00:29:25] You have the ability to deeply query related records by default. You don't always want that, but as a default step, it's really nice. For example, we've had times in the past where we were bikeshedding on how should we expose the where clause. If you're saying, "Find me all users where this person's company has a name sort of like this," to be able to open that up with one line as a default is really great.

Of course, you have to remember admin permissions and make sure you're authorizing things and everything else on top of that. But as that guiding thing of how can we deliver value quicker, that was one of the reasons why. And the comfort was, should we ever need to migrate away from it, which people might want to do right away if they are completely opposed to this, you get a generated schema that you can then just move into your Apollo schema and go more the traditional route.

[00:30:22] It would require some code refactoring and moving some stuff around, but it's not a terrible change should you need to unwind it. That was the main reasoning because we'd opted into Prisma, and because it provided a lot out of the box that we could, again, in the same way we just said about Chakra, get some really good defaults that we then build on.

00:30:41 - Anthony Campolo

I would actually like to know why you went with Prisma over TypeORM, because this is something that I hear when I talk to people who are not in the JavaScript world. They're like, "Why doesn't JavaScript have any good ORMs?" Prisma seems to have been one that a lot of people in JavaScript have started to really love. But I do know a lot of people who've used TypeORM. I know some people use Sequelize, I know some people have used Bookshelf. So I do think that over the last couple of years it has gotten a little bit better. But I'd be curious what your experience with TypeORM was and why you ended up moving away from it.

00:31:15 - Chris Ball

So I think TypeORM is a good project. It's not that I'm saying you should never use it by any means. It works. I know it's built into Nest. It works really well, so you can still use it. It's a little bit different. We like the schema-first approach that Prisma had. Some of the ways that you query things worked out really well. Part of it was a feel thing; the API to Prisma just feels nice.

Part of it was that it felt like a slight departure into making ourselves more class-based, with the shift being more functional and smaller sort of services on the server side. It felt like a less forward-thinking way to do it. I don't want to say it was outdated by any means because it's not. But in terms of general alignment, it just felt different.

I don't remember the specifics, but there are two other things that stuck out in my mind.

[00:32:11] One being the fact that there was this huge gap of version. I don't remember if it was version two or the next big version of TypeORM, and all the problems that they needed to solve to get to that next version. The timeline seemed to be sort of indefinite, like we don't know if they're going to actually go that route. To be honest with you, I haven't looked into it in a number of months, so I don't know if that's changed. But that was one of the things that we said: in terms of buying into something, you want something to be updated and an active project that's moving along with everything else.

00:32:45 - Anthony Campolo

Yeah. Have some sort of forward momentum to it, even if it's not like we're going to be a whole new kind of ORM. At least there are always things to improve, bugs to fix, and new features people want.

00:32:56 - Chris Ball

Totally. For us, Sequelize, the reason we didn't use that to start was because it did not have good TypeScript support at the time, so that's why we went to TypeORM. Now I hear it does, but I don't have any other input on it yet.

00:33:08 - Christopher Burns

Have you heard of TypeGraphQL?

00:33:11 - Chris Ball

I have heard of it, yeah.

00:33:12 - Anthony Campolo

I don't know anything about it. It's another one I think is kind of like TypeORM, but also really good for GraphQL too. I don't know. When I heard about it, I was like, "Conceptually, that sounds super interesting." But yeah, I don't know a single thing about it. There's way too many tools to learn.

00:33:27 - Chris Ball

Yeah, like that and Hasura and things where it's like they're taking the API layer sort of out of the equation a little bit. Conceptually, it's almost like not overly different from some of the stuff that the Blitz project is doing, where it's like we're generating this thing for you and you're leveraging it even if you have no idea what it is. Kind of interesting.

00:33:48 - Christopher Burns

If the default platform to host on is Vercel, where would you normally provision databases at this stage?

00:33:57 - Chris Ball

It changes. We've done them on Heroku, we've done them on DigitalOcean. I'd say those are our most common spots. There's some stuff with connection pooling that doesn't work correctly on Heroku. I have no idea when that will be solved, if ever. And yeah, I think those are usually the two platforms that we mainly use for data.

00:34:17 - Anthony Campolo

And is it always Postgres? Not MySQL?

00:34:20 - Chris Ball

Always. Always Postgres. Yeah. So we usually do Postgres and then add GraphQL on top of it. We've used Postgres for years, way back when a lot of our people were Rails developers and companies kind of started around that type of stuff. Postgres was just a nice default that we learned from that.

We're always exploring the other options. It's just the tried and true. I really like Postgres, honestly. It takes a lot to convince me not to use it. Certain projects, you can argue that a serverless graph database is more appropriate. But most typical projects, I would say, are relational for the most part anyway.

00:35:01 - Anthony Campolo

What about DynamoDB here? Mess around with that at all?

00:35:04 - Chris Ball

Me personally, I haven't done much. I played around with it, I think. I know some people on our team have dove pretty deep into AWS.

00:35:14 - Anthony Campolo

Yeah. DynamoDB is a whole thing. What's cool is AWS has a very complicated history because they wrote a paper called the Dynamo Paper, and it was the database they built for Amazon's shopping cart. It has to be ridiculously scalable, so they had to invent a whole new kind of database to do it.

After that paper was put out, Cassandra was created and was based on that paper. When Amazon created the DynamoDB service, it was based on Cassandra's API. So it ended up being kind of levels of indirection between what we're using today, which is kind of like a version of Cassandra that was envisioned from the Dynamo paper that first came out, which is super cool. But anyway, it's just a key-value store document database kind of thing. You can do a lot of stuff with foreign keys and things like that to model it in a relational way.

[00:36:09] So if you're willing to spend a little time to figure out how it works and how to use it, you can get it to do basically all the things you'd want to do with a relational database and never have to worry about sharding. That's kind of the promise.

00:36:22 - Chris Ball

That's definitely on our list. We use an RFC process with everything that we do. Here's Bison as it stands today, and here's some workflow things that we do. Anyone on the team with ideas, let's say that was one you wanted to run with, and I know there are people on our team that want to run with that. So we propose that, talk through it, and figure out how we can adapt going forward because there are definitely some great arguments.

00:36:45 - Christopher Burns

It's interesting that you even have your own ESLint plugin.

00:36:50 - Chris Ball

Yeah, that one is going to become optional. Don't worry about that.

00:36:55 - Christopher Burns

Would you say your ESLint is strict?

00:36:58 - Chris Ball

I don't know. I can't say. It feels normal to me.

00:37:02 - Anthony Campolo

He wants it to be. He doesn't want it to be optional. Chris wants his framework to do everything for him. He got a framework that just made his project, and he didn't have to do anything. That would be his ideal universe.

00:37:14 - Chris Ball

Push a button, I get an app. Yeah, I like it.

I think where that's going to go is, again, I don't want this thing. There's a lot of people that are like, "Don't tell me how my code should look," and this and that, but there's this whole other group that's like, "Hey, I don't know what a good config is, and it would be nice to have some sort of default."

So I think it's going to be like an... I say optional. You can just delete it right now; it's not a big deal. But I do think having a, "Hey, if you want the recommended config, we'll just generate it with the recommended config, and then you can migrate away as needed."

00:37:47 - Christopher Burns

ESLint is one of these tools that I feel like you want 100% in from the start, or it's never going to take off. Because if you start dedicating halfway through a product to ESLint, you're probably going to spend a lot of time fixing a lot of errors that won't necessarily block you from getting to production, but then you can finally commit.

00:38:17 - Chris Ball

It certainly could block you from production if you want it to. People love that.

00:38:23 - Anthony Campolo

All right. Is there anything else you want to say about Bison before we close off here? Or anything you want to say about Echo Bind? Anything you want to promote or things you're excited for in the future?

00:38:32 - Chris Ball

Well, let's start with some of the stuff that we think we're going to do with it. One of the things is we have some open pull requests that are going to be adding, hopefully by the time this is posted they will not be open, but basically a CLI to help if people start a project this way. How can you upgrade to some better ideas that have come since you started it?

So basically an upgrade process. One of the guiding things is to make it almost like AWS Amplify, but for lots of other things. We really want to improve that getting-started wizard kind of thing to fit any number of projects we create. Not everything uses this exact stack, and we have to change away from certain elements. So being able to, like you said, add in DynamoDB as an option or any number of pieces.

There's obviously a lot to that, but we want to make it so that you can pick and choose all the pieces and still generate the current state.

[00:39:25] But with those pieces, have as much done for you as we possibly can, including the CI and the deployment, but just be more flexible.

00:39:33 - Christopher Burns

When does your job posting close for developers? You can plug your developer role, fully plug it, be our guest.

00:39:45 - Chris Ball

So we need to hire right now. We have mostly senior roles open. We're definitely open to talking to people that are not a senior right now, but I think the biggest needs for us right now are definitely React Native, React, Node, TypeScript. These are all the things that we use.

We also have a designer post open and an account strategist to help run projects. So for us, we would love to talk to anyone interested. Absolutely.

00:40:13 - Christopher Burns

Where can they find that?

00:40:15 - Chris Ball

That's going to be on our website, or we use Workable. So echo.workable.com, or just go to Echo Bind's website. At the very bottom, there's a link to them. Echobind.com, by the way, is the website. And yeah, I'd love for people to apply.

00:40:32 - Anthony Campolo

Yeah, we'll have links to all this stuff in the show notes as well, so check that out for anyone who wants to get in touch or apply. I think it would be a very cool team to work for. So anyone who is looking for this type of role in terms of getting to be around great tech and good people who will help you grow, I would definitely take a look at it.

00:40:51 - Chris Ball

Appreciate that. Yeah. If you don't want to work on the same project for years and you want exposure to lots of different industries and everything, it's a good place for sure.

00:41:01 - Christopher Burns

And you get to work from home.

00:41:03 - Chris Ball

You do!

00:41:06 - Christopher Burns

Well, thank you for your time.

00:41:08 - Anthony Campolo

Thanks a lot, Chris.

00:41:09 - Chris Ball

Absolutely. Thanks, guys. Appreciate it.

00:41:12 - Anthony Campolo

Have a good one.

00:41:43 - Chris Ball

Oh yeah. Let me not create a six-hour recording this time.