The Chewy Stack

Hi folks! I'm Raphaël, and I'm building a project called the Chewy Stack to help developers deploy complex applications faster.

I wanted to write a little something about the Chewy Stack, the motivations behind it, and the philosophy behind its architecture. Some of this stuff is also in our docs, but I want to give people a sense of why I, as an individual, wanted to build this thing.

Some History

The initial idea for the Chewy Stack came about four years ago in early 2019. I was working on a couple different projects at the time, and was thinking about the similarities I found across them. Some of it was agency work (I'm a co-founder of Éphémère Creative) and some of it was part-time contract work. Essentially my thought was that a lot of different web and mobile products have very similar needs, or at least there is a lot of overlap between their needs. For example, most of the types of projects I work on need two or more of the following:

• some sort of API
• a web and/or mobile client
• auth
• object storage
• search
• admin panel
• BI dashboard
• etc.

I also generally found that it made sense, at their scale and budget, to use off-the-shelf open-source tools rather than building anything custom. Often, tools like Firebase were a no-go. Sometimes it was because of data residency requirements. Sometimes because the functionality they required would be easier to build on a SQL database. Or some other reason.

Some Patterns

In the end, I developed a stack that I liked and re-used across multiple projects, which consisted (mostly) of Postgres, Hasura, Nest.js, Keycloak, and Next.js or Expo. More recently I've started moving away from Keycloak towards Ory Kratos/Oathkeeper. In certain cases, I also deployed AppSmith and Metabase and I considered tools like Meilisearch in a couple instances.

Now... getting all those different tools to play nicely together, instead of just building a simple Django or Rails app can be a little daunting, and there are potential operational and performance disadvantages at smaller scales. But once they are hooked up properly, and playing nicely together... it's a really nice set of tools to work with: they offer a lot of functionality out of the box, which I've found a lot of clients end up asking for and I like that they can scale and be managed independently. Another advantage was I found that when working with less experienced developers, they found that, if the development environment was well setup for them, they could develop features much faster with this stack than with others. Which brings us to...

Tooling

So I had sort of templated a bunch of stuff that would make our work more efficient internally:

• Cloud-based development environments, to make sure every dev had everything they needed to work with the stack.

• Scripts and configurations to make the stack run nicely and make it easy for devs not to have to think too much about the underlying complexity

• A bunch of deployment stuff to make it easy to deploy to different environments

Now, the idea for the Chewy Stack had started way back, and I had started to build an early version of it back then. But it's only after 2-3 more years of building projects for various clients that I really wished I had it available to me in my tool box. I also learned a lot about what would make it more efficient to work on those projects in that time.

So a couple years ago I decided we (Éphémère Creative) should probably dedicate some time towards the Chewy Stack. We were two developers at the time, including myself, and we spent a few months building out an early version of it. It was a really great starting point and a nice exploration of what the Chewy Stack could be. But over the following year and a half, I realized something: it felt too much like a somewhat customizable template, rather than a framework.

A Framework

Since then, I've re-imagined what the Chewy Stack should be to address the pains I had felt:

The Chewy Stack is a framework, built on required and optional components, organized in a dependency graph in which each node is aware of information about related nodes.

(I'm sure that definition will keep evolving)

I say "components" rather than "services" because here's one of the important things for me about this framework: it is aware of infrastructure, so the CLI will help you manage infrastructure as well as the services that run on top of it.

The goal is that if you want to run Next.js on Vercel, Hasura on Hasura Cloud, and Nest.js on a DigitalOcean kubernetes cluster, the Chewy Stack will help you do that, from development to deployment. Each service will know how to connect to the others in production, staging, etc., and your development environment will work with zero additional effort from you. You just write your code and run the deploy command when you're ready.

And we're developing interfaces to specify how all of this should work so that anyone can develop Chewy Stack-compatible services and deployment targets: this thing will be extensible. It might not be quite there yet when our first beta comes out... but it will get there eventually! That's not to say this will be for everybody, but hopefully the extensibility will make it possible for a wider variety of use cases down the line.

Oh, a quick note about the code. We're building everything in TypeScript, even though there are certain parts of the system that might have benefited from a different language. The reason is to make the entire codebase accessible to developers we're hoping will benefit from this. So if you like building on Next.js and/or Nest.js in TypeScript, you should be able to hop into the Chewy Stack code and feel right at home 😊

If you want to learn more about the Chewy Stack, want to chat, contribute, help out, ask questions, etc. you can find me on our Discord, or you can poke around the code on GitHub (and if you have any suggestions about the code/architecture/etc. please let me know! I would really appreciate the help!)

About Money

So... there are a few things we haven't figured out yet, money-wise. It's taking a lot of my time to build this! So I want to say a few things about money.

The first is that the core functionality of the Chewy Stack should always be freely available.

That being said, this thing needs to be financially sustainable. I recently enabled the sponsorship button on GitHub. But I know that it's early for people who don't know us to support. And unless a big infrastructure provider decides to sponsor, that's not going to be the thing that keeps us going.

We will definitely paywall some extra functionality, eventually. Maybe that's collaborative features. Maybe we'll do something like a licence where for-profit companies with more than X developers need to pay a yearly fee on an honour system. Maybe it's something tied to deployment, or monitoring. I'm not sure. But if you have any suggestions, I'd gladly take them 😂

Finally, since I mentioned licencing... after a chat with someone recently, I decided to throw the AGPL v3 on all of our code... but I'm not sure I like that. I'll probably be switching it to something more permissive. But I'm really a novice regarding licencing, so if anyone has advice, I'd appreciate it!

Again, if anyone reads this and finds it neat, please come find me on our Discord or shoot me a message at [e-mail]!