Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe's Monorepo Developer Environment

blog.nelhage.com

Post reply on HN
Print view View original

201–210 of 249 posts

Re: Stripe's Monorepo Developer Environment

#201

Post by codethief »

bhuga wrote: post #166
aidos wrote: post #153

Earlier quoted context omitted.

Ah! So that’s a spot where we’re talking past each other. I’d anticipate you would be equally as able to ssh to VMs on dev laptops. That’s definitely a prerequisite for making this work in the same way as you’re currently doing. The only difference between what you do and what I’m suggesting is the location of the VM. That itself creates some tradeoffs but I would expect absolutely everything inside the machine to be…

> I’d anticipate you would be equally as able to ssh to VMs on dev laptops. That’s definitely a prerequisite for making this work in the same way as you’re currently doing. Our laptops don't receive connections, but even if they could, folks go on leave and turn them off for 9 months at a time, or they don't get updated for whatever reason, or other nutty stuff. It's surprisingly common with a few thousand of them ou…

Maybe I'm missing something here but couldn't you just track the whole VM setup (dependencies, dev tools, telemetry and everything) in your monorepo? That is, the VM config would get pulled from master just like everything else, and then the developer would use something like nixos-shell[0] to quickly fire up a VM based on that config that they pulled.

[0]: https://github.com/Mic92/nixos-shell (not to be confused with nix-shell)

Re: Stripe's Monorepo Developer Environment

#202

Post by closeparen »

p-o wrote: post #93

It's always so enlightening to have articles like this one shed light on how companies at scale operate. It goes without saying that many of the problems Stripe faced with their monorepo isn't application to smaller businesses, but there are still bits and pieces that are applicable to many of us. I've been working on an ephemeral/preview environment operator for Kubernetes( https://github.com/pier-oliviert/sequencer…

I find the devbox approach very frustrating because the JetBrains IDEs are leaps and bounds ahead of everything else in terms of code intelligence, but only work well locally. VSCode is very slightly more capable than plain text editor + sync or terminal-based editor over SSH, but only slightly.

It's darkly amusing how we have all these black-magic LLM coding assistants but we can't be reasonably assured of even 2000s level type-aware autocomplete.

Re: Stripe's Monorepo Developer Environment

#203

Post by codethief »

JasonSage wrote: post #159
stealthybox wrote: post #156

Earlier quoted context omitted.

That's a huge win -- has your team written about or spoke on this anywhere?

No but I'd be happy to (I maintained the docker-compose stack, our CLI, and did the transition to Nix).

Hi Jason! Like many others here I'm looking forward to that blog post! :-)

For now, could you elaborate on what exactly you mean by transitioning from docker-compose to Nix? Did you start using systemd to orchestrate services? Were you still using Docker containers? If so, did you build the images with Nix? Etc.

Re: Stripe's Monorepo Developer Environment

#204

Post by codethief »

aylmao wrote: post #171
klodolph wrote: post #58

Earlier quoted context omitted.

Multirepo also comes with cost overhead. I think people talk about it somewhat less. I’ve worked at multirepo and monorepo places, both, before. My current company has a multirepo setup and it sure seems like it comes with plenty of tooling to fetch dependencies. That tooling has to be supported by FTEs.

+1. I'd go as far to say that multi-repo probably needs as much, if not more effort to properly keep functioning, but all that effort is better "hidden" so people assume monorepos are more work. With a monorepo, it's common to have a team focused on tooling and maintaining the monorepo. The structure of the codebase lends itself to that With a multirepo codebase, it's usually up tu different teams to do the work asso…

I couldn't agree more! At the company I currently work for I have seen this phenomenon time and again.

Re: Stripe's Monorepo Developer Environment

#205

Post by Aeolun »

Hackbraten wrote: post #32
Aeolun wrote: post #16

They decided to keep the code on the local machine, but the language server on the remote one. That seems like a recipe for inconsistency. You only get relevant results from your language server once your code has synced.

The article mentions that the LSP itself already has baked-in support to enable editors to send chunks of unsaved edits to the language server (LS) as they happen. What Stripe’s configuration introduced is that they used a remote LS instead of the default local LS. Regardless, VS Code already defers LSP communication until it feels idle, and developers are used to that. So I wouldn’t expect a remote LS to significant…

Huh, I missed that first part. That’s a decent way to go about it.

Re: Stripe's Monorepo Developer Environment

#206

Post by physicles »

MetaWhirledPeas wrote: post #182
hamandcheese wrote: post #164

Earlier quoted context omitted.

