9 ms·

Stripe's Monorepo Developer Environment

• secondcoming 2y ago
  What's the easiest way of sharing things like protobuf definitions across multiple separate repos and making sure things are always in sync?
  • MrDarcy 2y ago
    buf.build
• domenkozar 2y ago
  We've been building https://devenv.sh https://devenv.sh for that reason, I expect more companies to go back to local development once they see DX has improved locally.
  • evnix 2y ago
    How is this better or different from tools like dev which use docker
    • drakerossman 2y ago
      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're using, etc.
      • tmerse 2y ago
        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.
        • ParetoOptimal 2y ago
          You can generate fully reproducible OCI/docker containers with devenv, so yes I think. https://devenv.sh/containers/ https://devenv.sh/containers/
        • pxc 2y ago
          > When I read about nix, reproducibility is a goal, but [...] isolation is a non-goal. Generally, yes. But you can use or put together something like this to run Nix inside a devcontainer instead of locally: https://github.com/xtruder/nix-devcontainer https://github.com/xtruder/nix-devcontainer So you can use them in conjunction (or alternation, if for some projects you're okay running without a container) without having to specify your development environments twice. > 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). There are basically two kinds of integration you can do for a project with Nix, which I'll call deep and shallow. In shallow integration, you just have Nix provide the toolchain and then you build the project (manually, with a script, with a Makefile, whatever). This is pretty common and pretty easy, and gives you no protection from malicious NPM build scripts. For deep integration, you can actually have Nix build your whole project. This has some downsides, like that it can't really handle incremental builds. It also imposes restrictions, like no network access by anything but Nix at build time, all packages are built by special build users with no homedirs and no perms to access anything, etc. When you do that kind of build/install, you do get some protection from crypto miners lurking in the NPM registry or PyPI or whatever.
  • stavros 2y ago
    Nix is the right tool for this, developing a tool to make Nix's UX easier is a great idea. Thanks for this!
    • eadmund 2y ago
      > Nix is the right tool for this Or Guix, which has the advantage of a more pleasant language.
      • earthling8118 2y ago
        The language isn't the problem with nix.
        • 0x457 2y ago
          It's not "the problem", but it's a problem. It's better than alternatives, but it's hacky nature shows.
          • ParetoOptimal 2y ago
            Well, if you believe: - discoverability is a problem in Nix - Guix encourages or "shepherds" more discoverable functions, modules, and abstractions Then the language could be a problem.
        • nitsky 2y ago
          What is?
      • chpatrick 2y ago
        YMMV, I really don't like lisp braces personally.
      • otabdeveloper4 2y ago
        That's, like, just your opinion, man. Scheme and/or Lisp is literally the worst language choice for this problem domain.
  • pxc 2y ago
    My small team uses devenv for all our development environments and we really like it. Local DX is really important to me and to our team, which is a big part of why we've chosen Nix and devenv. As we've started to use it more extensively, we've also found that we want to add some enhancements, work out some bugs, and experiment with our own customizations out-of-tree, etc. I'm happy to report here on HN that devenv is well-documented and easy to extend for Nix users who have some experience with Nix module systems, and that Domen is really responsive to PRs. :)
• reillys 2y ago
  I chatted to Nelson when I was designing brisk (https://github.com/brisktest/brisk https://github.com/brisktest/brisk) and his insight informed the development of it. Among other things, Brisk allows you to run tests for your local code changes in the cloud (basically the pay mini test piece but for any test runner) We also have a sync step much like the one described here and allow users to run one off commands (linters, tsc etc)
  • riffraff 2y ago
    > Brisk allows you to run tests for your local code changes in the cloud how does this work for interactive debugging? I was going to ask the same about the system in TFA but I might as well ask you :)
  • IshKebab 2y ago
    Can't you achieve all that just using a build system with reliable remote builds & caching e.g. Bazel, Buck, Please, etc? That also avoids hacky sync scripts.
    • reillys 2y ago
      No you can’t. They don’t work from your local development env and also work in your CI env. Mostly Brisk was designed to run your complete test suite on every codes save (ie local save) but it also works great from your CI. We can run entire test suites in seconds which is performance you don’t get with those systems you named (which are generally for building/compiling)
      • reillys 2y ago
        To be clear the sync step is used for the test suite execution not only the one off command running - it’s just something we can also easily do because we have a hot env in the cloud
      • joshuamorton 2y ago
        > They don’t work from your local development env and also work in your CI env. This is one of the biggest selling points of bazel-like build systems. Like to the extent that, for some changes, bazel can say "even though you changed this source file, I can be 100% certain that that change didn't affect any tests and so I will not run them"
