Does Stripe use RoR? The author mentions the codebase was Ruby, but I didn't see if they talked about Rails.
It is Ruby but not rails
Stripe's Monorepo Developer Environment
41–50 of 249 posts
Re: Stripe's Monorepo Developer Environment
#42They 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.
I was at Stripe until 2022 and inconsistency with the language server was never an issue
Re: Stripe's Monorepo Developer Environment
#43This isn't recommended practice really and there is nothing about this which justifies having to maintain huge code bases in a single folder or multiple folders in one larger one. Won't be surprised to see that many would probably need a safari map or README documentation in every single folder to navigate a repository as large as stripes. Sounds like an emergence of a new bad practice if you are having to praise how…
> Won't be surprised to see that many would probably need a safari map or README documentation in every single folder
Is...documentation a bad thing?
Re: Stripe's Monorepo Developer Environment
#44Earlier quoted context omitted.
> Won't be surprised to see that many would probably need a safari map or README documentation in every single folder to navigate a repository as large as stripes. No different to having thousands of smaller repos instead. I personally dislike monorepos, for very niche, in-the-weeds operational reasons (as an infra person), but their ergonomics for DX cannot be understated.
The 'ergonomics for DX' benefit is that you can share code across projects without having to go down the path of creating a package / library pushed to some internal registry and pulled by each project right? Or are there any other aspects to the monorepo architecture that make it beneficial for large companies like that? Just curious, I've never worked in such an environment myself.
Every host running a particular commit is running the code you think it is. No submodules or internal packages. If you updated the Button component in the design system, when your commit is deployed, every service that gets deployed has the new button now.
Re: Stripe's Monorepo Developer Environment
#45We use similar practices in our 3.5 person team; we work via code-server and Aider with our own tooling on VPSs and this gets synced to execution VPSs which run dev versions, a lot of sentry logging and tests (mostly playwright these days). There is also a vps which does builds all day and logs to Sentry too. We can almost instantly get on our own test versions and see what we did, and, over the space of some seconds to minutes we see test and build data coming in. It works incredibly well for many years already. Onboarding people is easy and no one ever has 'it doesn't build on my system' as that's not something we do (you can of course, all scripts are there but why waste the time?).
I grew up with mainframes, minis and unix batch andor multiuser machines; for me this is the best way for business applications. I didn't particularly like the move to local all that much.
Re: Stripe's Monorepo Developer Environment
#46Does Stripe use RoR? The author mentions the codebase was Ruby, but I didn't see if they talked about Rails.
It is Ruby but not rails
Thanks. I wonder what the experience is like working on a very large codebase with or without a framework. E.g. Stripe vs Shopify.
Or if the framework is barely noticeable at that scale and doesn't really matter anymore. That's the impression I get for Instagram (which was built with Django).
Re: Stripe's Monorepo Developer Environment
#47Earlier quoted context omitted.
I'd suggest you revise your competitor analysis. Bazel definitely has a test command that with remote execution and caching absolutely allows you to run entire test suites in seconds* both locally and in CI eg. https://blog.aspect.build/typescript-with-rbe
This blog post says 2 and a half minutes not seconds. I know Bazel is a build system which distributes builds among remote machines. In fact using any computer language you can achieve these goals - you just need to program it. So yes you could probably do all the things with all the things, but Basel does not solve this problem out of the box. I wonder why stripe didn’t “just use Bazel”.
First release of Basel was in 2015 when Stripe was already 5 years old and the progenitor of this tooling was already running with several dozen users.
Re: Stripe's Monorepo Developer Environment
#48>Some caveats: It’s been nearly five years, and I have no doubt that I have misremembered some of the specific details, even though I’m confident in the overall picture. I’m also certain that Stripe has continued evolving and I make no claim this document represents the developer experience at Stripe as of today. Are there any more recently ex-Stripe folks here willing and able to comment on how Stripe's developer en…
Not ex-Stripe but in "close relationship" with them since its inception and there's a clear mark in my calendar circa end of 2018 when their decisions and output started to become... weird, or ill-designed.
I don't think it has to do with the dev environment itself, but I'd blame such thing for allowing to deliver "too fast" without thinking twice. Combine that with new blood in management and that's an accident waiting to happen *
They're the best in business still, but far from the well-designed easy-to-use API-first developer-friendly initial offering.
* Pure speculation based on very evident patterns
Re: Stripe's Monorepo Developer Environment
#49Earlier quoted context omitted.
It (obviously) leverages Nix, which in turn means the environment is declarative and fully reproducible (not "reproducible" as in docker). Now, you can use just Nix's devShells, but with devenv you have a middleground between just Nix package manager and a full fledged NixOS module system. Basically, write out one line of code - and you've got your Postgres, another one - full linter set up for whatever language you'…
Can I also get the security/isolation benefits that a duly configured docker/podman can provide (container can only act on mounted volume, non-root user, other seccomp settings?). I feel better doing my "npm install"s in such an environment (of course it's still not a VM – but that's another topic). When I read about nix, reproducibility is a goal, but security/isolation is a non-goal.
You can generate fully reproducible OCI/docker containers with devenv, so yes I think.
Re: Stripe's Monorepo Developer Environment
#50Earlier quoted context omitted.
Nix is the right tool for this, developing a tool to make Nix's UX easier is a great idea. Thanks for this!
What about dev containers?
You can create them with devenv, but they are actually reproducible :