En la industria del software históricamente hemos utilizado los términos frontend y backend para dividir dos mundos de la programación. La tecnología cambia a pasos agigantados y la realidad de un desarrollador de hace 10 años es muy distinta a la actualidad. Aún así, seguimos usando esta frontera entre backend-frontend para dividir equipos, proyectos o, incluso, una misma aplicación a través de una barrera en muchos casos de forma artificial.
Vamos a repasar ambos términos, qué implicaciones tienen y, sobre todo, el uso en torno a ellos según evoluciona la industria del software con una mentalidad más fullstack.
La primera división entre ambos términos: frontend vs backend
Si nos fijamos en la definición estricta: un programador frontend tiene como principales responsabilidades la capa de UI del proyecto. Remontándonos a unos años atrás recordamos como HTML, CSS, los principales frameworks JavaScript como Ext JS, Dojo o el incipiente jQuery dominaban el mercado. Básicamente la persona encargada del frontend no era más que un maquetador (hablando en plata) “poner bonita la interfaz web y dar ciertas interacciones Ajax”, mientras que el desarrollador backend era el encargado de procesar y devolver los datos, en el mejor de los casos, en un template del MVC o en una pseudo API.
Por otro lado, el desarrollador backend, debía ocuparse de la lógica de negocio, delegando en muchos casos a un CRUD de aplicación para leer y escribir datos en SQL. Por ese entonces, frameworks empresariales de Java o C# ocupaban los primeros puestos, junto algunos intentos de frameworks de PHP o Ruby on Rails para facilitar el uso MVC de las aplicaciones web.
Hasta aquí parecía coherente tener en una cueva a desarrolladores frontend y otra a los de backend. Esto se llevaba tanto a la definición de las tareas como en la división de equipos. Apenas había interacción entre ellos, quizás mínima para ponerse de acuerdo en optimizar ciertas cosas como la caché, el rendimiento, pero aún seguía siendo escasa esa comunicación.
¿Sigue siendo tan clara esa separación frontend-backend?
Mismos problemas que son resueltos, incluso con las mismas herramientas y, por supuesto, identicos conceptos de ingeniería del software
Salvo las empresas más grises y anticuadas, donde el desarrollo software continúa siendo una horrible cascada de tareas con Project Managers presionando, sin apenas interrelación entre equipos o desarrolladores. La cosa ha cambiado mucho, al igual que volvemos a repetir la tecnología y la forma de trabajar.
El sentimiento generalizado históricamente ha sido que la parte más seria de la programación se hace en el lado backend: el diseño de la API, la persistencia, la gestión de la caché, la sincronización de los datos, los tests unitarios, la integración continua, etc…
La realidad en estos últimos años ha cambiado bastante, cada vez nos encontramos con frameworks más complejos para desarrollar aplicaciones cliente como Angular, React o Vue. O la irrupción de node.js que ha impulsado poder desarrollar con JavaScript como un lenguaje de servidor más. Firebase o AWS han apostado con sus cloud functions, por ejemplo.
Sin contar las plataformas móviles como Android o iOS con un amplísimo ecosistema, donde no me atrevería a llamarlos front-end sin más. Los problemas actualmente van más allá de que un UI se va bonita y tenga ciertos toques AJAX. A día de hoy, son aplicaciones complejas con similares problemas como la sincronización de datos, la persistencia, la escalabilidad de código.
No me puedo imaginar un desarrollador, sea backend o frontend que no tenga similares preocupaciones acerca del diseño de una API, de la persistencia, de la testabilidad del código, de cómo escalar funcionalidades, del cómo aplicar Domain Driven Design, TDD o la integración continua.
Trabajamos sobre los mismos problemas que son resueltos, incluso con las mismas herramientas y, por supuesto, idénticos conceptos de ingeniería del software. Los lenguajes han pasado a ser más transversales que nunca, ya lo demuestra JavaScript estando más presente que nunca, los lenguajes modernos Kotlin o Swift, Go, Rust o Elixir, y el uso de frameworks cada vez más funcionales para resolver, volvemos a repetir, los similares casos de uso.
Claramente, hay ciertos aspectos que siguen estando en los extremos de ambos mundos. Como puede ser el despliegue de aplicaciones, la seguridad, sus escalabilidad en entornos en la nube como AWS o Google Cloud. Aunque cada vez son menos abstractos para los programadores frontend con el uso de instancia Docker o el uso de serverless para dotar de un componente backend a sus apps.
La mentalidad full-stack
Obviamente cada uno de nosotros tiramos más hacia uno de los lados. Pero existe una tendencia, sobre todo en las empresas de producto, dícese de gran parte de las Startups tecnológicas que conocemos, donde tener una mentalidad fullstack empieza a ser cada vez más importante.
Esa mentalidad full-stack permite trabajar en cualquier faceta de una funcionalidad end-to-end. Es decir, ser capaz de programar tanto en el lado cliente como servidor, conociendo cómo se comportan cada parte en conjunto. Arreglar y solucionar cualquier reto, y no solamente la mitad de él.
Tanto los lenguajes más modernos y frameworks han ido adoptando esa filosofía multipropósito, homogenizando paradigmas de programación que todos conocemos y manejamos. Esto ha facilitado mucho la primera toma de contacto y su uso en cualquier plataforma.
No estamos diciendo que haya que ser un experto en todo. Eso es imposible. Lo importante es buscar el equilibrio y cómo usar de la mejor forma la tecnología. Saber y entender cómo consumen nuestros usuarios las aplicaciones, ya sea a través de una UI o una API es fundamental. A parte de saber cómo se almacena o se despliega nuestras aplicaciones en lado servidor, por supuesto.
Un desarrollador que entiende cómo funciona una aplicación completamente será mucho más valioso que un desarrollador que sólo entiende la mitad
Un desarrollador que entiende cómo funciona una aplicación completamente será mucho más valioso que un desarrollador que sólo entiende la mitad. Un programador que es capaz de escribir código en cualquier parte de un proyecto será mucho más versátil. Al igual que los equipos multidisciplinares sin una frontera fuerte entre backend y frontend.
Por ello, siempre recomiendo a los desarrolladores más juniors que empiecen a interesarse desde el principio en lo que hacen sus compañeros del “otro lado”. Y que empiecen a tener una mentalidad fullstack de cada proyecto. Será inevitable especializarse en una parte, pero esa curiosidad les ayudará el resto de su carrera profesional.
Es necesario pensar primero en nosotros mismos como desarrolladores e invertir tiempo en investigar sobre tecnologías frontend y backend. Evangelizar a nuestros compañeros, empezando por nuestro propio equipo y nuestra propia empresa.
Foto | Flickr
Ver 5 comentarios