¿Cómo (Diablos) Terminamos Aquí?!

El desarrollo web ha cambiado drásticamente en los últimos 25 años y aunque ahora trabajo como ingeniero de software en JetBrains, me gusta recordar que fue hace unos 15 años cuando comencé con JavaScript y PHP. Abróchense los cinturones y acompáñenme en un viaje por el camino de la memoria hasta donde comencé con el desarrollo web. Hoy en día hay una gran cantidad de IDE disponibles, pero en ese entonces no había una tienda de PHP y recuerdo que tenía que elegir entre Dreamweaver y Eclipse. Siendo un adolescente sin dinero, la elección fue bastante fácil y definitivamente no obtuve una versión correcta de Dreamweaver, así que elegí Eclipse. Sin embargo, esta captura de pantalla no es realmente representativa del pasado porque desafortunadamente no había un tema oscuro. Comencemos escribiendo una versión simplificada de un libro de visitas en un solo archivo. Primero necesitamos un formulario HTML clásico en el que los usuarios puedan completar con sus comentarios. Luego necesitamos obtener los comentarios existentes de una base de datos utilizando consultas MySQL y luego necesitamos iterar sobre ellos para mostrarlos. Hasta ahora todo bien. Finalmente, necesitamos manejar el envío del formulario por parte del usuario y escribir el nuevo comentario en la base de datos. Por supuesto, nada en este código era seguro en cuanto a tipos o seguro contra inyecciones, pero hizo el truco y me permitió presumir frente a mis amigos. Curiosamente, sin mis gafas no podía realmente notar la diferencia entre este código y una aplicación de remix, ya que ambas utilizan la misma estructura que separa el controlador de acciones, el cargador y el contenido real. Ejecutar esto localmente era fácil con XAMP, que era una forma conveniente de ejecutar Apache y MySQL localmente. Implementar este libro de visitas era tan fácil como cargar un archivo a través de FTP. Todo era bastante fácil, a diferencia de los flujos de trabajo de hoy en día desafortunadamente.

Entonces veamos el desarrollo web moderno en comparación. Primero tenemos que seleccionar nuestra biblioteca o framework de UI de elección, ya sea vanilla React o un framework con sabor como Next, Remix o algo diferente como Solid. Por supuesto, hay otras opciones disponibles si estás trabajando con clientes que aún no se han puesto al día. Para nuestra arquitectura, tenemos un front-end que debe implementarse en algún lugar, preferiblemente Vercel o CloudFlare para evitar lidiar directamente con AWS o GCP. El front-end requerirá datos persistentes almacenados en una base de datos para lo cual tenemos múltiples proveedores sin servidor dependiendo de tu elección, siendo Planetscale mi favorito absoluto. La seguridad de tipos y el deseo de una economía de desarrollador decente han llevado a ORM y generadores de consultas como Prisma, Drizzle o Kiesli, que serán nuestras herramientas para comunicarnos con la base de datos. En la era de los servicios sin servidor, también debemos ser conscientes de usar conexiones clásicas a la base de datos o utilizar controladores sin servidor que son compatibles en entornos de borde. Otra cosa más a tener en cuenta. A pesar de todo el discurso sobre los servicios sin servidor, hay ciertas cargas de trabajo como tareas de larga duración que realmente no funcionan en estos entornos y que requieren un backend clásico con estado que podemos alojar en fly.io o railway. No hace falta decir que estos también intercambiarán datos con la base de datos utilizando nuestro ORM o nuestro generador de consultas. Aún no hemos terminado. Las aplicaciones de hoy en día tienen muchas más capacidades, como la autenticación, el registro de eventos en tiempo real y más. Para todo lo imaginable, hay alguna plataforma o servicio útil, pero en comparación con cargar solo un archivo PHP o al menos algunos de ellos en un solo servidor, realmente me pregunto cómo diablos llegamos hasta aquí. La respuesta es bastante simple: dinero. Veo con demasiada frecuencia que las empresas intentan ahorrar cientos de dólares ideando soluciones personalizadas y descuidando que el tiempo que los desarrolladores dedican a solucionar problemas de devops supera con creces los ahorros. Centrémonos en entregar productos y no lidiar con demasiados problemas de devops en el camino, ¿de acuerdo? Eso es todo lo que tengo por hoy. Aquí está mi nombre de usuario de Twitter y disfruten del resto de la conferencia.