Steve Krouse

Compose update: Nov 2021

Nov 2021 Β· All Compose Updates

TL;DR

The beta prototype is almost ready! The challenge in December will be finding our founding programmer (a solo React dev in need of a backend for a small project), and iterating closely with them. Please, please, please hit me up if you or someone you know wants to be our founding programmer πŸ™

AWS Serverless

We ended last month feeling optimistic about the user reactions to the alpha prototype, and started this month by working on the architecture for the beta prototype. It seemed that AWS serverless could be the perfect fit. I (Steve) has long dreamed of breaking up an app into Lambda Functions, API Gateway Routes, SES calls, and other AWS services, and (virtually) never have to worry about scale again.

Long story short: I spent two weeks (10 days of which with an expensive, full time AWS consultant), and it was extremely unpleasant and slow. Ultimately we terminated this strategy, because we're not yet at the stage for scale to matter. It makes more sense to focus on getting the product right for a medium scale now, and rebuild it for bigger scales later, when we have users motivating it and more resources to fund it. On the bright side, at least I won't regret my less-scalable choice because I did give serverless a real shot.

Node, Postgres & Railway

Our new architecture is in:

I'm much happier and more productive this way. In about a week, I was able to build 10x as much as the two weeks in AWS.

Programming in flow

Relatedly, last month I (Steve) took a fantastic branding & positioning course and developed the following purpose and positioning, respectively:

The purpose of Compose is to support programming in flow.

For solo React programmers
Who are hacking on web apps
Compose is a backend-as-a-service
That keeps you where you want to be, working on your UI
Unlike Firebase, Compose lives in your React hooks, so you don’t need to learn a query or permissions language.

Product highlights

There are a number of surprising (even to us) features that have emerged from seriously working on the question: What would the ideal backend interface be React be β€” from first principles?

  1. Server code, written within your client side code, is deployed on every save. This is a big deal. It addresses possibly the biggest complaint about Firebase (deploying Cloud Functions).
  2. Server logs & errors are streamed to the developer's JS console (and emailed to them if they're offline). This is also a very big deal. It makes server-side development feel just like client-side, local development. You would be shocked to learn how many clicks it takes it is to find this data within the AWS Console for Lambda functions.
  3. There's no distinction between a developer account and a user account. We've long dreamed of blurring the line between developer and user, and this is a necessary step. An account in Compose is an account in Compose.
  4. There's no boundary around "apps". Like in DNS or Dynamicland, Comise is a global namespace. This means all Compose users and states coexist. (Like all product decisions) I'm open to changing this for compliance or scalability, but I love how this breaks down the barriers between app data silos. Just like how Stripe remembers your credit card across apps, Composes remembers all your state across apps.
  5. No admin panel or CLI: the entire Compose interface lives in client-side JavaScript. Admin panels take you out of where you want to be: your React codebase. But here's the kicker: we (and the community) will build all of the pieces of an admin panel in components. Want to view some piece of state in a table? npm install a Viewer Component and hook it up into your app. It should take less than 5 minutes, and what you have is something in your tool, and fully customizable to your needs. Instead of using a generic "Compose Admin Panel", make your own internal tools with no Retool required: just using React & Compose should be that fast and easy.
  6. Super simple magic email login. I daresay that logging users into your Compose app is the simplest way to add users to an app. It's just a JS function call, and it sends a magic login email link.

Dog-fooding The Compose Community

While it sounds a bit distracting, there are four amazing reasons to build our own Discord alternative in Compose:

1. Dog-fooding is incredibly important, and a toy app just won't cut it. We personally want to be the biggest users of The Compose Community to foster a welcoming and helpful environment, so this way we will constantly be working on the Community app itself, which will keep us in constant touch with the pain-points of the Compose service.

2. As the founder of the Future of Coding Slack Community, I (Steve) have long dreamed of an alternative to Slack, Discord, and now I can co-create the perfect home for our community. Some of the unique features I'm excited about:

  1. Turning the #help channel into a Stack Overflow question base (indexed by search engines)
  2. Infinite threading (a la Reddit and HN) but with a chat app vibe
  3. Twitter-like #hashtags mixed with Slack/Discord #channels

3. We hope to enable end-programmer (and eventually end-user) programming. For example if a member of The Compose Community wants a different client interface, such as keyboard shortcuts, different colors, or an entirely different UI from scratch, they can build it themselves, and still participate in the same conversation as the rest of us. Compose app enable the "bring your own client" mentality.

4. We want to enable composability across the client/server/database boundaries. Currently programmers can only compose horizontally: front-end components and backend libraries. We dream of kickstarting an open-source explosion of fullstack components, and The Compose Community is the first foray in this direction. If a member of The Compose Community likes the app, they can easily fork the repo (or pieces of it) and deploy fresh copies for other communities.

Next month: founding programmer

We hope to be ready for our founding programmer in a week or two. (We just need to finish the community, squash a couple bugs, and finish the docs.)

Ideally this person is:

We're also open to someone who is:

We're also open to someone prototyping an MVP for a startup!

Some project ideas:

Next year

If all goes well with the user(s) in Dec, we'll launch properly in Jan or Feb on HN, and plan to fundraise off the tail end of that.

Thanks for reading! Feedback much appreciated ❀️

Steve and Adriaan