3 ms·

I think one should aspire to not have to make use of a container to get to where you can build a project. I don't think it is productive to start off by telling

• tuetuopay 2y ago
  I will even add that cargo already provides local dependency isolation without external tools, like Poetry for python. In my experience, a docker-compose to setup required services like a database or a rabbitmq broker is much more useful. Mandatory containers for dev end up locking the project in them, making the environment hard to change
  • bborud 2y ago
    I usually take it one step further: embed services that are typically external by default so that your application can run stand alone in a useful minimal, zero configuration configuration. It is a huge timesaver during development not having to orchestrate lots of moving parts and make sure they are in the correct state. And if you can embed the actual implementations you will be using in production instead of mocks or substitutes, even better. For production you will usually run against external dependencies - but not always. For a surprising number of backends I've written in the past decade, embedded resources have turned out to be good enough. For instance, lots of backends I've written with very modest database requirements just use SQLite. Back when I was developing in Java embedding dependencies was a bit easier since a lot of the infrastructure we used was also written in Java. What used to be slow integration tests became really fast integration tests (indistinguishable from regular unit tests) and you could build all-in-one-jars that people who need to integrate with you could just download and fire up without needing anything beyond a JVM. If you are on the receiving end of someone else's server software this is lovely because it makes your job easier. I always embed a default database with any application or server that needs a database. Now that I mostly develop in Go, I use the transpiled SQLite library (transpiled to Go so you don't need to use cgo. It is possibly a bit slower and I'm unsure about its suitability for production, but for development work it is brilliant). In Java there were a couple of embeddable database alternatives to choose from. I usually plan to use PostgreSQL (or RDS or similar cloud DB) in production. Even after I add PostgreSQL support I tend to leave the SQLite in as the default, "zero config" option. It is particularly useful when someone else needs to integrate with your server that they can just download and run it without having to know how to configure it. Usually people just need something to test against when integrating with APIs or similar. If you're really nice to other developers, you also provide some instructions on how to embed your server. So that people using it can just instantiate your server in integration tests. This usually makes for faster and more convenient tests that developers will be more inclined to run on every rebuild. (For speeding up integration tests I wrote https://github.com/borud/drydock https://github.com/borud/drydock a few years ago as an experiment. After you've run it once, it makes testing against PostgreSQL much faster and it only requires that you have Docker running. It takes care of everything for you. I seem to remember that someone else ran with the same idea and wrote a better tool for this than mine, but I can't remember who. This removes messing with Docker out of the build loop, but it may not be to everyone's liking if they prefer to manage docker from some build tool)
    • afiori 2y ago
      I guess that there would be a few incompatibilities, but you could even try directly embedding postgres https://supabase.com/blog/postgres-wasm https://supabase.com/blog/postgres-wasm
      • bborud 2y ago
        We live in exciting times :-)