• KolmogorovComp 2y ago
  > In addition, Stripe’s monorepo was (to our knowledge) the largest Ruby codebase in existence Bigger than shoppify's?
  • Macha 2y ago
    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 codebase. It's in the middle for employees (6,500), but it's existed longer than Stripe (though not as much longer as my gut feeling told me, interestingly)
    • wmoxam 2y ago
      > Shopify outsources their payment stuff to Stripe I thought they used active_merchant
  • spacemonkey92 2y ago
    I also wonder how they handle merge requests in a monorepo, especially when it comes to the code review process.
    • azthecx 2y ago
      Typically you have owner files or similar in the subprojects that are read by automation tooling and humans alike
    • popinman322 2y ago
      It's possible to get stuck in merge hell where all your reviewers ok the PR but someone merged a conflict 2 seconds ago, or you've got a reviewer in Singapore while you're in SF and conflicts appeared overnight. In general it was pretty rare, in my experience. The code bases were pretty well modularized.
    • 2y ago
• rvz 2y ago
  This 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 large your code base is.
  • pavlov 2y ago
    Meta also has a massive monorepo accessed primarily through cloud devservers. When several of the world’s most successful software companies use this approach, it’s hard to argue that it’s inherently bad. Of course it’s sensible to discuss what lessons apply to smaller companies who don’t have the luxury of dedicated tooling teams supporting the monorepo and dev environment.
    • n_ary 2y ago
      Just because some successful companies use some approach doesn't make it the best practice. I have seen firsthand nuisance of monorepo, which took almost 15minutes to correctly switch branches on intel machines(and decently spiked the CPU by causing windows defender to panic). It has decent benefit of easy code sharing, but build and test are soul sucking experiences and if someone decides to run some updated formatter and linter rule accidentally, the whole MR becomes a nightmare to correctly review(once had a 2k+ changes and had to request to rollback and then only commit what they actually wanted to change).
      • aidos 2y ago
        Why would you feel obliged to accept a MR in which someone has accidentally changed large amounts of code?
      • tail_exchange 2y ago
        > took almost 15minutes to correctly switch branches on intel machines This can probably be fixed with trivial tuning. Just configuring Git to fetch only your branches would speed up the branch switching significantly. > build and test are soul sucking experiences Why? It doesn't have to be. If you are going to build the entire monorepo, then yes, but this should only happen when you are running CI, and even then you can break down the builds into smaller components. > the whole MR becomes a nightmare to correctly review Not if you set up code ownership properly. You also need to think what happens in case of emergencies, so having a selected list of "super users" and users with permissions to bypass reviews is important. It sounds like this company wanted a monorepo, but nobody invested any money or time to actually think about developer productivity. When this happens, yes, of course it won't be good, because no project succeeds like this. The nice thing about a monorepo is that instead of 1,000 repos with tooling all over the place and no specialist to take care of them, you can have one repo with really good tooling and a team dedicated to just keep it running smoothly. But if nobody is actually taking care of the monorepo, it will rot just like any other codebase.
• Aeolun 2y ago
  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.
  • Hackbraten 2y ago
    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 significantly impact the level of inconsistency that developers already accept when using a local LS.
    • Aeolun 2y ago
      Huh, I missed that first part. That’s a decent way to go about it.
  • bastawhiz 2y ago
    I was at Stripe until 2022 and inconsistency with the language server was never an issue
    • aidos 2y ago
      Due to the work that this team put in though, right? The choice to run dev environment far away from the files puts you in the position of needing to engineer your way past the inconsistency.
      • bastawhiz 2y ago
        Yes, almost certainly. On the other hand, there was so much code that running everything on your own laptop was essentially out of the question. Doing a git pull after a long vacation locked up your dev box for a hot minute while it checked all the types—doing the same thing on your MacBook would be painful at best.
• CodeVenturer 2y ago
  [dead]
• srvaroa 2y ago
  "This scale – the scale of devprod, and in turn the scale of the overall organization, such that it could afford 10 FTEs on tooling – was a major factor in our choices" Is basically the summary for most mono/multi repo discussions, and a bunch of other related ones.
  • mhh__ 2y ago
    Not sure. I think a lot of this is just type of thing comes because with a monorepo you can actually see the problems to solve whereas you can easily end up with the same N engineers firefighting the same problems K times across all your polyrepos.
    • bluGill 2y ago
      You have different problems with both. Some problems are hidden in one, but there is no one best answer. (unless your project is small/trivial - which is what a lot of them are)
  • klodolph 2y ago
    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.
    • hibikir 2y ago
      Internally, they definitely do. I worked at Stripe's monorepo many years ago, and I am working at a larger company with massive amounts of repos. The difference in pain has little to do with mono v multi, but with the capabilities of your tooling team. If there's anything I'd say to low-level execs, the kind that end up with a few hundred developers under them, it's that mis-sizing the tooling team, in one way or the other, comes with total productivity penalties that will appear invisible, but will make everything expensive. Understanding how much of a developer's day is toil is very important, but few really try to figure that out.
