Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

?id=f1db7416-6e33-4e3f-821b-2b73a83f85cf

Los desarrolladores backend, ¿hemos dejado de estar de moda?

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

single-model

  • 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.

GraphQL_Logo.svg_-1

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".

thematrix

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:
Ángel Carlos López Quevedo

Ingeniero técnico informático por la Universidad de Castilla la Mancha (UCLM), llevo varios años trabajando con las tecnologías en .NET, dedicándome sobre todo a la parte backend de las aplicaciones. Estoy certificado en microsoft como MCSA: Web Applications y actualmente tengo el placer de trabajar en Plain Concepts como Software Development Engineer.

Puedes seguirme en twitter: _aclopez

Ver todos los posts de Ángel Carlos López Quevedo
Archivado en: DevFacts | General

¿Te vas a perder los mejores trucos de programación?

Únete a miles de desarrolladores que ya reciben cada mes nuestro boletí­n por email. No te pierdas los mejores trucos, noticias y frikadas.

Enviamos poco, pero bueno. Palabra de desarrollador.

Suscríbete aquí­

Sí­guenos también en:

Telegram LinkedIn YouTube
La mejor formación online para desarrolladores como tú

Comentarios (6) -

Es un muy buen artículo del que no entiendo mucho y me gustaría entender jajaja! Soy algo nuevo en esto.

Responder

Hola, la moda llega mucho más lejos de lo que cuentas, yo era un programador en su día de C# principalmente en backend,  etc, pero el cambio ha llegado a puro front, con decir que estoy trabajando para una Intranet de una muy conocida empresa multinacional, y dado que la Intranet es segura, la lógica de negocio se opera en TypeScript puro, no hay nada al backend!!!

Alguno podría preguntarse, si la información puede guardarse así y si el funcionamiento es bueno, y la respuesta es un absoluto Sí!, el backend es un webservice genérico que recibe las peticiones, y tenemos una librería TypeScript que construye la petición para el web service a partir de una sintaxis similar a SQL. El resultado, ya no tocamos para nada el backend. nada de nada, ni siquiera dar de alta campos, todo es typescript. El servidor es robusto y soporta cualquier cosa sin caerse. Aquí en este trabajo para mí el backend está muerto.

Se me puede decir que la aplicación podría ser lenta... pues no, para nada, en los navegadores modernos JavaScript va como el rayo, y si se programa bien, puede llegar a un rendimiento de un 60% a 70% del C++. ¿El transito de información es problema? No, pues la red al ser una intranet estando los usuarios que hacen carga masiva de datos en la central ni se nota nada, pues todo el mundo tiene buena conexión, y los usuarios en otros países, no hacen cargas masivas (no son usuarios preferentes).

¿Falta de memoria quizás? No, para nada, el mínimo que tiene un usuario son 8 gigas ram, con eso se puede hacer mucho..., ¿pocos usuarios? No, nuevamente para nada, son varios miles...

Soy consciente de lo que comento no es del todo lo habitual, pero quería comentarlo para enfatizar que está muriendo  el backend!! y con WebAssembly y futuras conexiones cada vez más rápida, el backend va a quedar a la mínima expresión y sólo para Web públicas...

Cordiales Saludos
Víctor J. González Fernández

Responder

Ángel Carlos
Ángel Carlos

Hola.

No creo que el backend muera nunca ya que dejar lógica de negocio en el lado del cliente es muy peligroso. Por mucho que la Intranet sea segura (definición un poco arriesgada, ¿que es seguro hoy en día?) ese código en el lado del cliente está demasiado expuesto. Aunque se minifique y sea difícil de leer.

Otra cosa diferente es que en tu backend uses Typescript. Eso sí es perfectamente asumible. Cuando hablamos de backend no hablamos de C#, podemos hablar de cuantos lenguajes se quieran: Javascript, Typescript, Java, C#... Pero tu dominio de negocio nunca debería estar expuesto en tu cliente, siempre debe haber esa capa de backend detrás. Se puede tener un backend con microservicios o con cualquier otro diseño acorde a tus necesidades pero siempre es necesario.

Muchas gracias por tu comentario.

Un saludo!

Responder

Victor Jesus
Victor Jesus

El backend morir en teoría no puede morir, pero se puede minimizar mucho, es a lo que me refería, a veces hay que exagerar las cosas para que la gente se percate ante la costumbre: antes el backend era el 90%, ahora, 50%, 30% e incluso el 5% de todo el volumen del aplicativo como es el caso del que llevo.

Respecto a la seguridad, es un concepto muy relativo, pues los usuarios son todos empleados de la empresa, bien fichados, y el aplicativo usa la autenticación windows, en cualquier caso, la autenticación contra el webservice se produce con las credenciales del usuario en directorio activo. Estoy contigo que para web públicas no lo veo, `pues por más credenciales expone cierta lógica operativa, pero esta Intranet los que se encuentran fuera la ven por una VPN bien segura. Son usuarios que no se van a dedicar a realizar manipulaciones de código, no hay anonimato alguno.

Por cierto, ya que comentas de JavaScript, C# y TypeScript (todos mis favoritos), y de lenguajes backend hay que empezar ya a pensar en GO de google, últimamente es mi vicio... me encanta, Si lo compilas en gccgo tiene la velocidad de C puro, un perfomance increíble, anda en Linux, Windows, y una simpleza que me encanta pues es una programación orientada a objeto simplificada y lo mismo tiempo tiene el paradigma funcional extra simplificado, lo mejor es que tiene gestión de la concurrencia muy fácil (por fin aprovechamos de verdad a nivel de código los multinucleos, pues forma parte del propio lenguaje y su diseño, lo cual lo simplifica mucho) y tiene la recolección de memoria basura al estilo de JAVA y C#, una gozada. Me puse a verlo porque lo vi en el lenguaje del año en tiobe, al principio era muy critico con el mismo, ahora no, pienso en pensar a crear aplicaciones con el backend usándolo. No es difícil, no hay que temerlo :-)

Cordiales Saludos

Responder

santimacnet
santimacnet

Buenas,

Solo me gustaria compartir una pequeña duda o un posible escenario,  que pasará si en un futuro tu aplicación necesita evolucionar a otras plataformas, por ejemplo, una aplicación nativa para movil basada en la actual o necesitas aprovechar el webservice de tu backend para compartir con otras apliaciones empresariales.

Como reflexión, creo que en estos escenarios el backend te facilita mucho las cosas si tienes la lógica de negocio alli, la puedes reaprovechar y si cambia algo en el negocio tambien es más fácil el mantenimiento del sistema.

Un saludo.


Responder

Pues yo creo que del ingeniero y del diseñador se está haciendo un hibrido. Yo soy front y recientemente estoy estudiando temas como laravel y me encanta está forma de hacer php con frameworks.

El front End al principio de los tiempos solo era el diseño visual, la usabilidad y a lo mucho el maquetado, ahora si usas angular y no alimentas tu app con una base de datos, me parece que el medio laboral te vería como incompleto.

Más que una moda, me gustaría pensar que las cosas están mejorando para el usuario y para los involucrados en la producción de las aplicaciones.

Como se dice, al final del día es actualizarse o morir.

Responder

Agregar comentario

Los datos anteriores se utilizarán exclusivamente para permitirte hacer el comentario y, si lo seleccionas, notificarte de nuevos comentarios en este artículo, pero no se procesarán ni se utilizarán para ningún otro propósito. Lee nuestra política de privacidad.