Skip to content

Instantly share code, notes, and snippets.

@matthew-levan
Last active September 13, 2024 09:56
Show Gist options
  • Select an option

  • Save matthew-levan/847ac60c22a0f4c80663552065b45c44 to your computer and use it in GitHub Desktop.

Select an option

Save matthew-levan/847ac60c22a0f4c80663552065b45c44 to your computer and use it in GitHub Desktop.
Strategic considerations for our Butylic vision

Athenian Sunrise

In architecting the future of the Urbit UX, we must establish strategic principles according to the spirit of the opportunity and corresponding realities. These realities serve as natural limiting factors, in the same way that famous bodybuilder Henry Rollins says about weights in the the gym: "The Iron never lies." In other words, picking up the correct weight (not too heavy, not too light) is the only way we progress. The correct weight is the real weight is the one which fate has dealt us, and which is well within our immediate reach. It is characterized by its limitations with respect to our strengths. From the counterbalance of the limitations and strengths flourish a set of guiding principles, which we might refer to as our technique.

The limitations:

  • Urbit is default dead, not default alive.
  • Urbit is a single small startup and a small community.
  • Urbit is cash poor.
  • Urbit is a bad user experience.

The strengths:

  • Urbit is cool.
  • Urbit is a dream, a vibe.
  • Urbit is a secret weapon (or two).
  • Urbit is not limited by its OS.
  • Urbit is a social network.

The technique:

  • Build best-in-class for less-than-class.
  • Don't overpay. Pay only for what we need.
  • Use small cloud, not big cloud.
  • Prioritize legibility.
  • Avoid unnecessary complexity.
  • Stick with web standards.
  • Design. Use designers, don't depend on them.
  • Wear many hats.
  • Fear not Earth.
  • Minimize single points of failure.
  • Share often (with the team) and stay away from caves.
  • Remember: TypeScript can be tamed.

Alright, so we can see the right weight, it fits out strengths, and the two inform our technique. Our runway is developing and we're making our approach, how should we proceed?

Practically, of course. The neat thing about this chapter (codenamed Butyl or maybe... Operation Barbell?) is that we won't be reinventing the wheel and we won't be building a new OS, on a new VM, to replace the whole internet, lock, stock, and barrel. No, we will be treading very well-trodden territory, my friends. We can move fast and pick up tools, platforms, and techniques as fast as we throw them away. No Kelvin versioning here, my dudes.

Product Focus

The pinnacle of our near-term project is not onboarding, the login flow, ENS integration, or otherwise. The pinnacle of our focus is Athens, a new city which the public is free to admire but only citizens are allowed to enter. Our citizens, of course, are our very own Urbit ID owners. The telos of the city is not for me to expound on but let's just say quality matters (effortposts encouraged).

What does this new city look like? It's what we've always wanted but have been too hamstrung by the pace of our own research to build. It's not that our research has been slow-- no, in fact, the opposite is true. It's just that we forgot we were doing research for awhile there...

Let me cut to the chase. Architecturally, we're looking at something like this:

  • A cloud platform
  • A relational database (globally distributed and replicated, perhaps)
  • A stateless API (shipped to the edge)
  • A frontend (also on the edge)

Voila! A CRUD app. What were you expecting?! Fear not, for it will be our CRUD app and it will be a great CRUD app (perhaps even the best).

Where does this get deployed? TBD, but certainly not AWS or GCP (and Azure was never on the table, sorry Satya). "Don't overpay. Pay only for what you need." You know how we're hamstrung by Arvo for building compelling UXes? Using hyperscalers out of the gates as a cash poor, scrappy startup with only a few team members is just as good a way to get hamstrung again. In fact, much of the bit of infrastructure we still maintain at the UF is still maintained by one person with a particular set of skills... but, I digress.

Alright so we don't deploy to AWS. Again, then: Where do we deploy? We deploy where we can "build best-in-class for less-than-class", of course. Somewhere like Cloudflare... or Fly.io... or DigitalOcean... or one of these providers so-called "boutique", "niche", "specialized", or "alternative". But I'm thinking Cloudflare.

Why Cloudflare? Well, check this out, anon. You see that? That's a bigger network than even the hyperscalers have! We're not building some insanely compute-intensive application here. It's a CRUD app, and it should be really fast and snappy, which means the code should live as near to the users as possible. Cloudflare's CDN is unparalleled and they're trying to capture more of the "cloud" market (instead of just the "serve your Netflix stream" market, which I'm sure is healthy enough to support their years-recent foray into platforms here), so there's a nice pocket of above average utility for below average pricing. In other words, we can make Athens feel excellent and pay very little to do it.

Here's how:

  • Use Cloudflare's wrangler CLI tool for infrastructure management
  • Persist our relational data with Cloudflare D1
  • Ship our API to Cloudflare Workers
    • Workers are serverless (like D1)
    • Workers can be written in JS, TS, Rust, C, or C++
    • No cold starts
    • No containers (nobody wants Docker on their desktop, folks)
    • Auto-scaling (with scale to zero of course)
  • Serve our frontend from Cloudflare Pages
    • Blah, blah, blah... you get the picture

Cloudflare has other stuff we might want to use too like object storage, KV databases, etc.

Advantages of Cloudflare over alternatives:

  • It's cheap (inexpensive, actually; cheap implies poor quality)
  • Its free-tier is immense
  • It has the best CDN (obviously)
  • It's very fast, and very reliable
  • It's containerless
  • It has everything we need in one place

Framework

The framework we choose for building Athens will likely determine (if not significantly inform) how we build other apps in the evolving Butylic vision. I have thoughts on this too, which I'll have to revisit. The gist of it is that we should use Remix. The homepage there explains itself. Seriously, take a few minutes and check it out. Remix is a React framework that makes you feel like you're just coding web1 forms because you're using the web's standard Fetch API instead of some crafty JS runtime *ahem NODE ahem (excuse me)*. Remix is a perfect match for Cloudflare's offerings and it makes web programming feel fun again (I built Wexpert Systems' website and planet marketplace with it 2 or 3 years ago and found it fast to learn, fast to iterate with, and simple to understand because of the whole "web1 forms-based" workflow). It's also matched with Vite, the latest/greatest non-bundler-based JS development environment, and so tightly coupled with React that Remix itself is React Router.

Schemas, Migration, and Compatibility (oh my...)

Oops, will ya look at that? It's past my bedtime. Goodnight!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment