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

241–249 of 249 posts

Re: Stripe's Monorepo Developer Environment

#241

Post by JasonSage »

stealthybox wrote: post #179
JasonSage wrote: post #159

Earlier quoted context omitted.

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

I'm curious about the # of svc's / stack / company / team size -- if you have your own blog -- would love to read it when you publish could be a cool lightning talk (or part of something longer) maybe it's a good piece for https://nixinthewild.com/ ? I'm @capileigh on twitter and hachyderm.io if you wanna reach out separately -- here is good tho too

Hey, I plan to reach out when I get some time :)

I can see there’s interest in the topic.

Re: Stripe's Monorepo Developer Environment

#242

Post by stealthybox »

JasonSage wrote: post #241
stealthybox wrote: post #179

Earlier quoted context omitted.

I'm curious about the # of svc's / stack / company / team size -- if you have your own blog -- would love to read it when you publish could be a cool lightning talk (or part of something longer) maybe it's a good piece for https://nixinthewild.com/ ? I'm @capileigh on twitter and hachyderm.io if you wanna reach out separately -- here is good tho too

Hey, I plan to reach out when I get some time :) I can see there’s interest in the topic.

sounds good! it's a cool anecdote :)

Re: Stripe's Monorepo Developer Environment

#243

Post by stealthybox »

JasonSage wrote: post #240
codethief wrote: post #203

Earlier quoted context omitted.

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.

When we used docker-compose we had a CLI tool which developers put in their PATH which was able to start/stop/restart services using the regular compose commands. This didn’t accomplish much at the time other than being easy to remember and not requiring folks to know where their docker-compose files were located. It also took care of layering in other compose files for overriding variables or service definitions. Sh…

the pm2 thing via a custom cli is interesting

several nixy devtools do some process management now

something we're trying in Flox is per-project services run /w process-compose. they automatically shutdown when all your activated shells exit, and it feels really cool

Re: Stripe's Monorepo Developer Environment

#244

Post by bhuga »

codethief wrote: post #239
bhuga wrote: post #236

Earlier quoted context omitted.

> Isn't this a matter of not reusing old VMs after a `git pull/checkout`, though? Yes, but forcing people to rebase is disruptive. Master moves several times per minute for us, so we don't want people needing to upgrade as the speed of git. Some things you have to rebase for: the code you're working on. Other things are the dev environment around your code, and you don't want that to be part of the checkout as much a…

You seem to assume you would have to rebuild the entire VM whenever any code in git changes in any way. I don't think you do: You could simply mount application code (and test data) inside the VM. In my book, the VM would merely serve to pin the most basic dependencies for running your integration / e2e tests and I don't think those would change often, so triggering a VM rebuild should produce a cache hit in 99% of t…

> I don't think those would change often

I think this is where our contexts may differ, and so we end up with different tradeoffs and choices :) The services running on our dev servers are updated dozens of times per day, and they roughly correspond to the non-code parts of a VM.

Re: Stripe's Monorepo Developer Environment

#245

Post by codethief »

JasonSage wrote: post #240
codethief wrote: post #203

Earlier quoted context omitted.

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.

When we used docker-compose we had a CLI tool which developers put in their PATH which was able to start/stop/restart services using the regular compose commands. This didn’t accomplish much at the time other than being easy to remember and not requiring folks to know where their docker-compose files were located. It also took care of layering in other compose files for overriding variables or service definitions. Sh…

Thanks for elaborating!

By pm2 you mean https://www.npmjs.com/package/pm2 ?

Re: Stripe's Monorepo Developer Environment

#246

Post by codethief »

bhuga wrote: post #244
codethief wrote: post #239

Earlier quoted context omitted.

You seem to assume you would have to rebuild the entire VM whenever any code in git changes in any way. I don't think you do: You could simply mount application code (and test data) inside the VM. In my book, the VM would merely serve to pin the most basic dependencies for running your integration / e2e tests and I don't think those would change often, so triggering a VM rebuild should produce a cache hit in 99% of t…

> I don't think those would change often I think this is where our contexts may differ, and so we end up with different tradeoffs and choices :) The services running on our dev servers are updated dozens of times per day, and they roughly correspond to the non-code parts of a VM.

Or maybe we just used terminology differently. :) Why wouldn't those services be part of the code? After all, I thought we were talking about a monorepo here.

Re: Stripe's Monorepo Developer Environment

#247

Post by JasonSage »

codethief wrote: post #245
JasonSage wrote: post #240

Earlier quoted context omitted.

When we used docker-compose we had a CLI tool which developers put in their PATH which was able to start/stop/restart services using the regular compose commands. This didn’t accomplish much at the time other than being easy to remember and not requiring folks to know where their docker-compose files were located. It also took care of layering in other compose files for overriding variables or service definitions. Sh…

Thanks for elaborating! By pm2 you mean https://www.npmjs.com/package/pm2 ?

Yep!

Re: Stripe's Monorepo Developer Environment

#248

Post by olejorgenb »

closeparen wrote: post #202
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 2000…

> VSCode is very slightly more capable than plain text editor

What? For which languages are you talking about? For python, VSCode is leaps and bounds ahead of PyCharm if your project is well typed.

JetBrains offer a remote solution now though: https://www.jetbrains.com/remote-development/gateway/

Re: Stripe's Monorepo Developer Environment

#249

Post by closeparen »

olejorgenb wrote: post #248
closeparen wrote: post #202

Earlier quoted context omitted.

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 2000…

> VSCode is very slightly more capable than plain text editor What? For which languages are you talking about? For python, VSCode is leaps and bounds ahead of PyCharm if your project is well typed. JetBrains offer a remote solution now though: https://www.jetbrains.com/remote-development/gateway/

I work in Go. My company keeps trying to push us onto their VSCode based remote environment. “Find all references” doesn’t, “go to definition” works maybe 30% of the time, and the Go LSP daemon needs to force killed dozens of times in a working session, taking several minutes to recover each time. The autocomplete suggestions are about 3x as likely to be from the VSCode fuzzy matching thing or Copilot slop as actually existing symbols that type check in context.

JetBrains Projector and Gateway meanwhile lock up or outright crash several times an hour; text input and scrolling are not smooth.

Post reply on HN