• bool3max 2y ago
  Off-topic but the font on this blog is stunning - after some digging it seems to be "Vollkorn".
• delhanty 2y ago
  >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 environment might have evolved since the OP left in 2019?
  • artyom 2y ago
    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
    • rattray 2y ago
      Ex-Stripe ('17-'20) here. Agree. Though I am under the impression that things have gotten more sensical internally over the last year or so. Note also that the devprod team has largely been shielded from the craziness, and may still be making good decisions (but I don't know what they are in this realm personally).
  • nkohari 2y ago
    I spent 4.5 years at Stripe, and left in March. The biggest difference not mentioned is the article is that code is no longer kept on developer machines. The sync process described in the article was well-designed, but also was a fairly constant source of headaches. (For example, sometimes the file watcher would miss an update and the code on your remote machine would be broken in strange ways, and you'd have to recognize that it was a sync issue instead of an actual problem with your code.) As a result, the old devbox system was superseded by "remote devboxes", which also host the code. Engineers use VSCode remote development via SSH. It works shockingly well for a codebase the size of Stripe's. There are actually several different monorepos at Stripe, which is a constant source of frustration. There have been lots of efforts to try to unify the codebase into a single git repo, but it was difficult for a lot of reasons, not the least of which was the "main" monorepo was already testing the limits of the solution used for git hosting. Overall, maintaining good developer productivity is an extremely challenging problem. This is especially true for a company like Stripe, which is both too large to operate as a "small" company and too small to operate as a "big" company. Even with a well-funded team of lots of super talented people putting forth their best efforts, it's tough to keep all of the wheels fully greased.
• pjmlp 2y ago
  Yet another replay of timesharing development experiences, I guess we need a couple of generations more to count how many times does a pendulum swing back and forth during a developer's lifetime.
• jdtig 2y ago
  Does Stripe use RoR? The author mentions the codebase was Ruby, but I didn't see if they talked about Rails.
  • bastawhiz 2y ago
    It is Ruby but not rails
    • jdtig 2y ago
      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).
      • esprehn 2y ago
        At that scale there's certainly a framework and many in house libraries with opinions and patterns. It's just not rails.
      • bastawhiz 2y ago
        They had their own ORM, and a web framework built on Sinatra. It wasn't as though you needed to reach far for a tool if you needed one
    • jcmfernandes 2y ago
      Do they use zeitwerk?
      • froydnj 2y ago
        We do, yes.
• anonzzzies 2y ago
  We 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.
• aidos 2y ago
  Maybe a silly question, but why all this engineering effort when you could host the dev environment locally? By running a Linux VM on your local machine you get a consistent environment that you can ssh to, remove the latency issues but you remove all the complexity of syncing that they’ve created. That’s a setup that’s worked well for me for 15 years but maybe I’m missing some other benefit?
  • yeswecatan 2y ago
    I came to ask the same thing. We use docker-compose to describe all our services which works fine.
    • JasonSage 2y ago
      This does not scale to a large number of services with a certain amount of RAM/processing per service.
      • aidos 2y ago
        You could still run the proxy they have that lazy boots services - that’s a nice optimisation. I don’t think that many places are in a position where the machines would struggle. They didn’t mention that in the article as a concern - just that they struggled to keep environments consistent (brew install implies some are running on osx etc).
        • sulam 2y ago
          I think it’s safe to assume that for something with the scale and complexity of Stripe, it would be a tall order to run all the necessary services on your laptop, even stubs of them. They may not even do that on the dev boxes, I’d be a little surprised if they didn’t actually use prod services in some cases, or a canary at any rate, to avoid the hassles of having to maintain on-call for what is essentially a test environment.
          • aidos 2y ago
• mleo 2y ago
  I use syncthing to manage the synchronization of files between local laptop and remote development server. The software code base is upwards of 20 years and has dependencies on Windows for runtime. I can run unit tests locally on very fast MacBook Pro or run it much slower on Windows VM. With syncthing I can easily edit files locally or remotely and they are available locally for source control. The worst problem is refining the ignore settings to ensure only code is synced preventing conflicts on derivative files and that some rule doesn’t overlap code file names.
  • nxicvyvy 2y ago
    Try unison, it's built for this use case. https://www.cis.upenn.edu/~bcpierce/unison/ https://www.cis.upenn.edu/~bcpierce/unison/
    • shepherdjerred 2y ago
      I like Unison, though I found Mutagen a bit better. https://mutagen.io/ https://mutagen.io/
• mootoday 2y ago
  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-a-half-baked-solution https://mootoday.com/blog/dev-environments-in-the-cloud-are-...
  • numbsafari 2y ago
    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.
    • ParetoOptimal 2y ago
      But then how will they lock you into paying them monthly?
      • numbsafari 2y ago
        They’re just forcing me to stop paying them altogether.
    • mikeocool 2y ago
      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.
• truetraveller 2y ago
  "I’ve described a lot of fairly-involved custom tooling; we needed enough engineers to build and maintain it, and enough “customer” engineers for that investment to pay off." This is so important when deciding to re-invent the wheel. I've gotten bitten by this many times.
• deleted 2y ago
  [deleted]
• p-o 2y ago
  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 https://github.com/pier-oliviert/sequencer) and as I could agree to a lot of things OP said. I think dev boxes is really the way to go, specially with all the components that makes an application nowadays. But the latency/synchronization issue is a hard topic and it's full of tradeoff. A developer's laptop always ends up being a bespoke environment (yes, Nix/Docker can help with that), and so, there's always a confidence boost when you get your changes up on a standalone environment. It gives you the proof that "hey things are working like I expected them to".
  • draw_down 2y ago
    Right, dev boxes do not need to do double duty as a personal computer plus development target, which allows them to more closely resemble the machine your code will actually run on. They also can be replaced easily, which can be helpful if you ever suspect something is wrong with the box itself - if the new one acts the same way, it wasn't the dev box. I don't recall latency being a big problem in practice. In an organization like this, it's best to keep branches up to date with respect to master anyway, so the diffs from switching between branches should be small. There was a lot of work done to make all this quite performant and nice to use. The slowest part was always CI.
    • tmpz22 2y ago
      I feel like we're not getting the right lessons from this. It feels like we're focusing on HOW we can do something versus pausing for a brief moment to consider if we SHOULD in the first place. To me the root issue is the complexity of production environments has expanded to the point of impacting complexity in developer environments just to deploy or test - this is in conjunction with expanding complexity of developer environments just to develop - i.e. web pack. For very large well resourced organizations like Stripe that actually operate at scale that complexity may very well be unavoidable. But most organizations are not Stripe. They should consider decreasing complexity instead of investing in complex tooling to wrangle it. I'd go as far as to suggest both monorepos and dev-boxes are complex toolchains that many organizations should consider avoiding.
• T3RMINATED 2y ago
  [dead]
• crabbone 2y ago
  NB. What the article describes isn't a developer environment in the cloud. It's testing in the cloud. The editor in their model lives on the programmers' laptops, the editing happens there as well and so on. The code is deployed to cloud infrastructure for testing.
• physicsguy 2y ago
  I think for smaller companies, you can get a long way towards a lot of this with judicious use of docker-compose, and convenience scripts in a Makefile. As long as you don't do anything stupid like try and spin up 100 services when you're a team of 8, most laptops these days are sufficiently capable of handling a database, Redis, your codebase, and something like LocalStack.
  • PedroBatista 2y ago
    I would say you can even go a looong way without any Docker at all. And for the large majority of the companies/projects, if your project is so complex and heavy of resources that it doesn't fit on a modern laptop, the problem is not in the laptop, it's in the whole project and the culture and cargo-cult around "modern" software development.
    • vlovich123 2y ago
      Containers/VMs are a nice way to isolate away any machine configuration discrepancies. Conversely it does encourage the use of non hermetic and deterministic build systems which come with other issues too (eg speed differences surfacing race conditions in the build)
    • elktown 2y ago
      - "A single-binary app behind a load-balancer might scale to far beyond our needs, but the promotion/resume trade-off can't be justified."
• adamdecaf 2y ago
  We’ve been using a hundred repositories and a hundred Go services in a local docker-compose setup that’s worked fairly well. CI runners can struggle if their disks can’t keep up with Docker. It comes up that we should make a devprod for front end folks to make the backend abstracted more. Overall a lot of people prefer local dev because it gives them access to the entire stack, lets them run branch images easier, and has better performance than remote boxes. https://moov.io/blog/education/moovs-approach-to-setup-and-testing/ https://moov.io/blog/education/moovs-approach-to-setup-and-t...
• prasoonds 2y ago
  I wonder if there’s a devbox-as-a-service tool out there. I use a MacBook Air for most of my work and on occasion would be benefited by using a beefier machine in the cloud. I just don’t want to set up a machine, set up sync etc.
  • metachris 2y ago
    You could just rent a beefy server for like $40/month at hetzner or OVH and use VS Code with the remote development extension.
• stealthybox 2y ago
  This is an awesome writeup of the tools and culture issues you run into maintaining dev environments. From post, the problems that justified central dev boxes are roughly: 1. dependency / config mgmt / env drift on laptops 2. collaboration / debugging between engineers 3. compute scaling + optimization 4. supporting devs with updates and infra changes The last one is particularly interesting to me, because supporting the dev env is separate engineering role/task that starts small and grows into teams of engineers supporting the environment. I'm helping build Flox. We're working on these pain points by making environments (deps, vars, services, and builds) workable across all kinds of Mac/Linux laptops and servers. 1) a. Virtualize the pkg manager per-project b. Nix packages can install across OS/arch pretty well 2) Imperative actions like `flox install`/`upgrade` always edit a declarative env manifest.toml -- share it via git 3) less Docker VM's -- get more out of devteam Macbooks 4) reduce toil with a versioned, shareable envs --> less sending ad-hoc config and brew commands to people (as mentioned in the post.) Just `git pull && flox activate`. I think on problem point #2, collab tools are advancing to where, pairing on features, bugs, and env issues can be done without central SSH. (ex: tmate, vscode liveshare, screensharing, etc) -- however, that does sort of fall apart on laptops for async debugging of env issues (ex: when devprod is in the US, and eng is in London). Having universal telemetry on ephemeral cloud dev-boxes with a registry and all of the other DNS and SSH goodies could be the kind of infra to aspire to as your small teams run into more big-team problems. In the Stripe anecdote, adopting the centralized infra created new challenges that their devprod teams were dedicated to supporting: - international latency from central, US-based VM's - syncing code to the dev boxes (https://facebook.github.io/watchman/ https://facebook.github.io/watchman/) - linting, formatting, generating configs (run it locally or serverside?) - a dev workflow CLI tool dedicated to dev-box workflows and sync'ing with watchman's clock - IaaS, registry, config, glue for all the servers This is all very non-trivial work, but maybe there's a future where people can win some portability with Flox when they are small and grow into those new challenges when it's truly needed -- now their laptop environments just get a quick `flox activate` on some new, shiny servers or Cloud IDE's. I really like the notes from the author on how useing Language Server Protocol across a high latency link has great optimizations that work along side the watchman sync for real-time code editing.
• vfclists 2y ago
  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?
  • itsjustjordan 2y ago
    Surely in 2024 we can't be classifying Stripe as just "a payment service"
    • bartonfink 2y ago
      What else have they done that's worth giving a shit about?
  • intelVISA 2y ago
    It's a fair question, I think you need ~10 or so to do the work and 990 to bikeshed the horrors that come about when you have what should be a few 3mb HTTPS APIs at $50-100pcm split between 1000 resume-hungry engineers and a taste for cloud complexity.
  • fragmede 2y ago
    probably has something to do with the products that go beyond accepting credit cards listed on https://docs.stripe.com/products https://docs.stripe.com/products, though I suspect operating just the credit card accepting part is harder than you imagine.
• ronef 2y ago
  I love this. I believe I might have even interfaced with your team around that time. I was leading Facebook's (now Meta) Developer Products team and we were building against super similar areas internally. We ran back then a similar project that I coined "Developer On-Demand" to tackle that same problem space. It's also what eventually lead me to find the magics of Nix and then build Flox. I also agree with a lot of what was shared in other comments, while the problems we tackled at large orgs such as Facebook, Shopify, Uber, Google (to name a few teams I remember working with) and obviously also Stripe, certain areas of the pain are 100% universal regardless of team size. On the Flox side, we're trying to help with a few of them today and many more hopefully in the soon future, very open for thoughts! Things like - simple to use Nix for each of your projects + keep deps and config up to date across everyones Macbooks and Linux boxes, etc -- even if you don't have a full AWS team and Language Server team ready to support.
• codethief 2y ago
  Very insightful blog post! > Finally: the development experience, of course, is only part of the story: the full lifecycle of code and features continues onward into CI and code review and ultimately through deployment into production, where it will be further observed, debugged, and evolved. Writing about those systems would require further posts at least this long. In case the author is around: I would love to read those!
• nivertech 2y ago
  This post is more about syncing between local and remote dev environments than about monorepos.