My main gripe with the dev box approach is that a cloud instance with similar compute resources as a developers MacBook is hella expensive. Even ignoring compute, a 1TB ebs volume with equivalent performance to a MacBook will probably cost more than the MacBook every month.

Wouldn't this be a reasonable alternative? Asking because I don't have experience with this. 1. New shared builds update container images for applications that comprise the environment 2. Rather than a "devbox", devs use something like Docker Compose to utilize the images locally. Presumably this would be configured identically to the proposed devbox, except with something like a volume pointing to local code. I'm in…

We do this, but with k3s instead of docker compose (it’s a wonderful single-box substitute for full k8s), and a developer starts by building the relevant container images locally. If everything works, it takes about 3 minutes to get to a working environment with about a dozen services.

We steer clear of proprietary cloud services. In place of S3, we use minio.

The one sore spot I haven’t been able to solve yet is interactive debugging. k8s pushes you toward a model where all services need a pile of environment variables to run, so setting these up is pretty painful. In practice, though, all rapid iteration happens inside unit tests, so not having interactive debugging isn’t much of a productivity drag.

Re: Stripe's Monorepo Developer Environment

#207

Post by bartonfink »

itsjustjordan wrote: post #195
vfclists wrote: post #189

How does a payment service wind up with over a 1000 engineers? I understand that "engineers" may not mean "developers", it could DevOps, site reliability and all the bits and pieces that make up a large service provider, but over a 1000? Can someone please enlighten me?

Surely in 2024 we can't be classifying Stripe as just "a payment service"

What else have they done that's worth giving a shit about?

Re: Stripe's Monorepo Developer Environment

#208

Post by oftenwrong »

jrochkind1 wrote: post #183
ahtihn wrote: post #181

Earlier quoted context omitted.

How is a mono repo the simple solution compared to one repo per independently releasable component ? All the tooling is much easier to use when each application has its own repo.

The argument would be that for simple organization, dividing things into independently releasable components is less simple than just having one app. I think that's what most simple organizations do, no? Why do you need the complexity of independently releasable components for your simple organization? Now you have to track compatibility between things, ensure what version of what independently releasable thing works…

The monorepo vs many-repos discussion often hits upon so many implied factors, but it's only really about how source code is stored.

It doesn't necessarily indicate much about the deployment model. You can have many separately releaseable things in one repo, and you can have one independently releaseable thing based on the sources of many repos.

Monorepos enable, but don't require, source-level co-evolution. Or maybe a better way to put it would be: many projects can have a shared history. Many-repos require independent source-level evolution. In the open source world there is no real choice: every project wants to be independent. The authors of a given project can do what they wish with it.

One weird thing to think about is that monorepos can accomodate many-repo style workflows. You can still develop projects completely independently within a single repo. Of course you can store separate projects on separate revisions, which would be weird. An even weirder approach would be having all projects in a given revision, but have totally independent builds, no single-version policy, no requirement for atomic compatibility, et cetera. These are all things that are often imposed for monorepos, but that are also not requirements. Basically, you can treat each project as independent even if their sources are stored together. I don't think there are any reasons to actually do this, of course.

Re: Stripe's Monorepo Developer Environment

#209

Post by wmoxam »

Macha wrote: post #8
KolmogorovComp wrote: post #4

> In addition, Stripe’s monorepo was (to our knowledge) the largest Ruby codebase in existence Bigger than shoppify's?

So from a gut feeling that sounds right, finance is a pretty complicated domain with a lot of per vendor interactions, and Shopify outsources their payment stuff to Stripe. Also on a headcount level, Google tells me Shopify has 3,500 employees to Stripe's 9,500. Obviously neither company is compromised entirely of engineers, so this is a ballpark estimate. GitHub feels like the real case where there might be a larger…

> Shopify outsources their payment stuff to Stripe

I thought they used active_merchant

Re: Stripe's Monorepo Developer Environment

#210

Post by mikeocool »

numbsafari wrote: post #150
mootoday wrote: post #77

I've worked with remote dev environments for many years, including some time with one of the providers of such a service. It became clear to me that cloud-only is not the way to go, but instead a local-first, cloud-optional approach. https://mootoday.com/blog/dev-environments-in-the-cloud-are-...

This is my biggest complaint with GitHub CodeSpaces. I should be able to launch a local VM using the GitHub Desktop App just as easily as I can an Azure-hosted instance.

Look into dev containers — if you set one up for your repo, you get pretty much the same experience as GitHub Codespaces, but the choice of running it locally.
Post reply on HN