Voy a comenzar otro proyecto. Sí, otro. Pero espero no abandonar este porque no me haría gracia abandonarlo. Este tiene un sentido importante para mi, pero no es la primera vez que lo comienzo. ¿Te quedas y te cuento?
Una necesidad, una solución.
Mi padre lleva muchísimos años en el fútbol. Nunca tuvo interés en su juventud (era más de artes marciales), pero llego una persona especial que le transmitió los valores y el forismo por el que se vive y respira fútbol. Desde esos momentos, empezó a jugar en las peñas deportivas y, luego, pasó a un rol de entrenador de estas peñas para darle oportunidades a la gente que le apetece echar un rato los domingos sin tener que ser super mega profesionales.
Desde hace muchos años, mi padre usa un software de gestión muy bueno que se le está quedando obsoleto por no poder actualizarlo. Se puede actualizar, tiene versiones nuevas (e incluso nueva versión web/cloud), pero tiene un coste al año. Coste que no puedes pedirle a una peña que juega de forma desinteresada y que, con los pocos ingresos/aportaciones que pueda recibir de un sponsor para la equipación de ese año, no entra en los planes y se puede destinar ese dinero a otros apartados más importantes. Y, además, el software funcionaba, pero ya está explotando. A tal punto que este año ha decidido borrar toda la información y no poder hacer el traslado de información de la temporada anterior a la nueva. 😢
El año pasado empecé este proyecto. Sistema WordPress con diseño Metronic donde me tiré un par de días para empezar y montar algo base. Metronic ha mejorado con el paso de los años, se ha componetizado para frameworks reactivos, pero yo seguía full plain html y montado en WordPress. Total… que abandoné. A pesar de que empecé con muchas ganas, llegaron muchas problemáticas que no me dejaron continuar. No por WordPress o por Metronic, sino porque yo no empecé a plantear las cosas. Me envalentoné y me puse a desarrollar de golpe y porrazo. Acabé hundido y sin ganas de más. Encontré la solución de arreglarle a mi padre el famoso software y aguantó un año más.
Pero vamos a aprender de nuestros errores. Vamos a coger la experiencia del año pasado, vamos a ir paso a paso y vamos a documentar todo lo necesario para empezar el proyecto, completamente desde cero, con nuevas tecnología y con ganas de hacer cosas
El stack de desarrollo: ¿qué vamos a usar para desarrollar este proyecto?
Vamos a empezar el tejado por la puerta. Vamos a elegir primero la base con lo que vamos a trabajar. Quiero que quede claro del principio, hacer una apuesta por aprender cosas nuevas, manejarse en una jungla sin explorar, pero tener cosas claras y fuera de nuestra zona de confort. ¿Por qué haríamos esto? Te doy mis razones:
- No me quiero aburrir tan fácilmente: sé que esto es un arma de doble filo. Pero tener un stack diferente al que usas es algo que te da una cosita por dentro de tener ganas de trabajar y crear cosas nuevas. Vamos a decirlo claro: esto es el aliciente para sacar cosas. Porque cuando funcionen cosas, vas a querer seguir haciendo cosas. Además, vas a aprender cosas nuevas que podrás adaptar en otros apartados y proyectos, vas a tener nuevos retos y puede ser algo divertido con lo que reventarse la cabeza.
- Aprendizaje pre-mortem: no puedes aumentar tu expertise si no te sales de tu zona de confort. Eso es así siempre. Por supuesto, no tienes por qué estar siempre fuera. No tienes por qué estar haciendo side-projects en tu tiempo libre, no es obligatorio. Te ayuda a descubrir cosas que no verás en tu trabajo, ver cosas nuevas, afrontar problemas. Esto te ayudará de una forma u otra.
- Desconectar un poco de la rutina: plantear nuevas utilidades o herramientas es una forma de limpiarte y refrescarte de lo que siempre haces. Lo vas a hacer sin timelines ni de forma forzada o apresurada. Aquí tienes la tranquilidad de hacerlo como quieres y sin nadie que te diga o exija a limitarte.
¿Pero Adam… me has dicho la misma cosa tres veces? Lo sé. Para que te quede claro del por qué. Vamos con el stack, que se me hace tarde.
Gestor de contenido: Strapi
Descubrí Strapi en un directo de Midudev que me dejó con ganas de probarlo al máximo. Ofrece muchísimo y con muchas oportunidades de hacer cosas chulas. Integración con GraphQL, tipos de dato de fácil preparación, relaciones entre ellos y un panel bastante limpio.
Creo que será perfecto para tener controlados todos los tipos de datos (que no serán pocos) y lo utilizaremos con headless para que nuestro front-end se comunique como un campeón.
Utilizaré la base de datos con MySQL, ya que lo colgaremos en un servidor propio donde ya tenemos este método. Al menos, para sentirme un poco más «confiado», elegiré MySQL para poder ver la base de datos de forma rápida con Sequel Ace/Pro y ver cómo monta los datos. No es que me deba super de interesar esto porque, al fin y al cabo, esto ya lo va a hacer Strapi. Pero por «cacharrear» y ver qué hay ahí.
Además, se integra a la perfección con el siguiente tema que vamos a tratar: con qué vamos a hacer el front-end.
Front-end: Next.JS
Mi pelea con los reactivos ya empezó hace mucho tiempo. Tuve hasta un par de meses con el síndrome del impostor porque parecía que entendía y no entendía al mismo tiempo. Mi problema fue que entré en el peor momento. Con el avance de estos frameworks reactivos, le meten nuevas formas de hacer las cosas, nuevas técnicas, hooks, renderizados específicos… Un caos si no tienes una base buena. Y estar justo cuando acaban de meter apartados nuevos… chungo si quieres algo claro. Toda la documentación está sin actualizar, no está del todo claro explicado, los tech influencers están probando… Hay de todo.
Pero esta vez pues ya tengo un poco más de soltura en React, ya he entendido bastante cosas y NextJS ya tuvo un sitio en mi huecsio de side projects en el que he puesto en stand-by hasta que tenga más conocimientos con esto. Mi forma de aprender es ponerme un reto, pero hay veces que mi falta de conocimientos de arquitectura del software o de buenas prácticas para componentes muy avanzados me lastra. Pero hemos venido a jugar.
Elijo NextJS porque me parece muy interesante y tengo los conceptos claros que quiero hacer. Sus funciones de Router y buenas prácticas creo que me vendrán perfectas para este front-end específico. Y así pillarle práctica para futuros proyectos con headless WordPress que tengo ahí. (Porque me apetece mucho cortarle la cabeza a algunos de mis proyectos con mucha info en el front).
UI: Ant Design (AntD)
Ant Design llegó a mi por el curioso slogan que tienen del «segundo framework de UI para React del mundo». Tiene gancho. La verdad es que fui de cabeza a ver de qué se trataba porque me enganchó. Lo descubrí en la extensión de daily.dev que la recomiendo muchísimo para estar informado en general de todo.
Pero es que la verdad que Ant Design me parece precioso y elegante. Limpio y estético: perfecto para este proyecto. No quiero otra mega librería gigantesca de clases para copiar y pegar y liarla para al final no hacer nada. Ofrece mucho contenido, lo actualizan y decidí cogerlo. Por supuesto que hay muchas alternativas como chakra, MUI o el interesante (en beta al escribir esta entrada) NextUI. La idea es coger uno y adelante.
Y de beber, albóndigas.
Y que nos tenemos que poner manos a la obra ya de ya de ya.
Este diario empieza aquí vamos a ver cómo montamos las cositas chulas. En las siguientes entradas, veremos cómo vamos a estructurar los datos, cómo instalamos y preparamos nuestro stack de desarrollo y cómo iremos avanzando. Iré dejando un «menú» al principio según vayamos escribiendo para tenerlo todo organizando. Empezamos y espero que no se resientan estas ganitas.
¡Vamos, a por todas!