¿Qué está ocurriendo en el mundo de las tecnologías del lado del servidor con respecto al auge de las aplicaciones móviles?


12

Con las tecnologías móviles cada vez más populares, ¿qué está sucediendo en el lado del servidor con la mayoría de estas aplicaciones cuando necesitan comunicarse con un back-end?

Estoy acostumbrado al mundo de la tecnología desde hace 10 años, cuando se accedía a la mayoría de los recursos solicitando una página web dinámica que detrás de lo visto usaba un lenguaje del lado del servidor para obtener la información que necesitaba de una base de datos relacional.

¿Sigue siendo así, y si no, cuáles son los grandes cambios?


Muchas aplicaciones más pequeñas dependen de Google App Engine :).
MrFox

Respuestas:


7

Desde lo alto de mi cabeza:

  1. Uso de servicios web en lugar de acceso directo a DB desde el cliente.
  2. Descansa en lugar de jabón. SOAP parece ser demasiado pesado para la comunicación móvil con backend. REST usando JSON es mucho más simple de configurar y consumir. Especialmente si usa diferentes tecnologías en el cliente y el servidor.
  3. Concéntrese en múltiples vistas para páginas web. Uno para escritorio y otro para móvil. Debería ser fácil si alguien usa MVC, pero sigue siendo bastante problemático.

Probablemente hay más. Las aplicaciones móviles se consideran principalmente clientes normales, que consumen datos y los muestran.


6

Tecnologías

  • RESTful API utilizando JSON como serialización : las aplicaciones nativas, las aplicaciones híbridas y las aplicaciones web móviles utilizan la misma API. Incluso en el caso anterior, a menudo se usan plantillas del lado del cliente (vea un excelente ejemplo en "Dejar las JSP en el polvo: mover LinkedIn a las plantillas del lado del cliente dust.js" )

  • Servidores ligeros y asíncronos (controlados por eventos) : no más Apache previo a la bifurcación. Ahora se usan Nginx, node.js, Twisted, Tornado, etc.

  • OAuth / inicio de sesión social : los usuarios esperan no tener que registrar una cuenta para cada aplicación individual. Por lo tanto, la mayoría de las aplicaciones permiten iniciar sesión con FB, TW y otros proveedores. Para FB, tanto Android como iOS ofrecen la opción de inicio de sesión único .

Cosas para considerar

  • Las redes móviles tienen latencias muy altas;
  • Es normal que los clientes pierdan conexiones;
  • Es normal que un cliente cambie la IP durante la sesión;
  • Los móviles no son tan poderosos como las computadoras de escritorio / portátiles;

4

REST es la mitad de la historia. Lo más interesante que los protocolos más livianos en el cable son los servidores y las pilas de aplicaciones web más livianas: las solicitudes de escala masiva para datagramas pequeños versus HTML renderizado comparativamente grueso significa que tiene diferentes requisitos. Algunos ejemplos:

  • node.js es probablemente el ejemplo canónico de esto. La mayoría de las personas se obsesionan con la función javascript en el servidor, pero eso es una pista falsa, genial para los niños que no pueden progresar más allá de js pero no importa. La parte realmente ingeniosa es la naturaleza asincrónica que lo hace escalar increíblemente, especialmente al servir servicios RESTful pequeños y agudos. Algunas otras pilas con similitudes se retorcerían para python o manos de mono para .NET.

  • nginx usa muchos de los mismos IO (libuv) creados que node.js, y está limpiando el mercado de servidores en algunos círculos. Mucho más enfocado que apache e increíblemente rápido.

  • Las pilas de servidores delgados están apareciendo en entornos que tradicionalmente tenían marcos gruesos que hacían muchas presunciones. Es decir, en ruby ​​tienes sinatra para contrarrestar rieles. En python tienes un matraz [y otros] para contrarrestar django. En .NET tienes el WebAPI para contrarrestar MVC y WebForms. Todas las pilas que mencioné son muy, muy delgadas y están más (o totalmente) enfocadas en servir datagramas y no en páginas web. Ninguno de los que menciono presenta el tipo de plantillas y ORM que uno espera de una pila web típica en estos días.

Dicho todo esto, la mayoría de las veces alguien está sirviendo su aplicación móvil al piratear la aplicación web del lado del servidor de 10 años para servir a json en un punto final HTTP diferente. El mundo no ha cambiado tanto: la administración seguirá cojeando sobre dos ruedas y una dona si creen que pueden salirse con la suya.


1

¿Sigue siendo así, y si no, cuáles son los grandes cambios?

Creo que todavía hay aplicaciones que usan la arquitectura mencionada del lado del servidor o cliente-servidor. Sin embargo, en los últimos años hay un gran movimiento hacia SOA (Service Oriented Architecture) . Por lo tanto, la comunicación a través de servicios seguros abre nuevas capacidades a todas las aplicaciones del cliente y al mismo tiempo acceso / reutilización de servicios empresariales de back-end.

Con los mercados emergentes de dispositivos móviles y tabletas, es cada vez más importante utilizar los servicios HTTP como un importante canal de comunicación para proporcionar un servicio extendido a las aplicaciones del cliente.


1

La mayoría de los back-end ahora admiten JSON y REST y no solo SOAP. Aparte de eso, no hay mucha diferencia entre un front-end web y una aplicación móvil. Creo que la mayoría de los desafíos para las aplicaciones móviles están en el front-end (la mejor manera de ajustar la información en una pantalla más pequeña). Algunas aplicaciones están comenzando a aprovechar las capacidades móviles (como los informes de ubicación), pero eso está en ambos extremos.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.