ATENCIÓN: este contenido tiene más de 2 años de antigüedad y, debido a su temática, podría contener información desactualizada o inexacta en la actualidad.
Las modas en informática son un fenómeno que no se puede controlar. Hoy en día los nombres de Angular 2, React, Webpack... están en boca de todos:
- ¿Quieres desarrollar web? Aprende React, aprende el nuevo Angular 2 (que pronto será 4 pero... y ¿qué ha pasado con el 3?).
- Antes Gulp solucionaba nuestros problemas con sus tareas, pero ahora Webpack, el nuevo module bundler de moda, parece hacerte más fáciles las cosas.
- Hasta se habla de charlas como "Typescript para desarrolladores backend". ¿Typescript para aplicarlo en Angular, en algún otro front o Typescript para poder usarlo de verdad en el back en un API?
Si los desarrolladores backend vamos a hacer front con Typescript y Angular, ¿quién se va a encargar del "back"?
Quizá esto último es una exageración ya que los desarrolladores backend podemos hacer frontend y viceversa... Aunque ¿no tienes la sensación de que nos han pasado por encima? ¿No nos estamos acoplando a nuestras aplicaciones cliente?
Al final, tanto las aplicaciones de escritorio, como las apps de los móviles e incluso las SPAs tienen detrás un API. Mayoritariamente este API usa servicios REST con servicios HTTP, ya que es muy cómodo trabajar con ellos. Para ello se suele emplear una arquitectura MVC (Modelo-Vista-Controlador), donde modelamos nuestro negocio (Modelo) con sus reglas (Controlador) y dejamos a las tecnologías de front hacer de nuestra Vista.
Pero hasta los desarrolladores frontend en sus clientes aplican MVC. Al final es un MVC continúo: sus aplicaciones cliente son la "V" de nuestro MVC ya que consumen nuestros datos, pero ellos dentro de nuestra "V" tienen todo un MVC montado también para gestionar sus vistas, modelos y controladores dentro de sus propias apps.
¿Y esto de las API y el MVC es muy complicado?
Por suerte ASP.NET MVC tiene un apartado para los amantes de las APIs. ASP.NET Web API, según la definición de Microsoft:
ASP.NET Web API es un marco que facilita la creación de servicios HTTP disponibles para una amplia variedad de clientes, entre los que se incluyen exploradores y dispositivos móviles. ASP.NET Web API es la plataforma perfecta para crear aplicaciones RESTful en .NET Framework.
Node + Express también forman un buen tándem en la creación de APIs. Express, según su propia definición:
Express es una infraestructura de aplicaciones web Node.js mínima y flexible que proporciona un conjunto sólido de características para las aplicaciones web y móviles. Con miles de métodos de programa de utilidad HTTP y middleware a su disposición, la creación de una API sólida es rápida y sencilla.
¿Entonces está todo inventado?
Las modas son modas, pero:
- ¿Está ya todo inventado en las APIs?
- ¿Seguimos teniendo Falete Controllers?
- ¿Tenemos claro qué arquitectura vamos a usar para acceder a nuestros datos?
- ¿Hemos solucionado ya los problemas que causan los ORMs y los patrones Repositories?
- ¿Hemos explotado ya todo lo que se podía nuestros Tokens?
- ¿Hemos resuelto el versionado de nuestras APIs?
- ¿Bases de datos SQL o NoSQL?
Aquí no hay Webpack ni Angular ni otras tecnologías de moda. Aún así sigue habiendo preguntas en el aire a las que tenemos que enfrentarnos. La evolución sigue su curso en el backend y para mí existen dos puntos clave que son los que están evolucionando sobre todo:
- CQRS: es un patrón muy interesante que se basa en el principio de CQS. A este patrón también se le puede añadir Event Sourcing dando lugar a CQRS/ES
- GraphQL: Más allá de REST: trata de cambiar las cosas, de que sea el cliente el que especifique los datos que necesita exactamente en cada momento.
Reivindicando el papel de los desarrolladores backend
[Neo]: ¿Eso es...?
[Cifra]: ¿Matrix? Sí.
[Neo]: ¿Siempre la ves codificada?
[Cifra]: No hay más remedio, los traductores de imagen trabajan para el programa del constructor, pero hay demasiada información para descodificar Matrix. Llegas a acostumbrarte, yo ya ni veo el código, solo veo una rubia, una morena, una pelirroja... Eh, ¿te apetece tomar un trago?
Nosotros, los desarrolladores backend, somos los que vemos esa rubia, esa morena en nuestros APIs. Mimamos nuestros datos, pero a veces pecamos de acoplarlos demasiado al cliente principal que proveemos.
¿Y si de repente apareciera una aplicación móvil que quiere consumir nuestro API? ¿Estaríamos preparados? ¿O nos hemos dejado llevar por nuestros compañeros de front que nos han dicho que los datos no son tan importantes, que lo importante es la usabilidad del cliente? ¿Hemos documentado la respuesta o se lo hemos pasado en un papel a ellos? "Total... si sólo te voy a llamar yo".
No quiero entrar en la guerra del frontend vs backend, sino que quiero hacer un llamamiento a los desarrolladores.
Las APIs son un proyecto aparte del front y deberían tratarse como tal entidad. Los desarrolladores somos muy malos prediciendo el futuro, y los propios clientes no se cansan de demostrárnoslo. Quizá el API de tu aplicación web de hoy pueda interesarle a la aplicación de escritorio que tiene la misma empresa, o a la nueva aplicación móvil que lancen para IOS o, por qué no, al nuevo Bot de Facebook que han creado.
Por tanto, nuestras APIs son importantes. Tan importantes como los front y, aunque no estén de moda, tenemos que creérnoslo y hacer ver que nuestro trabajo también es primordial.
Sí, puede que ese jefe de proyecto que pulula por la oficina tenga más determinación y amor propio por su trabajo que nosotros. Pero ese jefe de proyecto no puede cambiar las cosas. Levantaos, reivindicad vuestras APIs y dadles la importancia que se merecen. Miradlas como si tuvierais más de un cliente. No os acopléis. ¡Sed libres!
Fecha de publicación: