Was passiert in der Welt der serverseitigen Technologien in Bezug auf den Boom der mobilen Apps?

Mit der zunehmenden Beliebtheit mobiler Technologien, was passiert mit den meisten dieser Apps auf der Serverseite, wenn sie mit einem Back-End kommunizieren müssen?

Ich bin an die Welt der Technologie von vor 10 Jahren gewöhnt, als auf die meisten Ressourcen zugegriffen wurde, indem eine dynamische Webseite aufgerufen wurde, die hinter dem Gesehenen eine serverseitige Sprache verwendete, um die benötigten Informationen aus einer relationalen Datenbank abzurufen.

Ist dies immer noch der Fall und wenn nicht, was sind die großen Veränderungen?

Von oben auf meinen Kopf:

1. Verwendung von Webservices anstelle des direkten Zugriffs auf die Datenbank vom Client.
2. REST statt SOAP. SOAP scheint für die mobile Kommunikation mit Backend zu schwer zu sein. REST mit JSON ist viel einfacher einzurichten und zu verwenden. Vor allem, wenn Sie auf Client und Server unterschiedliche Technologien einsetzen.
3. Konzentrieren Sie sich auf mehrere Ansichten für Webseiten. Eine für Desktop und eine für Mobile. Es sollte einfach sein, wenn jemand MVC verwendet, aber es ist immer noch recht problematisch.

Es gibt wahrscheinlich mehr. Mobile Apps gelten meist als normale Clients, die Daten verbrauchen und anzeigen.

Technologies

• RESTful API mit JSON als Serialisierung - Die gleiche API wird von nativen Apps, Hybrid-Apps und mobilen Web-Apps verwendet. Auch im ersten Fall werden häufig clientseitige Vorlagen verwendet (siehe hervorragendes Beispiel in "JSPs im Staub lassen: LinkedIn in clientseitige Vorlagen von dust.js verschieben" ).

• Leichte, asynchrone (ereignisgesteuerte) Server - kein vorab gespaltener Apache mehr. Nginx, node.js, Twisted, Tornado usw. werden jetzt verwendet.

• OAuth / Social Login - Benutzer müssen voraussichtlich kein Konto für jede einzelne App registrieren. So ermöglichen die meisten Apps das Einloggen mit FB, TW und anderen Providern. Für FB bieten sowohl Android als auch iOS die Single-Sign-On- Option.

Dinge, die man beachten muss

• Mobilfunknetze haben sehr hohe Latenzen.
• Es ist normal, dass Kunden Verbindungen verlieren.
• Es ist normal, dass ein Client die IP-Adresse während der Sitzung ändert.
• Handys sind bei weitem nicht so leistungsstark wie Desktops / Laptops.

REST ist die halbe Wahrheit. Das Interessantere als leichtere Protokolle auf dem Kabel sind leichtere Web-App-Server und -Stacks - die Massenskalierungsanforderungen für kleine Datagramme im Vergleich zu vergleichsweise dickem gerendertem HTML bedeuten, dass Sie andere Anforderungen haben. Einige Beispiele:

• node.js ist wahrscheinlich das kanonische Beispiel dafür. Die meisten Leute hängen an der Javascript-on-the-Server-Funktion, aber das ist ein roter Hering - cool für die Kinder, die jenseits von js nicht weiterkommen können, aber es spielt keine Rolle. Der wirklich raffinierte Teil ist die asynchrone Natur, die es wahnsinnig skalieren lässt, besonders wenn es kleine, scharfe RESTful-Services bietet. Einige andere Stapel mit Ähnlichkeiten würden für Python oder Manos de Mono für .NET verdreht.

• nginx verwendet eine Menge derselben ereignisgesteuerten E / A (libuv) wie node.js und räumt in einigen Kreisen den Servermarkt auf. Viel konzentrierter als Apache und wahnsinnig schnell.

• Dünne Server-Stacks tauchen in Umgebungen auf, in denen traditionell dicke Frameworks verwendet wurden, die viele Vermutungen anstellten. IE, in Rubin hast du Sinatra, um Schienen auszugleichen. In Python hast du eine Flasche [und andere], um Django auszugleichen. In .NET haben Sie die WebAPI, um MVC und WebForms auszugleichen. Alle Stapel, die ich erwähnt habe, sind sehr, sehr dünn und konzentrieren sich mehr (oder weniger) auf die Bereitstellung von Datagrammen und nicht auf Webseiten. In keinem der hier genannten Beispiele sind die Arten von Vorlagen und ORMs enthalten, die man heutzutage von einem typischen Web-Stack erwartet.

In den meisten Fällen stellt jemand seine mobile App bereit, indem er die vorhandene 10 Jahre alte serverseitige Web-App hackt, um JSON auf einem anderen HTTP-Endpunkt bereitzustellen. Die Welt ändert sich nicht so sehr - das Management wird immer noch auf zwei Rädern und einem Donut dahinhumpeln, wenn sie glauben, damit durchzukommen.

Ist dies immer noch der Fall und wenn nicht, was sind die großen Veränderungen?

Ich denke, es gibt immer noch Anwendungen, die die erwähnte Server-seitige oder Client-Server-Architektur verwenden. In den letzten Jahren ist jedoch ein großer Schritt in Richtung SOA (Service Oriented Architecture) zu verzeichnen . Die Kommunikation über sichere Dienste eröffnet somit allen Clientanwendungen neue Funktionen und ermöglicht gleichzeitig den Zugriff und die Wiederverwendung von Back-End-Geschäftsdiensten.

In den aufstrebenden Märkten für Mobiltelefone und Tablets wird es immer wichtiger, HTTP-Dienste als wichtigen Kommunikationskanal zu verwenden, um den Client-Anwendungen einen erweiterten Service bereitzustellen.

Die meisten Back-Ends unterstützen jetzt JSON und REST und nicht nur SOAP. Ansonsten gibt es keinen großen Unterschied zwischen einem Web-Frontend und einer mobilen App. Ich denke, die meisten Herausforderungen für mobile Apps liegen im Frontend (wie man Informationen am besten auf einen kleineren Bildschirm bringt). Einige Apps nutzen bereits mobile Funktionen (z. B. Standortberichte), aber das ist beiderseits der Fall.