Dymmer: Cómo se hizo

Diciembre de 2018 fue un mes bastante prolífico porque además de lanzar el Libro de Elixir lanzamos también la web de Dymmer para la gestión de dominios y zonas DNS, ¿quieres saber qué es y cómo se hizo?

La idea de realizar un sitio web para gestionar dominios rondaba por la empresa desde 2011, en aquél momento la idea era proveer a los usuarios de un servicio parecido a DynDNS que permitía generar un nombre de host asociado a un dominio genérico y una API para poder modificar la IP ya que se entendía que generalmente sería para apuntar a sitios albergados en conexiones particulares con direcciones IP dinámicas.

El blog de Altenwald nació en uno de estos dominios bombadil.es.vg y más tarde bosqueviejo.dynalias.net que llegaría a ser finalmente bosqueviejo.net, más tarde adquiridos bosqueviejo.es, bosqueviejo.com, bosqueviejo.org y traducidos al alemán para generar altenwald.com y altenwald.org.

Pero lo más importante...

¿Qué es Dymmer?

A día de hoy Dymmer ha evolucionado para ser un agregador de dominios que te permite seleccionar el proveedor y gestionar todo desde una única interfaz. De esta forma si te pasa como a mi que compras dominios de muchos proveedores, finalmente a través de Dymmer puedes gestionar todo esto pagando solo una factura y centralizando todo.

Pero no solo eso también es una potente herramienta para configurar tu zona DNS, redirecciones de email y buzones de correo electrónico. Esto no solo te proporciona el control para gestionar desde una interfaz tu zona DNS, sino también crear y controlar tus cuentas de correo electrónico.

En un futuro próximo además, Dymmer te permitirá...

• Gestionar tus hostings, es decir, decidiendo entre distintos proveedores podrás contratar máquinas de Amazon Web Services (AWS), DigitalOcean, Scaleway, Vultr, Hetzner y OVH entre otros para configurar registros DNS apuntando directamente a estos.

• Usar Dymmer desde CLI y API, además de la interfaz podrás integrar Dymmer muy fácilmente dentro de tu aplicación de despliegue continuo, herramientas de desarrollo o directamente desde consola para gestionar todo lo que puedes gestionar desde la interfaz web.

• Importación/Exportación de ficheros de Zonas, estamos trabajando también en proporcionar un editor de zonas que te permita con un editor enriquecido de un vistazo ver la configuración completa de tu zona y modificarla en un solo paso modificando el fichero.

Estamos abiertos a sugerencias por lo que si estás interesado en otra característica que ves fundamental o que necesitarías para plantearte el salto a Dymmer, puedes dejarnos un comentario o enviarnos un mensaje privado.

Ahora vamos a lo interesante...

¿Cómo se hizo Dymmer?

Usando git hours el sistema me da que he realizado 191 commits y 173 horas aproximadamente. Invertidas principalmente entre octubre y noviembre de 2018 serían unos 22 días a groso modo o un mes laboral. Tengo que decir que no partí desde cero porque antes diseñé de esta forma las pantallas que quería implementar (estos fueron diagramas que envié a José Manuel Montero en verano de 2016) y fuimos trabajando en ellos de cuando en cuando hasta obtener la versión HTML, CSS y JavaScript necesaria para comenzar la implementación:

El desarrollo pasó por bastantes fases. En principio decidimos implementar una API y sobre esta API un framework basado en Angular. También barajamos la posibilidad de en lugar de Angular emplear Elm y así aprender un lenguaje funcional para navegador y su integración con Phoenix Framework. Obviamente el backend no podía desarrollarse en otra cosa que no fuera Phoenix Framework y Elixir junto con una conexión a base de datos donde volvía emplear PostgreSQL con BDR tal y como hice anteriormente con Altenwald Books.

Infraestructura

La parte de DNS y email de momento reutilicé la configuración de bind9 del antiguo DynHOST y también postfix y dovecot para la configuración del servicio de correo electrónico y por último let's encrypt para los certificados.

A nivel de infraestructura en este año me gustaría poder cambiar a DNS Erlang el cual ya estuvo probando a fondo Guillermo hace un par de años y pensamos en implementarlo desde primera hora pero no hubo mucho tiempo para dedicarle. También y por fin, sería de desear para este 2019 poder contar con Skirnir para la gestión de correo y así quitar algunas cosas que ya no funcionan tan bien como antes.

Integraciones

Es usual y necesario realizar integraciones en todos los desarrollos web. Tarde o temprano necesitaremos algo que no formará parte de nuestro núcleo de negocio y que hacen otras plataformas mejor. Pero además, Dymmer se basa en integrar otros servicios no solo para el pago sino también para adquirir dominios. Las integraciones realizadas hasta el momento son:

