El 14 de septiembre de 2017, publicamos una versión revisada de nuestra Política de privacidad. Tu uso continuado de video2brain.com significa que aceptas este documento revisado, por lo que te recomendamos que dediques unos minutos a leerlo y comprenderlo.

Swift 3: Integración con tecnologías backend

Estrategia de servicios

Prueba ahora LinkedIn Learning sin cargo y sin compromiso.

Prueba gratis Mostrar modalidades de suscripción
Existen diferentes estrategias conocidas para elaborar servicios web. En este video te voy a mencionar algunos como por versiones, por feature, por recursos y algunas otras opciones más que puedes encontrar.

Transcripción

Los años me han enseñado muchas cosas a lo largo de integrar múltiples servicios a mis aplicaciones. Existen diferentes estrategias, y, créeme, esto se puede descontrolar. ¿Cómo lo vas a mantener de alguna manera organizada y teniendo muy claro qué es lo que necesitas? Bueno, pues te voy a dar una serie de "tips", trucos y estrategias muy comunes que puedes encontrar en cualquier libro o en cualquier tutorial para que te identifiques con ellos y tú sepas cuál es el más adecuado para tu proyecto. Lo primero que te tengo que decir es, no los vayas haciendo uno a uno. Trata de tener, al menos, el "scope" más grande de tus requerimientos para después ir desarrollándolos en conjunto. No importa si después le agregas más, lo que importa es que establezcas una estructura básica para después comenzar a desarrollar los servicios y el cliente. Primero vamos a ver, puedes tener microservicios con una instancia monolítica de "AppServer". ¿Cómo funcionan los microservicios? Los microservicios son una estrategia para poder tener múltiples funcionalidades en diferentes aplicaciones. Por ejemplo, va a existir una aplicación en Rails que se dedica a hacer todo el "Login". Luego vamos a tener una aplicación en Django para procesar todas las imágenes. Luego vamos a tener una aplicación en PHP para generar los documentos de Office. En realidad, esa es la estrategia de microservicios, haces muchas aplicaciones que hacen pequeñas cosas a la vez. La ventaja es que puedes actualizar las diferentes partes de tu aplicación sin apagar toda la aplicación o el conjunto de servicios. La aplicación principal puede reutilizar código hecho para otras necesidades como la web o móvil. Corregir errores o agregar funcionalidades al ApplicationServer, puede ser general y no tienes que tener múltiples parches para poderlo hacer. Todo depende de qué tan rápido y qué tan grandes sean los cambios. Si tú necesitas muchos cambios grandes que sí pueden estar apagando todo el servidor, entonces tal vez te sugeriría mandarlo a microservicios. Tal vez tú necesitas que el cambio sea muy rápido, bueno, entonces necesitas hacerlo en el ApplicationServer y reiniciarlo. El problema es que, a veces, con los "bugs", si lo haces en microservicios y eso se comparte en otros proyectos, tener microservicios puede ser un poco caótico si en realidad no lo necesitas. Te sugiero que dependiendo del proyecto, el tamaño y la gente involucrada, tú lo evalúes. Versiones. Es importante aprender que las versiones existen por una razón. Imagina esto, tú tienes un servicio en donde expones una estructura de un objeto y estás "parseando" esa estructura en tu cliente. Y, de repente, tu jefe dice: "Oye, pues vamos a cambiarle el nombre del tipo". Tú se lo cambias, muy inocentemente, no tienes versiones, la liberas y, de repente, te das cuenta que hay muchos usuarios, a los cuales, les está "crasheando"la aplicación. Bueno, ese es un problema muy serio. ¿Cómo se resuelve? Se resuelve simplemente colocándole un numerito a la URL o al encabezado o al sub-dominio. Lo único que tienes que hacer es "versionar". Solamente "versionas" los cambios que son destructivos o que pueden provocar ciertos "crashes" en tu aplicación. Recuerda que estos clientes pueden ser SDK, bibliotecas, REST API y todo lo que esté conectado a tu servidor. Existen cambios destructivos y cambios inofensivos. Debes de probar todos estos de una manera muy sencilla y rápida. Ahora, esto, recuerda, pueden estar en la URL, en los ecabezados o en los parámetros, pero es muy importante que lo tengas. Ahora, tal vez estás haciendo un prototipo, no necesitas versiones. Tal vez no vas a tener muchos cambios en los clientes, no necesitas versiones, pero ya cuando empiezas a tener un ambiente productivo que sí es vital, es muy importante que, por lo menos, lo tengas en cuenta. Otra estrategia es expon todos los recursos como objetos. ¿Cómo funciona? Cada recurso es un objeto de dominio. Cuando digo un "objeto de dominio", quiere decir un objeto dentro de tu dominio o problema, y tu problema se resuelve con tu aplicación y con tu estructura de modelo. Entonces cada recurso se va a volver un modelo. Imagina que tienes la tabla de usuarios, bueno pues, entonces, tienes una clase "usuarios", pero también la tienes en el cliente, entonces la puedes "mapear" sin ningún problema. A veces no necesitamos el mismo modelo del servidor en el cliente. Entonces, puede ser, que tú tengas una tabla para análisis de estadísticas de los usuarios, y solamente necesitas un valor de esa tabla, bueno, ese valor de esa tabla lo tienes que exponer pero tal vez lo metas en otra estructura o en otro recurso. Se utilizan todos los verbos HTTP, aquí se utilizan el "get", el "put", el "lead", el "post", todos los verbos de HTTP que están establecidos los puedes utilizar. Es muy flexible y existen cambios de propiedades y relaciones. ¿Cómo va a funcionar esto? Bueno, pues cada vez que cambies las tablas de tu base de datos, lo vas poder estar reflejando en todos los recursos, aunque a veces no es suficiente la información. Si tú tienes más información que desplegar y necesitas múltiples objetos, puede ser muy ineficiente. Si tú quieres hacer esto, es muy rápido con PostgreSQL. PostgreSQL tiene un pequeño servicio en donde tú lo activas, y expone todos los objetos como si fueran recursos, como si fuera tu AppServer. Te ahorras mucha lógica, pero toda la lógica del negocio tiene que estar en tu cliente. Otra estrategia es hacer pistas. Básicamente, todo lo que esté en tu pantalla es lo que vas a estar pidiendo como un servicio. Es muy sencillo, es muy óptimo, no haces tantas peticiones al servidor; el problema es que cada cambio que hay en la interfaz afecta directamente a tus servicios. El conjunto de datos puede ser muy grande para nuestra petición, eso también es algo que ocurre mucho. Si, de repente, el diseñador necesita 20 mil datos dentro de nuestra primera pantalla, entonces, la petición va a ser muy grande, y a veces tú no necesitas tanto nada más necesitas lo ya procesado. Como conclusión te puede decir que depende de la empresa, depende del proyecto, depende del equipo. Solamente te estoy mostrando algunas estrategias, y puedes mezclar cualquier punto entre ellas. No creas que en realidad son técnicas ya cerradas. Te recomiendo que estudies cada uno de los puntos que te estoy dando, que analices cada uno de los detalles, y si quieres mezclarlos y generar tu propia técnica, está bien. Lo que te haga hacer tu proyecto más rápido y de una manera más simple de mantener y escalar, va a ser lo mejor. A veces necesitamos más estructura que rapidez. Yo, en lo personal, uso "recursos" más "vistas". Primero hago todos los recursos que necesito y después, si necesito alguna vista muy compleja, desarrollo el servicio solamente para esa "vista". Ninguna de las estrategias es exclusiva, entonces puedes mezclarlas y mejorarlas con el tiempo. Y recuerda que la mejor estrategia es la que te hace cumplir tu objetivo de forma rápida y sencilla. Así que mantén la mente abierta, estudia cómo otras empresas hacen sus servicios, estudia cómo, por ejemplo, servicios famosos como Paypal o Stripe, que son empresas de pagos y que ofrecen un API muy bien estructurado, revisa cómo lo hacen y trata de ver qué te puede servir de ellos.

Swift 3: Integración con tecnologías backend

Aprende a vincular tus aplicaciones web creadas con Swift 3 con el servidor, comienza a enviar información entre ambos y aprovecha esto al máximo dentro de tus sistemas.

3:08 horas (27 Videos)
Actualmente no hay comentarios.
 

Este curso video2brain está disponible como descarga y para ser visualizado online. ¡Pero no hace falta que decidas entre las dos opciones! Al comprar el curso, disfrutarás de ambas posibilidades.

La descarga te permite ver las lecciones sin estar conectado/a a internet y supone una navegación fácil y ágil entre capítulo y capítulo. Si vas a trabajar en diferentes ordenadores o si no quieres descargarte el curso completo, entra en la web con tus datos de acceso y disfruta directamente de tus vídeos online. Te deseamos que disfrutes de este curso y te resulte de mucha utilidad.

Estamos a tu disposición si tienes cualquier tipo de duda o pregunta.