¿De dónde viene el stack de Redradix?

Redradix empezó como producto de desecho de Favmonster, la start-up original. Después de consumir lo levantado en las rondas de inversión y tras haber montado un equipo técnico de lujo, teníamos que encontrar una alternativa para monetizar. La primera idea que nos vino a la cabeza fue hacer proyectos para otros, manteniendo la calidad con la que habíamos hecho el nuestro.

De esa forma empezamos a hacer proyectos para terceros, poniendo siempre la calidad por delante. Y en honor a la verdad, diré que el respeto por las buenas prácticas no era algo que hiciéramos solo por el cliente. Cualquier programador que esté leyendo esto compartirá que se disfruta mucho trabajando sobre un proyecto limpio y bien estructurado, en el que se respeten los principios de diseño y cuyo código sea legible, muy legible. Así nos lo enseñó nuestro CTO, Elías Alonso, el mejor programador que he conocido, y así construimos Favmonster. Era nuestra motivación y nuestra alegría, crear código de calidad. Quizás perdiéramos algunas horas de más discutiendo sobre la mejor forma diseñar un esquema de base de datos o el diseño de una API, y tal vez la conversación divagaba ligeramente, pero nuestros productos salían a producción con cero errores.

Por aquel entonces teníamos dos referentes: Thoughtbot y Basecamp. Thoughbot era una agencia digital que promovía las buenas prácticas y hacía unos proyectos de diez. Basecamp, por su parte, tenía una cultura de equipo innovadora muy people centric, que se alineaba muy bien con nuestra forma de pensar de aquel entonces. Ambos compartían Ruby como lenguaje de programación y Rails como framework. RoR era casi una religión en aquellos tiempos; tenía sus mandamientos sobre buenas prácticas y su legión de fervientes devotos. Nosotros éramos parte de esa legión.

Pasaron un par de años y el reinado de RoR fue cayendo. En mi opinión gran parte de la atracción irresistible de ese framework sobre los programadores de talento cayó debido a las Single Page Application (SPA). Además la supraconciencia de Javascript se estaba organizando. Entre otras muchas cosas se estaba poniendo cariño en las especificaciones del lenguaje, la comunidad estaba aumentando (así como su talento), estaban surgiendo frameworks que daban mucha estructura al código front y en back-end había un nuevo player que estaba rompiendo esquemas: Nodejs.

Tal vez fue un error dada la complejidad accidental de las SPAs, pero no dimos mucha opción a nuestros clientes. Fue una transición breve, pasamos de Ruby a Javascript en un abrir y cerrar de ojos. Sin desmerecer Jquery y lo mucho que aportó, estábamos acostumbrados a spaguetti code, y Backbone nos conquisto. La modularización del código y el control de eventos nos permitía tener la complejidad de la lógica front controlada. Además era muy ligero, y eso nos encantaba. Podíamos debuggear el código de la librería (porque eso es lo que era) y entender cómo funcionaba por dentro.

Poco antes añadimos al equipo la disciplina de maquetación. La motivación fue clara: Redradix tienes que hacer lo que te guste para hacerlo bien. Y a ninguno nos gustaba maquetar. Si a eso añadimos que creemos en la especialización, obtienes la fórmula que hemos mantenido hasta el día de hoy: profundización de conocimientos en un mismo stack y especialización por disciplinas.

Esa profundización es la que evitaba que picásemos de flor en flor e hizo que nos especializáramos con Backbone. A pesar de ello, en nuestros ratos libres, trasteábamos con todo lo que salía dentro del ecosistema Javascript (incluso fuera de él, como cuando casi migramos todo el stack a Lisp, pero eso es otra historia). Desde el primer contacto, Angular nos dio náuseas. Un monolito como ese violaba todos los principios de diseño y no nos daba libertad para hacer las cosas como considerábamos correcto. Iba en contra de todas nuestras creencias y a día de hoy seguimos rechazando cualquier proyecto en ese framework. Algo muy distinto ocurrió con React.

De nuevo Elías vino a poner nuestro mundo patas arriba. Un buen día nos presentó su disección sobre una librería que llevaba menos de tres meses live, cuyo concepto era muy simple y además cuadraba con un paradigma que siempre habíamos considerado superior, la programación declarativa. Su nombre era React. Además hacía solo una cosa (respetaba SRP) y lo hacía muy bien: la construcción de interfaces. Entre otros beneficios, nos gustó que aportaba claridad al código, velocidad de desarrollo y que se fundamentaba en la orientación a componentes, algo que era un must en todos nuestros proyectos en los que seguíamos los principios de Atomic Design de Brad Frost. En cuestión de una hora el equipo votó unánimemente cambiar de framework. Y en dos semanas habíamos migrado los tres proyectos que teníamos en marcha. Eso es lo que llaman abrazar el cambio, ¿no?

A día de hoy este stack permanece. Pese a que han salido muchos frameworks y lenguajes interesantes no hemos encontrado nada que se adapte tan bien a nuestro proceso y a las necesidades de nuestros clientes. Sí que vamos evolucionando ciertas librerías del ecosistema. Hemos pasado por Thunks y Sagas hasta llegar a React Query y el contexto de React. Hemos tonteado con la programación funcional, desde Mori a Rambda. Y hasta hemos creado nuestra propia capa por encima de Redux para evitar boilerplate imitando las estructuras de Redis: Reducen.

Nuestra especialización en maquetación es un orgullo y una diferenciación. Puedo decir sin dudarlo que tenemos uno de los mejores equipos de maquetación de España. No solo por la calidad de lo que hacemos, sino por los entregables que la disciplina genera y las facilidades que aporta al equipo de desarrollo. Utilizamos Storybook integrado en el mismo repositorio donde trabaja el equipo de desarrollo. Principalmente trabajamos con Sass porque todavía no hemos encontrado ningún CSS in JS que nos haya enamorado.

En el back no hemos evolucionado mucho. Nos gusta hacer las cosas de cero, basándonos en Express o en algún framework muy minimalista. Creemos en las arquitecturas emergentes y huimos de la sobreingeniería. No creo que haya un stack perfecto para todos, pero éste es el que nos funciona a nosotros. A nuestro proceso y a nuestra filosofía. Y es con el que desarrollamos todos nuestros proyectos. Eso sí, si mañana sale algo que consideramos mejor, seguro que seremos pioneros.