A place for developers to talk about building on Farcaster.

/dev

Here's how our developer tooling allows us to ship 100+ features per year with a team of 9.

I’ll cover 🧵
- Our monorepo
- One-command local build
- Shared multi-platform code base
- CI
- Multiple staging environments
- Fast deployment & easy rollback

Bringing AI to email at Shortwave. Previously Cofounder of Firebase.

Our development environment is central to how we work, not just for engineering, but for *everyone*, in every function. 

Not only are all of our apps in code, but so is our website, blog posts, emails, marketing assets, etc. Git is the common language we speak across the whole company.

How do we enable this? With a monorepo.

All of the code for our core product, including web, iOS, Android, backend code, k8s config, etc. all lives in a single repo.

This makes setup easy, and it gives us versioning & code review for changes across the entire stack. It also makes testing easier.

We are obsessed with making our local development environment work with only a single command -- including loading test data.

We use Bazel for our builds, and all of our configuration is code, checked into git.

This makes getting started fast and keeps everyone's dev env moving in sync as our infrastructure evolves.

It's a ton of work to set this all up, and ensure that *everything* we do works in both production and development environments (esp. with AI!), but it's worth it.

We share a single code base across all client-side platforms (web, iOS, and Android).

All of our business logic is in Typescript and separated from UI code with clear internal APIs. 90%+ of our business logic is shared across all platforms.

We use React Native on iOS, and drop down to native only when we have to.

Next: CI

We lint and test our code automatically on every commit using Github Actions.

We aggressively enforce linting and code formatting rules to avoid bad habits and bikesheds.

We make it really easy to get code onto staging environments for testing. 

Our backend has a staging cluster that mirrors our production cluster. It's smaller (to save $$) but functionally the same.

Our web frontend can be deployed to many different staging environments, each with its own subdomain. Everyone on our team can have a different version of the app deployed to staging simultaneously.  Our Android app pulls this same code (it's a PWA) so we can test there quickly too.

For iOS, we use Testflight.

Lastly - deployment and rollback.

The goal of all of the above is to get things *shipped* -- and we do! We've fully automated deployments, and we put new code in prod 5-10 times per day.

To ship things this quickly you have to make it easy to handle errors  (yes we make mistakes!). This is what rollbacks are for! We save every deployed artifact and make it one click to roll back to a previous version. 

When something breaks in prod, we rollback first, and ask questions later.

And that's the core of it!

Tomorrow I'll be talking about how we use experiments to deliver features incrementally and get rapid early feedback from users.

Every person, from me, to our growth specialist, to our designer, is working directly in code: testing & reviewing things locally, making changes, and shipping.