José Luis Pamplona Stoever

Cada función que se añade a un proyecto es un cartucho con sus papeles: qué instala, qué necesidad responde y por qué está hecho así, con sus fuentes. El cartucho le da forma a ese conocimiento: una pieza con nombre y portada a la que se asocia lo aprendido, lo que facilita entender una solución, recordarla y dejarla registrada. Es el mayor valor de DEW.

Costo. Escribir un cartucho pide Elixir avanzado, y hoy tener cartuchos propios obliga a hacer un fork de DEW. Lo siguiente es una colección pública de cartuchos, fuera del repositorio.

Cómo se escribe un cartucho

Cada paso de mix y de git corre en un contenedor, y la consola reúne el flujo de trabajo que antes vivía en el host: el servidor, los logs, la terminal, las pruebas. Lo que el proyecto necesita alrededor, como la base de datos, su administrador o el monitoreo, llega también en contenedores: no se instala ni se configura nada en la máquina. Se trabaja igual en cualquier equipo: basta con tener Docker y clonar el proyecto.

Costo. Toda la línea de comandos es un script de bash de unas 3 500 líneas. Es el precio de que el host solo necesite Docker y una shell.

El banco y su espacio de trabajo

En Phoenix, la base de datos, el HTML o el correo se eligen una sola vez, al crear el proyecto. En DEW cada una es un cartucho como los demás: se puede añadir después, y otros cartuchos pueden depender de ella, como el administrador de base de datos, que pide ecto.

Para lograrlo, cada uno de estos cartuchos genera el proyecto dos veces, con y sin su opción, en la versión de Phoenix con que nació, y fusiona solo la diferencia sobre el proyecto tal como está hoy. La prueba: un proyecto nacido sin nada y crecido cartucho a cartucho tiene que quedar igual, archivo por archivo, al que nació con todo.

Costo. El proyecto tiene que guardar con qué versión del instalador de Phoenix nació, y DEW tiene que poder volver a ejecutar esa misma versión.

El papel de diseño

Ni una ruta, ni un archivo, ni una marca existen en un proyecto solo para que DEW los lea. Un proyecto se independiza de DEW en cualquier momento: basta con dejar de usar wb.sh.

Costo. Como el proyecto no guarda nada para DEW, DEW tiene que deducir su estado cada vez, leyendo el código, Docker y git.

Por qué tiene esta forma

Un proyecto nuevo de Phoenix busca su base de datos en localhost, y dentro de Docker eso normalmente deja de funcionar. En DEW, la aplicación y sus servicios comparten una misma red interna (un pod), así que localhost sigue siendo válido y la configuración no se toca.

Costo. En desarrollo, la aplicación tiene que escuchar en 0.0.0.0: es la única línea de configuración que DEW cambia. Y el pod no admite réplicas, porque compartirían dirección: el despliegue escalado se levanta como producción, en una red bridge, con sus variables de entorno definidas en el archivo de Docker Compose.

Por qué tiene esta forma