Que se passe-t-il dans le monde des technologies côté serveur en ce qui concerne le boom des applications mobiles?

Les technologies mobiles devenant de plus en plus populaires, que se passe-t-il côté serveur avec la plupart de ces applications lorsqu'elles doivent communiquer avec un serveur principal?

Je suis habitué au monde de la technologie d'il y a 10 ans, lorsque la plupart des ressources étaient accessibles en demandant une page Web dynamique qui derrière le vu utilisait un langage côté serveur pour obtenir les informations dont il avait besoin à partir d'une base de données relationnelle.

Est-ce toujours le cas et sinon, quels sont les grands changements?

Du haut de ma tête:

1. Utilisation de services Web au lieu d'un accès direct à la base de données à partir du client.
2. REST au lieu de SOAP. SOAP semble être trop lourd pour la communication mobile avec le backend. REST utilisant JSON est beaucoup plus simple à configurer et à utiliser. Surtout si vous utilisez différentes technologies sur le client et le serveur.
3. Concentrez-vous sur plusieurs vues pour les pages Web. Un pour ordinateur de bureau et un pour mobile. Cela devrait être facile si quelqu'un utilise MVC, mais c'est toujours assez problématique.

Il y en a probablement plus. Les applications mobiles sont généralement considérées comme des clients normaux, qui consomment des données et les affichent.

Les technologies

• API RESTful utilisant JSON comme sérialisation - La même API est utilisée par les applications natives, les applications hybrides et les applications Web mobiles. Même dans le premier cas, les modèles côté client sont souvent utilisés (voir un excellent exemple dans "Laisser les JSP dans la poussière: déplacer LinkedIn vers les modèles côté client dust.js" )

• Serveurs légers, asynchrones (pilotés par les événements) - plus d'Apache pré-fork. Nginx, node.js, Twisted, Tornado etc. sont maintenant utilisés.

• OAuth / connexion sociale - Les utilisateurs s'attendent à ne pas avoir à créer un compte pour chaque application individuelle. Ainsi, la plupart des applications permettent de se connecter avec FB, TW et d'autres fournisseurs. Pour FB, Android et iOS offrent une option d' authentification unique .

Choses à considérer

• Les réseaux mobiles ont des latences très élevées;
• Il est normal que les clients perdent des connexions;
• Il est normal qu'un client change d'IP pendant la session;
• Les mobiles sont loin d'être aussi puissants que les ordinateurs de bureau / portables;

REST est la moitié de l'histoire. La chose la plus intéressante que les protocoles plus légers sur le fil sont les serveurs d'applications Web et les piles plus légères - les demandes à grande échelle de petits datagrammes par rapport au HTML rendu relativement épais signifie que vous avez des exigences différentes. Quelques exemples:

• node.js en est probablement l'exemple canonique. La plupart des gens se sont accrochés à la fonctionnalité javascript sur le serveur, mais c'est un hareng rouge - cool pour les enfants qui ne peuvent pas progresser au-delà de js mais cela n'a pas d'importance. La partie vraiment astucieuse est la nature asynchrone qui la rend incroyablement évolutive, en particulier lorsqu'elle sert de petits services RESTful pointus. Certaines autres piles avec des similitudes seraient tordues pour python ou manos de mono pour .NET.

• nginx utilise beaucoup du même IO événementiel (libuv) que node.js, et il nettoie le marché des serveurs dans certains cercles. Beaucoup plus concentré qu'apache et incroyablement rapide.

• Des piles de serveurs minces apparaissent dans des environnements qui avaient traditionnellement des cadres épais qui faisaient beaucoup de présomptions. IE, en rubis vous avez sinatra pour contrebalancer les rails. En python, vous avez un flacon [et d'autres] pour contrebalancer Django. Dans .NET, vous disposez de WebAPI pour contrebalancer MVC et WebForms. Toutes les piles que j'ai mentionnées sont très, très fines et sont plus (ou totalement) axées sur le service de datagrammes et non de pages Web. Aucun de ceux que je mentionne ne propose les types de modèles et d'ORM que l'on attend d'une pile Web typique de nos jours.

Cela dit, le plus souvent, quelqu'un sert son application mobile en piratant l'application Web côté serveur existante de 10 ans pour servir json sur un point de terminaison HTTP différent. Le monde n'a pas tellement changé - la direction boitera toujours sur 2 roues et un beignet s'ils pensent qu'ils peuvent s'en tirer.

Est-ce toujours le cas et sinon, quels sont les grands changements?

Je pense qu'il existe encore des applications qui utilisent l'architecture côté serveur ou client-serveur mentionnée. Cependant, au cours des dernières années, il y a un grand mouvement vers SOA (Service Oriented Architecture) . Ainsi, la communication par le biais de services sécurisés ouvre de nouvelles capacités à toutes les applications clientes et permet d'accéder / réutiliser simultanément des services métier d'arrière-plan.

Avec les marchés émergents du mobile et des tablettes, il devient de plus en plus important d'utiliser les services HTTP comme canal de communication important pour fournir un service étendu aux applications clientes.

La plupart des back-end prennent désormais en charge JSON et REST et pas seulement SOAP. En dehors de cela, il n'y a pas beaucoup de différence entre un frontal Web et une application mobile. Je pense que la plupart des défis pour les applications mobiles sont sur le front (la meilleure façon d'ajuster les informations sur un écran plus petit). Certaines applications commencent à tirer parti des capacités mobiles (comme les rapports de localisation), mais c'est aux deux extrémités.