• Mailgun: sí, la gestión de correo electrónico transaccional es bastante importante y lo mejor es que esté gestionada desde algún sistema que pueda controlar no solo los envíos que se realizan sino muchas más cosas.
• ReCaptcha: para el registro creo que es indispensable evitar el ataque indiscriminado de bots y el uso de recaptcha es ideal para esto.
• Slack: la mayoría de acciones que se realizan en el sistema, además de generar una o varias líneas en el log, generan un mensaje en Slack para tener constancia de qué pasa a cada momento en la plataforma. De momento como el sistema está en un estadio inicial, su primera versión y pocos usuarios es genial de cara a soporte. Saber qué falla o qué acciones se están llevando a cabo, dónde pueden surgir mayores problemas y qué optimizar.
• PayPal: de momento y aunque en algunos pasos pueda suponer una pequeña barrera, hasta contar con más medios de pago el único que está implementado a día de hoy es PayPal. No obstante se está negociando con otras plataformas para integrarlas lo antes posible y hacer la experiencia de pago más liviana.
• Netim: uno de los mayoristas proveedores de dominios que integramos en la plataforma.
• Resellbiz: otro de los mayoristas de proveedores de dominios integrados.
• Akismet: para controlar un poco el formulario de contacto. A diferencia de otras plataformas esta información no va a nuestro buzón de correo, sino que va directamente a un canal comercial en Slack pero antes, se filtra un poco a través de un módulo que publicaremos en breve y Akismet.

En un futuro cercano agregaremos más proveedores de dominios (aún estamos en negociaciones con ellos) y como mencioné más arriba, más proveedores de pago.

Además de momento no tengo implementada en la web principal ni AddThis ni Google Analytics lo cual seguramente remediaré agregando uno o ambos en las siguientes iteraciones.

Gestión de Usuarios

Esta vez los desafíos eran realizar el registro de usuarios, crear sesiones y mantener seguridad para las pantallas donde el usuario debe ver su contenido.

Para esto decidí emplear Coherence. Hubo que realizar algunos ajustes mínimos y aún seguimos aportando en cosas que se pueden mejorar pero el sistema es genial porque proporciona sin necesidad de hacer nada:

• Registro de usuarios por alta o por invitación (con su correspondientes facilidades para la gestión de invitaciones) además del sistema para verificar la identidad del usuario a través de confirmación de email.
• Inicio y cierre de sesión con control de reintentos y bloqueo de usuarios.
• Reestablecimiento de contraseña.
• Cambio de contraseña durante la sesión.
• Sistema integrado para enviar emails vía proveedores como mailgun por ejemplo.
• Sistema de comprobación de sesión para no permitir acceder a interfaces cuando no existe sesión.

La instalación del esqueleto inicial es bastante fácil y casi que funciona todo desde el primer momento sin necesidad de muchos cambios.

Integraciones: Proveedores de Dominios

Después de esto agregué todo el código de integraciones añadiendo las propias para PayPal, Netim y Resellbiz principalmente. Las otras integraciones apenas requirieron modificaciones al copiar la parte importante del código desde Altenwald Books pero Netim y Resellbiz hubo que implementarlas desde cero agregando una interfaz agnóstica para cada una de ellas que proporcionase el nivel de abstracción necesario para emplear cualqiera de las dos una vez se selecciona el proveedor. De esta forma tengo estos módulos:

• Dymmer.Domain para el esquema de base de datos donde se guarda cada dominio y se especifica el proveedor.
• Dymmer.Domain.Netim donde se especifica de forma agnóstica la implementación de las funciones para acceder a la API de Netim.
• Dymmer.Domain.Resellbiz donde se especifica de forma agnóstica la implementación de las funciones para acceder a la API de Resellbiz.
• Dymmer.Api.Netim donde se implementa la API completa de Netim.
• Dymmer.Api.Resellbiz donde se implementa la API completa de Resellbiz.

Todos los módulos bajo Dymmer.Api están implementados usando principalmente Tesla lo cual facilita y simplifica enormemente la implementación.

Integraciones: Pagos

Aunque de momento la implementación del pago se ha realizado únicamente con PayPal he querido realizar de forma agnóstica el tratamiento de los pagos para poder implementar en un futuro nuevos procesos de pago. Estos procesos harían uso del módulo Dymmer.Payment como base y se implementarían como PayPal de la forma Dymmer.Payment.PayPal haciendo uso de una interfaz común y agnóstica (dentro de lo posible) para interactuar después con Dymmer.Api.PayPal.

Aún así, en estos casos se presenta otra problemática porque el flujo de pago para PayPal requiere de ir a otra web y al volver se provee información que hay que verificar. Obviamente otros métodos de pago se implementan de formas diferentes. Habrá que ir viendo cómo evoluciona esto en un futuro.

Internacionalización

Todas las webs corporativas que he realizado (Altenwald y Bragful entre otras) han sido configuradas con varios idiomas (inglés y español principalmente). El sistema de internacionalización empleado ha sido el provisto por Phoenix Framework: gettext.

