JavaScript still can't ship a full-stack module | Wasp

Skip to main content<br>🦋 Launch Week #12 — TS Spec · Wasp goes fully TypeScript-native. Kickoff Mon, Jun 15 →

Imagine if there were a way for us to somehow ship a full-stack package that you could plug into your app. Client code, backend code, webhooks, and database models all wired up and ready to go. I know I'd love that. Just install one complete module and the whole thing just works.

Take payments, for example. Normally, we install the Stripe SDK or some nice payments UI library, but it always requires manual wiring. And that wiring bit, figuring out how to integrate libraries written by different people, is one of the most annoying parts of the job.

Different ways you can write a full-stack feature.

Yeah yeah, I know what you are thinking. LLMs are writing most of the code these days, who cares? Ok, but it's already been established: what's good for humans is good for LLMs. They like to be lazy too.

Agents love working with legos​

Opus, GPT, and the rest of the models out there adore "legos" (pre-built pieces of functionality): they speed up the scaffolding process and result in more secure apps. You shouldn't trust your agent with hand-rolled components, especially with parts that need to be vetted (auth, payments...). When you trust the agent with that, you pay for more tokens and have no idea where the security holes are.

But imagine those agents had access to well-tested, full-stack implementations of auth, payments, file upload, admin dashboard, etc. Ideally, these packaged legos would hide most of the complexity from us and offer our agents control knobs for the most important configuration. For example, the agents would only be dealing with 2 env variables and maybe 2 or 3 lines of config for tested, reliable, and secure Google auth.

Matt Pocock talks about how LLMs struggle when a feature is split across too many layers and too much ad hoc glue. He focuses on the concept of "deep modules" from A Philosophy of Software Design as one of the methods that help agents work in your codebase. We can define deep modules as a standalone part of our app that exposes a simple way to use it (a thin interface), but hides all the internal complexities of the actual implementation.

“Your codebase is NOT ready for AI (here's how to fix it)”

The legos I described are nothing more than deep modules themselves, having a thin interface for the agent to interact with while the complexity is tucked away.

Legos have a name: full-stack modules​

While developing Wasp, a JS full-stack framework, we keep researching other ecosystems (Rails, Laravel, Django, etc.) and finding ways how they figured out developer productivity. We kept finding these reusable legos, so we gave them a name: "full-stack modules". Let's define what we mean by that exactly.

We usually talk about applications in two ways:

One is by technical layers: backend server, frontend client, database.

The other is by vertical slices: a complete feature that runs through the whole stack. Payments is our standard example: backend logic, the button the user clicks, and the database model that stores the state. A full-stack module is one of these vertical slices.

Technical layers vs vertical slices of an application.

In Rails and Laravel, you can install packages that ship a slice like this. Add the package and payments are covered. You are not assembling a model, a backend, and a UI by hand. You can install one package which was developed against the stable shape of these frameworks.

That is a real advantage developers in Rails and Laravel ecosystems have, and it matters even more in the AI age. You ship faster if you don't spend days figuring out payments. You are also safer if you lean on a battle-tested package instead of something you wrote (or generated) under time pressure. The same logic applies to LLMs. We rarely review every line they produce. So, the less custom glue we ask them to write, the better.

Researching full-stack modules in 11 frameworks​

To better understand the common patterns, I wanted to "feel" how full-stack modules work elsewhere. I can read the docs only so much, so I prefer playing around with code, trying to make some changes and see what kind of pushback the API will give me.

I gathered all the frameworks/libraries/tools that sounded interesting to me and looked like they had something to teach me. Then I sketched an app that would somehow use a full-stack module.

To make it easy to compare, I created a static HTML prototype and tried to flesh out the requirements:

users can sign up / log in

they can browse products

they can buy products with Stripe

they can see their purchased items

In all of the frameworks, we want to see the same webshop (same design, same capabilities).

Demo of the payments module in Django

Our webshop is made out of auth, payments, and products modules. In this exercise, we told the agent that the "payments" module must be...