Co dzieje się w świecie technologii po stronie serwera w związku z boomem na aplikacje mobilne?

Ponieważ technologie mobilne stają się coraz bardziej popularne, co dzieje się po stronie serwera z większością tych aplikacji, gdy muszą komunikować się z zapleczem?

Przyzwyczaiłem się do świata technologii sprzed 10 lat, kiedy dostęp do większości zasobów był możliwy, prosząc o dynamiczną stronę internetową, która za tym, co widziało, używała języka po stronie serwera, aby uzyskać potrzebne informacje z relacyjnej bazy danych.

Czy nadal tak jest, a jeśli nie, jakie są wielkie zmiany?

Z czubka głowy:

1. Korzystanie z usług internetowych zamiast bezpośredniego dostępu do bazy danych z klienta.
2. REST zamiast mydła. SOAP wydaje się zbyt ciężki do komunikacji mobilnej z backendem. REST przy użyciu JSON jest znacznie prostszy w konfiguracji i korzystaniu. Zwłaszcza jeśli używasz różnych technologii na kliencie i serwerze.
3. Skoncentruj się na wielu widokach stron internetowych. Jeden na komputer i jeden na telefon. To powinno być łatwe, jeśli ktoś używa MVC, ale wciąż jest dość problematyczne.

Prawdopodobnie jest ich więcej. Aplikacje mobilne są w większości uważane za zwykłych klientów, którzy zużywają dane i je wyświetlają.

Technologie

• RESTful API używający JSON jako serializacji - ten sam API jest używany przez aplikacje natywne, aplikacje hybrydowe i mobilne aplikacje internetowe. Nawet w pierwszym przypadku często używane są szablony po stronie klienta (patrz doskonały przykład w „Pozostawienie stron JSP w pył: przenoszenie LinkedIn do szablonów po stronie klienta dust.js” )

• Lekkie, asynchroniczne (sterowane zdarzeniami) serwery - koniec z Apache przed rozwidleniem. Nginx, node.js, Twisted, Tornado itp. Są teraz używane.

• OAuth / login społecznościowy - użytkownicy nie muszą rejestrować konta dla każdej aplikacji. W związku z tym większość aplikacji umożliwia logowanie za pomocą FB, TW i innych dostawców. W przypadku FB zarówno Android, jak i iOS zapewniają opcję pojedynczego logowania .

Rzeczy do rozważenia

• Sieci komórkowe mają bardzo duże opóźnienia;
• Utrata połączeń jest czymś normalnym;
• To normalne, że klient zmienia adres IP podczas sesji;
• Telefony komórkowe nie są tak potężne jak komputery stacjonarne / laptopy;

REST to połowa historii. Bardziej interesującą rzeczą niż lżejsze protokoły w sieci są lżejsze serwery i stosy aplikacji internetowych - masowe żądania małych datagramów w porównaniu do stosunkowo grubego renderowanego HTML oznaczają, że masz inne wymagania. Kilka przykładów:

• node.js jest prawdopodobnie kanonicznym przykładem tego. Większość ludzi odkłada słuchawkę na javascript-on-the-server, ale jest to czerwony śledź - fajny dla dzieci, które nie mogą przejść dalej niż js, ale to nie ma znaczenia. Naprawdę fajna część to asynchroniczna natura, dzięki której skaluje się niesamowicie, szczególnie podczas obsługi małych, ostrych usług RESTful. Niektóre inne stosy o podobieństwach byłyby przekręcone dla Pythona lub Manos de Mono dla .NET.

• nginx używa wielu tych samych zdarzeń IO (libuv), które robi node.js, i w niektórych kręgach czyści rynek serwerów. O wiele bardziej skoncentrowany niż apacz i niesamowicie szybki.

• Cienkie stosy serwerów pojawiają się w środowiskach, które tradycyjnie miały grube ramy, które powodowały wiele domniemań. IE, w rubinie masz sinatrę do równoważenia szyn. W python masz flask [i inne], aby zrównoważyć django. W .NET masz WebAPI do równoważenia MVC i WebForms. Wszystkie wspomniane stosy są bardzo, bardzo cienkie i bardziej (lub całkowicie) koncentrują się na udostępnianiu datagramów, a nie stron internetowych. Żaden z tych, o których wspomniałem, nie zawiera rodzajów szablonów i ORM, których oczekuje się obecnie od typowego stosu internetowego.

To powiedziawszy, najczęściej ktoś obsługuje swoją aplikację mobilną, hakując istniejącą 10-letnią aplikację internetową po stronie serwera, aby obsługiwać JSona na innym punkcie końcowym HTTP. Świat tak bardzo się nie zmienił - kierownictwo nadal będzie kuleć na dwóch kołach i pączku, jeśli będą myśleć, że uda mu się uciec.

Czy nadal tak jest, a jeśli nie, jakie są wielkie zmiany?

Myślę, że wciąż istnieją aplikacje korzystające ze wspomnianej architektury po stronie serwera lub klient-serwer. Jednak w ostatnich latach nastąpił duży ruch w kierunku architektury SOA (Service Oriented Architecture) . W ten sposób komunikacja za pośrednictwem bezpiecznych usług otwiera nowe możliwości dla wszystkich aplikacji klienckich, a jednocześnie zapewnia dostęp / ponowne wykorzystanie usług biznesowych zaplecza.

Wraz z pojawiającymi się rynkami telefonów komórkowych i tabletów coraz ważniejsze staje się korzystanie z usług HTTP jako ważnego kanału komunikacji w celu zapewnienia rozszerzonej obsługi aplikacji klienckich.

Większość back-endów obsługuje teraz JSON i REST, a nie tylko SOAP. Poza tym nie ma dużej różnicy między interfejsem internetowym a aplikacją mobilną. Myślę, że większość wyzwań związanych z aplikacjami mobilnymi dotyczy frontonu (jak najlepiej dopasować informacje do mniejszego ekranu). Niektóre aplikacje zaczynają wykorzystywać funkcje mobilne (np. Raportowanie lokalizacji), ale działa to z obu stron.