> people are using them for their dev environments [?]
Yes, we use a container for dev environment so that we can share the same env across all the team. If it's decided that we need 1 more tool in our toolbox, the script that generates the container is updated (the script is version controlled in the repo too), the CI/CD generates a new container version, all the devs can now use the same NEW environment.
We actually use the container as image for (remote) virtual machines, so we don't really compose multiple containers.
The container has all the tools (for several languages) that we use as a team.
IDEs and debuggers can connect through ssh.
> post-development workflow do you ever use separate containers for build and test?
We build different flavors of the final packaged application, for example:
Mostly payload and Airborne time.
Idk what is the current status of Zephyr (google search suggests 26 days?) but Loon balloons were consistently reaching 300 days of airborne time.
This is basically the value proposition of Firebase & Supabase (they grew up to offer more than that, but DB as BaaS is their main product).
Regarding just using raw postgres sockets, the CONS is that it gets harder to code the client in javascript (I don't think webassembly can handle sockets yet?)
Security-wise, it can actually be done (see how firebase handles security) but you need a way (API layer? StoredProcedures?) to verity auth tokens (like JWT) sent from the clients
Thanks for sharing your experience! I can see how you were struggling trying to handle different "versions" in subsets of the repo.
In my experience the "monorepo" workflow implies a "working on master/head" mindset, but this is not always the best approach depending on your specific needs.
> I had a number of frustrations with that.
Could you elaborate more? The OP had to split the monorepo due to https://getcomposer.org/ limitations (each package needs it's own repo it seems). What other issues have you found when working with a monorepo? Thanks!
Congrats on the launch! really like the concept.
I actually worked on a company where the entire team was working on the rhythm (focus/pause/focus...) of a shared pomodoro timer (a physical one!). It was super productive. Now that we all work remotely your concept is very intriguing.
I wonder if you could remove some requirements (camera, introductions, slot booking) and still have accountability benefits from having other people sharing your focus time.