{"id":11369,"date":"2019-08-19T09:35:24","date_gmt":"2019-08-19T07:35:24","guid":{"rendered":"https:\/\/www.hiberus.com\/crecemos-contigo\/?p=11369"},"modified":"2024-01-17T09:24:47","modified_gmt":"2024-01-17T08:24:47","slug":"consejos-para-desarrollar-un-backend-para-app-movil","status":"publish","type":"post","link":"https:\/\/www.hiberus.com\/crecemos-contigo\/consejos-para-desarrollar-un-backend-para-app-movil\/","title":{"rendered":"Consejos para desarrollar un backend para app m\u00f3vil"},"content":{"rendered":"

Estamos en 2019. Eso significa que los microservicios<\/a>, las aplicaciones multiplataforma<\/a>, las SPA\u2019s, y en definitiva la creaci\u00f3n y reutilizaci\u00f3n de arquitecturas escalables, est\u00e1n muy demandadas. Quiz\u00e1s te est\u00e9s preguntando: \u00bfQu\u00e9 tiene que ver esto con una app m\u00f3vil? pues muy sencillo: si hoy en d\u00eda necesitas tener una aplicaci\u00f3n m\u00f3vil que compita en el mercado, que sea capaz de atraer p\u00fablico y generar tr\u00e1fico que despu\u00e9s se traduzca en conversiones para tu negocio, necesitas consumir y utilizar servicios externos.<\/p>\n

Qu\u00e9 es un backend para app<\/h2>\n

Aqu\u00ed es donde entra un backend<\/strong>. Tradicionalmente un backend siempre ha estado pensando para que su desarrollo vaya de la mano con el frontend, es decir, que una vez se sirviese una web, una aplicaci\u00f3n m\u00f3vil, o cualquier otro sistema, no se tuviera que realizar peticiones constantes a sistemas externos que pudieran ralentizar la experiencia del usuario.<\/p>\n

Esto est\u00e1 muy bien para sistemas que s\u00f3lo tienen intenci\u00f3n de mostrar contenido est\u00e1tico (informaci\u00f3n est\u00e1tica poco o nada cambiante), pero al desarrollar una aplicaci\u00f3n avanzada con notificaciones push, recomendaciones basadas en ubicaci\u00f3n, interacciones constantes con el usuario, informaci\u00f3n actualizada y que sea capaz de reaccionar a las acciones externas; aqu\u00ed es donde entran los paradigmas modernos, el uso de API\u2019s REST y la reutilizaci\u00f3n de sistemas que puedan ofrecer datos a muy diversas aplicaciones.<\/p>\n

Factores a tener en cuenta al crear el backend de tu app<\/h2>\n

En cualquier caso, el \u00e9xito de un backend (independientemente de qu\u00e9 aplicativo lo vaya a utilizar posteriormente) depende principalmente de su velocidad de respuesta<\/strong>, aunque habr\u00e1 que tener en cuenta otros factores para no perjudicar los principios b\u00e1sicos de seguridad, escalabilidad y estabilidad.<\/p>\n

Autenticaci\u00f3n y seguridad<\/h3>\n

Hoy en d\u00eda se utilizan principalmente dos sistemas de autenticaci\u00f3n por lo general: un login\/registro tradicional<\/strong>, o uno que se apoya en el uso de las redes sociales<\/strong> (Google, Facebook, Twitter, etc.). Si optamos por la segunda opci\u00f3n, nos podremos apoyar en la infraestructura con la que ya cuentan estos sistemas externos, pero no tendremos el control total de lo que se est\u00e1 guardando y las modificaciones dependiendo de las necesidades del negocio pueden acabar siendo costosas. Por otra parte, optar por la primera opci\u00f3n (siempre y cuando se implemente correctamente) suele ser la forma m\u00e1s escalable a largo plazo, ya que tendremos control total sobre los datos, su arquitectura, y, por tanto, su arquitectura.<\/p>\n

Esto se traduce en algo muy concreto, muy usado, y muy robusto: OAuth 2.0 y un sistema de autenticaci\u00f3n basado en Json Web Tokens (JWT). Este mecanismo nos permite tener un sistema escalable (posteriormente se har\u00e1 m\u00e1s hincapi\u00e9 en esto), r\u00e1pido y seguro, pero cuidado: la informaci\u00f3n almacenada en un JWT (si no se toman medidas adicionales) se puede leer f\u00e1cilmente y, por esa raz\u00f3n, nunca hay que almacenar informaci\u00f3n sensible en ellos. Si se quisiera aumentar la seguridad de este mecanismo, quiz\u00e1s ser\u00eda una buena idea cifrarla con alg\u00fan tipo de clave que tanto backend como frontend conociesen, aunque habr\u00eda que ir rot\u00e1ndola cada cierto tiempo para evitar ataques de fuerza bruta y, por tanto, un mayor mantenimiento a futuro.<\/p>\n

 <\/p>\n

\"desarrollo<\/p>\n

 <\/p>\n

Escalabilidad y velocidad<\/h3>\n

Aunque pueda parecer que estos dos conceptos no van muy de la mano, creo que, todo lo contrario, un backend que le cueste mucho tiempo responder no va a escalar correctamente<\/strong>, aunque s\u00ed que es verdad que habr\u00e1 que tomar medidas adicionales a la velocidad para conseguir una buena escalabilidad.<\/p>\n

Un primer paso para conseguir estos objetivos es el concepto de que el backend debe ser \u201cstateless\u201d, es decir, en cada petici\u00f3n debe incluirse la informaci\u00f3n necesaria para poder resolver dicha petici\u00f3n. El servidor no tiene que guardar ning\u00fan tipo de informaci\u00f3n necesaria para resolver peticiones consecutivas. Esto ayuda en que las peticiones se resolver\u00e1n r\u00e1pidamente y se podr\u00e1 escalar la capacidad de procesado en m\u00faltiples m\u00e1quinas sin necesidad de configuraci\u00f3n adicional.<\/p>\n

Otra idea interesante ser\u00eda la separaci\u00f3n de la l\u00f3gica en distintos microservicios<\/strong>. Por ejemplo: si tenemos (como ser\u00e1 habitual en una aplicaci\u00f3n m\u00f3vil) una parte encargada de registrar a un usuario para recibir notificaciones push y envi\u00e1rselas, ser\u00eda interesante separar toda esta l\u00f3gica en un microservicio (aunque por detr\u00e1s utilice servicios cloud como AWS o Firebase).<\/p>\n

En cualquier caso, todas estas interacciones deber\u00edan ser transparentes de cara a la aplicaci\u00f3n, es decir, una aplicaci\u00f3n no tendr\u00eda por qu\u00e9 saber cu\u00e1ntos servicios tiene un backend detr\u00e1s. Es por esto por lo que, aunque existan servicios externos, el backend deber\u00e1 actuar como un \u201cmiddleware\u201d para ellos. De esta forma cualquier tipo de modificaci\u00f3n del servicio o ampliaci\u00f3n de este, se realizar\u00e1 de forma transparente al usuario.<\/p>\n

 <\/p>\n

\"desarrollo<\/p>\n

Estabilidad y future-proofing<\/h3>\n

Todos los temas mencionados previamente son muy necesarios si queremos ser capaces de atender a las peticiones de aplicaciones m\u00f3viles, webs u otras plataformas, pero \u00bfqu\u00e9 pasa cuando sufrimos alg\u00fan fallo o \u201cbug\u201d, alg\u00fan ataque o simplemente los servicios externos dejan de responder? En ese caso lo primordial es averiguar la causa del problema<\/strong>, solucionarlo y volver a poner nuestro backend en funcionamiento, pero para ello necesitamos herramientas de monitorizaci\u00f3n, integraci\u00f3n continua, despliegues autom\u00e1ticos y, sobre todo, una calidad de c\u00f3digo<\/strong> que nos har\u00e1 minimizar el riesgo de aparici\u00f3n de estas cuestiones.<\/p>\n

En orden de prioridad lo primero es empezar con un buen analizador de c\u00f3digo para acostumbrarnos a usar buenas pr\u00e1cticas y as\u00ed evitar la aparici\u00f3n de problemas a futuro. Para eso tenemos herramientas (conocidas como \u201clinters\u201d) tan complejas como SonarQube hasta simplemente analizadores de c\u00f3digo en tiempo real que nos aportar\u00e1n sugerencias, ejemplo: JSLint o TSLint para aplicaciones (frontend, backend, etc.) en Javascript o Typescript respectivamente.<\/p>\n

En cualquier caso estas herramientas necesitan de una serie de \u201creglas\u201d para ser \u00fatiles, por eso es importante fijarse en gu\u00edas y buenas pr\u00e1cticas que sean ampliamente utilizadas<\/strong>, como por ejemplo las gu\u00edas de c\u00f3digo de Airbnb para javascript<\/a> (s\u00ed, esa famosa empresa de alquileres vacacionales).<\/p>\n

 <\/p>\n

\"guias<\/p>\n

 <\/p>\n

Una vez tenemos claro que nuestro c\u00f3digo sigue ciertas normas establecidas, debemos ser capaces de tener un entorno controlado de despliegue, para evitar introducir cualquier fallo humano en el mismo. Para esto intervienen herramientas de CI\/CD<\/strong> como Jenkins<\/a>, las cuales se pueden acoplar r\u00e1pidamente a nuestro flujo de trabajo y realizar despliegues con un simple click.<\/p>\n

 <\/p>\n

\"testing<\/p>\n

 <\/p>\n

Finalmente, y no por ello menos importante, debemos monitorizar el estado del sistema<\/strong> en todo momento. Esto nos ayudar\u00e1 a descubrir fallos en la mayor brevedad posible, as\u00ed como posiblemente sus causas. Con esta finalidad en mente tenemos varias alternativas, algunas que incluso ofrecen versiones tanto gratis como de pago (dependiendo del nivel de monitorizaci\u00f3n que queramos), pero en entornos de backend Javascript destaca una principalmente: PM2<\/strong>.<\/p>\n

Esta herramienta nos permitir\u00e1 tener en todo momento una visi\u00f3n de los procesos que est\u00e1n ejecut\u00e1ndose, las veces que se han tenido que reiniciar (en el caso de un fallo cr\u00edtico que provoque la parada del backend, PM2 se encargar\u00e1 de volver a arrancarlo), diversos logs con los errores o las trazas ejecutadas, e incluso una opci\u00f3n muy interesante: despliegues remotos desde nuestro entorno local con una serie de opciones preconfiguradas.<\/p>\n

 <\/p>\n

\"monitorizar<\/p>\n

 <\/p>\n

En cualquier caso, lo que est\u00e1 claro es que un backend ya sea para una aplicaci\u00f3n m\u00f3vil, una web o cualquier otra plataforma, es algo que debe ser pensado desde un principio con una buena arquitectura, debe estar pensado para escalar en diversas m\u00e1quinas (que no tienen por que estar ubicadas f\u00edsicamente en la misma localizaci\u00f3n) y tiene que estar monitorizado constantemente para solucionar los problemas que tarde o temprano van a aparecer.<\/p>\n

 <\/p>\n

Si est\u00e1s interesado en crear un backend para tu app y as\u00ed poder gestionar\u00a0tu\u00a0app\u00a0y\u00a0\u00a0tu sitio web con mayor facilidad, escr\u00edbenos explic\u00e1ndonos m\u00e1s sobre tu proyecto. Nuestro equipo de\u00a0 aplicaciones multiplataforma<\/a> en Hiberus Mobile estar\u00e1 encantado de ayudarte.\u00a0<\/em><\/p>\n

\n
\n
\n
\n

\u00bfQuieres m\u00e1s informaci\u00f3n sobre nuestros servicios de desarrollo de aplicaciones m\u00f3viles?<\/p>\n

Contacta con nuestro equipo de Mobile<\/p>\n <\/div>\n

\n \n
\n

<\/p>

    <\/ul><\/div>\n
    \n
    \n<\/fieldset>\n
    \n\t
    \n\t\t
    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t\t

    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

    \n\t\t
    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t\t

    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

    \n\t\t
    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

    \n\t\t
    \n\t\t\t