Gettext proporciona un conjunto estándar de ficheros .pot y .po empleados desde hace muchos años por otros sistemas como lenguaje C. Además disponemos de dos tareas en mix para ayudarnos a extraer todas las cadenas y generar los ficheros .pot e incluso mezclar estos ficheros finalmente en los ficheros destino .po según los idiomas que queramos o necesitemos implementar.

Puedes emplear el editor de ficheros PO que más te guste después para editar y traducir los textos.

Páginas legales

Esto siempre es un trastorno tener que escribir todo el texto legal. Además hacerlo en dos idiomas. Finalmente decidí dar otro enfoque y escribir toda esta información en ficheros Markdown. A través de una extensión de Phoenix Framework llamada phoenix_markdown el sistema permite escribir ficheros con este formato y convertirlos en tiempo de compilación a HTML.

Programación de tareas

Hay muchas acciones como la supervisión de los estados de los dominios, generación de facturas, comprobación del balance de los proveedores de dominios, etc. Estas actividades están programadas dentro del sistema a través de la extensión cronex. Esta extensión como su nombre indica permite configurar acciones a realizar en un determinado momento y con una determinada frecuencia (al igual que cron).

Consultas, Llamadas, Umbrales, Límites y Caché

Uno de los problemas al realizar este tipo de software es la cantidad de límites que establecen los proveedores para evitar ser atacados. Esto nos obliga a controlar desde nuestro lado también no exceder estos límites y proporcionar sistemas que permitan ser más eficientes.

Por ejemplo obtener el precio de los proveedores se realiza a través de llamadas bastante costosas. El tiempo para obtener esta información es bastante alto y esto se mezcla a la limitación de los proveedores para que no realicemos más de un específico número de llamadas por minuto.

La solución para este caso específico fue emplear Nebulex, un sistema de caché interno para Elixir que nos proporciona caché a nivel de nodo. Además mezclado con Lambda Throttle, otra librería de Erlang que nos da la posibilidad de limitar (retardando) las llamadas a ciertas funciones, nos garantiza mantener una cadencia.

Gracias a estos sistemas mantenemos la base de datos libre de estos datos temporales y nos aseguramos de que nuestro sistema es plenamente responsable a través de estas técnicas de no saturar a los proveedores y mantener el nivel de servicio óptimo.

WhoIs...

Otro de los grandes dilemas a la hora de dar de alta zonas (que no dominios) es si permitir o no dar de alta esa zona. Es decir, si ese dominio no pertenece al usuario y algún otro usuario al que sí pertenece quiere transferirlo al sistema, se produce ahí una colisión.

Mi forma de evitarlo es exigir siempre la correcta configuración y comprobarlo a través de whois. De esta forma si los nameservers configurados para el dominio son los proporcionados por Dymmer la zona se puede crear sin necesidad de comprar o transferir el dominio.

No obstante el sistema español de dominios (.es) no facilita el acceso mediante whois a sus servidores. Para poder realizar esto hay que realizar un proceso, el cual comencé en noviembre de 2011 y puedo ver que sigue en el estado en tramitación.

La parte positiva es que las transferencias de los dominios .es son gratuitas. Al menos mientras no cambien el sistema en red.es.

Tests

Esta vez quise comenzar con buen pie en el tema de los tests. Cuando integré completamente coherence me aseguré de tener un test para cubrir cada característica y a medida que realizaba cambios y antes de subir los cambios a producción siempre he ejecutado los tests para asegurar la calidad del código cubierto.

A día de hoy no he sido muy estricto y tan solo el 40% del código pero hay tests para todo lo relacionado con la gestión de usuarios, dominios y direcciones de email tanto redirecciones como buzones. Me queda agregar muchos casos de error y algunas funcionalidades que omití por ser muy simples de comprobar.

Conclusiones

Me extendí ya bastante. Solo me queda ver que ha sido un trabajo bastante arduo hasta llegar a la definición final y un trabajo bastante fluido una vez estuvo todo definido y listo para ser implementado. No obstante tengo que decir que desde el diseño a la implementación final obviamente hubo cambios que tuve que discutir conmigo mismo. Una dura negociación. En base a considerar si el tiempo extra en invertir en esos cambios compensaría por el cambio en sí. Algunas de las veces acepté realizar el cambio y otras veces lo moví como modificación al backlog para realizarlo en un futuro.

Se puede ver también que aún queda mucho por hacer. Me motiva bastante el proyecto y quiero seguir haciéndolo crecer pero antes prefiero hacer un alto, escuchar opiniones y planificar los siguientes cambios no solo por lo que pueda considerar sino por las necesidades reales que los usuarios puedan tener.

Estamos en el punto que necesitamos early adopters por lo que si estás interesado/a, haz un comentario o envíanos un mensaje directo y te incluiremos en el programa obteniendo mejores precios para los dominios y ampliando los límites de lo que puedas crear sin necesidad de pagar nada mensualmente.

¿Te apuntas a probar Dymmer? ¡Déjanos tu comentario o envíanos un mensaje directo!