José Luis Pamplona Stoever

Every feature added to a project is a cartridge with its papers: what it installs, the need it answers and why it is built that way, with its sources. The cartridge gives that knowledge a shape: a piece with a name and a cover that what was learned gets attached to, which makes a solution easier to understand, to remember and to keep on record. It is DEW's greatest value.

Cost. Writing a cartridge takes advanced Elixir, and today having cartridges of your own means forking DEW. What comes next is a public collection of cartridges, outside the repository.

How a cartridge is written

Every mix and git step runs in a container, and the console gathers the workflow that used to live on the host: the server, the logs, the terminal, the tests. What the project needs around it, such as the database, its admin tool or the monitoring, also arrives in containers: nothing is installed or configured on the machine. Work is the same on any computer: having Docker and cloning the project is enough.

Cost. The whole command line is a bash script of about 3,500 lines. It is the price of the host needing only Docker and a shell.

The workbench and its workspace

In Phoenix, the database, the HTML or the mailer are chosen only once, when the project is created. In DEW each one is a cartridge like the rest: it can be added later, and other cartridges can depend on it, like the database admin, which requires ecto.

To make that possible, each of these cartridges generates the project twice, with and without its option, at the Phoenix version the project was born with, and merges only the difference into the project as it stands today. The test: a project born with nothing and grown cartridge by cartridge has to end up equal, file by file, to one born with everything.

Cost. The project has to keep which version of the Phoenix installer it was born with, and DEW has to be able to run that same version again.

The design paper

No route, file or marker exists in a project only for DEW to read. A project becomes independent of DEW at any time: it is enough to stop using wb.sh.

Cost. Since the project keeps nothing for DEW, DEW has to work out its state every time, by reading the code, Docker and git.

Why it is shaped like this

A new Phoenix project looks for its database on localhost, and inside Docker that normally stops working. In DEW, the application and its services share one internal network (a pod), so localhost stays valid and the configuration is left untouched.

Cost. In development, the application has to listen on 0.0.0.0: it is the only line of configuration DEW changes. And the pod takes no replicas, because they would share one address: the scaled deployment runs like production, on a bridge network, with its environment variables set in the Docker Compose file.

Why it is shaped like this