Termin UI lub interfejs użytkownika jest rzucany wokół dużo, jeśli chodzi o rozwój aplikacji. Pierwszą rzeczą, którą widzi klient po otwarciu aplikacji jest to, jak została ona zaprojektowana, więc ma sens, że jest to aspekt rozwoju sieci, który jest bardzo ważny. Prosty i łatwy w użyciu UI może zwiększyć współczynnik konwersji aplikacji internetowej o prawie 200%. UI jest integralną częścią procesu tworzenia oprogramowania.
Ponieważ jest to głównie związane z tym, co widzi klient, interfejsy użytkownika są opracowywane przez inżynierów front-end. Kilka frameworków front-endowych - jak React.js, flutter i inne, sprawiają, że tworzenie pięknych interfejsów użytkownika jest proste i efektywne. Jednak tradycyjny rozwój może być długim procesem, zwłaszcza jeśli chodzi o aktualizacje. Sklepy z aplikacjami, takie jak Apple store i Google play store, często wymagają od deweloperów przejścia przez długi proces, jeśli chcą wdrożyć jakiekolwiek większe zmiany UI. To właśnie tutaj SDUI, czyli tworzenie aplikacji z interfejsem użytkownika sterowanym przez serwer, może mieć znaczenie.
Rozwój UI sterowany przez serwer lub backend może zmienić oblicze gry, a sposób jego działania jest bardzo podobny do tego, jak przeglądarki radzą sobie z językami takimi jak HTML i CSS. Zanim jednak zajmiemy się tym, jak działa SDUI i jakie ma zalety, przyjrzyjmy się, czym właściwie jest backend lub server-driven UI.
Czym jest UI sterowane przez serwer?
Interfejs użytkownika aplikacji lub usługi odnosi się do tego, jak wygląda i jak się go odczuwa. Projektant UI musi dbać o to, jak poszczególne aspekty aplikacji są pokazywane, o estetykę, a także o responsywność strony na wielu urządzeniach. Dzieje się tak dlatego, że to właśnie w rejonie ekranu głównego konsumenci angażują się w pracę z witryną.
Interfejs użytkownika strony internetowej jest zdefiniowany przez jej kod HTML. Klienci mogą szybko otrzymać ten kod, gdy odwiedzają witrynę, która zatrudnia rozwój UI po stronie serwera. Kiedy użytkownicy korzystają z takiej aplikacji, strona, projekt, CSS, JavaScript i materiały w witrynie są ładowane podczas pierwotnego żądania.
W tradycyjnym rozwoju aplikacji mobilnej, programista projektuje i pakuje projekt interfejsu użytkownika i wygląd w cyklu wydania. Pakiet oprogramowania jest przesyłany do sklepów z aplikacjami, takich jak sklep Google play, gdzie są one recenzowane przed udostępnieniem do pobrania przez klientów. Interfejsy użytkownika takich aplikacji stają się interaktywne poprzez oddzielenie interfejsu użytkownika od prezentowanej przez niego treści. Informacje są często pobierane z serwera lub backendu i włączane do UI, mimo że interfejs użytkownika jest elementem kodu aplikacji. Jest to zwykły przypadek cyklu wydawniczego w przypadku aktualizacji.
Rozważ przypadek, w którym programiści muszą dodać kilka dużych modyfikacji interfejsu użytkownika do aplikacji. Jak wspomnieliśmy powyżej, deweloperzy muszą przejść przez cały cykl wydawniczy, aby wprowadzić te zmiany. Dzieje się tak dlatego, że logika, która dyktuje sposób wyświetlania informacji, jest zintegrowana z ekranem głównym programu. Po wprowadzeniu niezbędnych poprawek w tym cyklu wydawniczym, muszą przejść przez kolejną rundę recenzji, testów i zatwierdzenia w sklepie Play. Jeśli Twoja aplikacja ma być wydana zarówno na platformie iOS, jak i Android, cykl wydania musi być zakończony dwukrotnie. To może być długi proces, i najprawdopodobniej trzeba będzie oddzielnych programistów dla dwóch platform, ponieważ muszą być zakodowane w różnych językach. Zanim nawet drobne zmiany UI dotrą do użytkowników po cyklu wydawniczym, mogą minąć miesiące.
Różnica od renderingu po stronie klienta
Tradycyjny rozwój wykorzystuje renderowanie po stronie klienta. W tym przypadku, projekt strony, CSS i JavaScript są pobierane po tym, jak klient złoży żądanie. Czasami pewne treści nie zostaną uwzględnione, co zmusza JavaScript do wykonania dodatkowych żądań, aby mieć możliwość wytworzenia niezbędnego HTML.
Takie podejście ma swoje zalety, ale boryka się z problemem wspomnianym powyżej, jeśli chodzi o aktualizacje. Niemniej jednak, może być ono czasami przydatne. Jeśli na przykład tylko niewielki fragment strony został zmieniony podczas korzystania z renderowania po stronie klienta, cała strona nie musi być ponownie renderowana. Renderowanie UI po stronie klienta upewnia się, że wszystkie niezbędne dane zostały w pełni załadowane. Dzięki temu UI po stronie klienta staje się dość szybkie i responsywne. Renderowanie po stronie klienta pozwala również na interaktywne zaangażowanie użytkowników.
W przypadku renderingu po stronie serwera konieczne jest utrzymywanie tego samego skryptu zarówno po stronie klienta jak i serwera aplikacji, co może skutkować wyższymi kosztami operacyjnymi i opóźnieniem rozwoju. Przyjazne dla użytkownika aplikacje po stronie klienta oferują wysoki stopień wydajności. Ale tylko wtedy, gdy niezbędne skrypty JavaScript zakończą ładowanie. Dlatego w takich aplikacjach mogą wystąpić pewne problemy z wydajnością podczas korzystania z telefonów komórkowych i powolnego połączenia internetowego. Różnorodność dostępnych obecnie urządzeń mobilnych może również utrudniać przewidywanie, jak będzie działał rendering po stronie klienta. Programiści budują UI po stronie klienta za pomocą bibliotek takich jak Ember.js, backbone.js i innych.
Zalety UI sterowanego przez serwer
Produkt końcowy interfejsu użytkownika sterowanego przez serwer nie wygląda inaczej niż UI po stronie klienta. Jakie są więc zalety, które oferuje SDUI?
Szybkie aktualizacje
SDUI ma wiele zalet, gdy programiści muszą dokonywać aktualizacji aplikacji. Cykl wydania nowej aktualizacji może trwać nawet kilka tygodni. Dzięki SDUI można to przyspieszyć. Inżynierowie muszą jedynie korzystać z backendu lub aktualizacji po stronie serwera. Nie muszą go testować, ponieważ nie tworzą żadnego nowego kodu. Cykl wydania nie będzie również musiał składać zaktualizowanej wersji aplikacji do sklepów z aplikacjami, takich jak sklep Google play. Nie jest więc potrzebna żadna akceptacja ze strony Apple czy Google. Zmiany, które kiedyś zajmowały miesiące lub tygodnie, mogą być teraz wykonane w ciągu kilku godzin lub dni. Te modyfikacje w cyklu wydawania odzwierciedlają zarówno aplikację iOS, jak i aplikację Android, ponieważ zmiany są wprowadzane bezpośrednio na serwerze.
Łatwiejsze do wdrożenia
Strategia backendowa lub napędzana przez serwer jest zazwyczaj prostsza, jeśli programiści tworzą statyczną stronę internetową. Nie muszą też przejmować się potencjalnymi obawami o SEO, ponieważ strona tworzy statyczny HTML, umożliwiając wyszukiwarkom zobaczenie ich materiałów. Dając przeglądarce mniej pracy, zmniejszasz również szansę na pojawienie się nieprzewidzianych błędów.
Łatwiejsze indeksowanie w mediach społecznościowych
Podobnie jak wyszukiwarki, boty mediów społecznościowych mają problemy z parsowaniem materiału JavaScript. Na przykład, Twitter Cards nie obsługują renderowania po stronie klienta. Podejście do renderowania po stronie serwera może być preferowane, jeśli udostępnianie w sieciach społecznościowych jest istotnym elementem planu marketingowego. Renderowanie aplikacji napędzane przez serwer jest również mniej skomplikowane i bardziej bezpieczne. Przyjrzyjmy się temu szczegółowo.
Zmniejszona złożoność
W pewnych warunkach korzystanie z backendu lub rozwoju interfejsu użytkownika napędzanego przez serwer może być znacznie mniej skomplikowane niż podział na front-end i backend. Z perspektywy dewelopera rozwój UI sterowany przez serwer zmniejsza stres poznawczy. Nie musząc rozważać dwóch środowisk programistycznych, programista może bardziej skupić się na wartości dodanej tworzonej aplikacji. Eliminacja duplikacji znacznie zmniejsza również złożoność tych aplikacji. Oprogramowanie backend API i oprogramowanie UI nie muszą być identyfikowane, ponieważ logika weryfikacji jest obsługiwana w jednym miejscu.
Bezpieczeństwo
Rozwój UI sterowany przez serwer nigdy nie czyni swoich specyfikacji widocznymi dla przeglądarki i dostarcza tylko precyzyjne dane potrzebne do zmiany interfejsu użytkownika. W porównaniu ze scenariuszem, w którym programiści przekazują odpowiednie dane dla określonego kontaktu UI, jest to samoistnie bezpieczniejsza strategia rozwoju. W rezultacie punkty końcowe API nie będą ujawniać zbyt wielu informacji przeglądarce JavaScript. Dzięki temu trudniej jest dokonać włamania lub naruszenia danych. Jest to bardzo ważne dla utrzymania reputacji firmy i kluczowe dla logiki biznesowej.
Zespoły full-stack
Zespoły deweloperskie są często podzielone na różne zespoły. Wymaga to pewnej integracji różnych części oprogramowania po wykonaniu poszczególnych komponentów. Rygorystyczna segregacja frontend-backend może spowodować pewną dozę rozłączności między zespołami, ponieważ poszczególne obszary wymagają specjalistycznej wiedzy. Utrudnia to programistom rozważenie całej logiki biznesowej end-to-end, ponieważ są odpowiedzialni tylko za jedną część.
Jeśli jesteś inżynierem full-stack, będzie to o wiele łatwiejsze do załatwienia. Potencjalne wady lub korzyści z komponentów UI można łatwo zrozumieć. Zespoły full-stack mogą wdrożyć rozwój UI napędzany przez serwer, a potrzeba integracji może być w pewnym stopniu zmniejszona.
Wady UI sterowanego przez serwer
Chociaż używanie backendu lub renderowania napędzanego przez serwer wydaje się prostą koncepcją, głębokość pomysłu wzrasta wraz ze złożonością aplikacji i logiki biznesowej, niektóre z głównych wad związanych z interfejsami użytkownika napędzanymi przez serwer to:
Dłuższy czas ładowania
Podstawową wadą renderingu sterowanego przez serwer jest to, że serwer lub backend tworzy nową stronę internetową dla każdego połączenia z klientem. Następnie klientowi należy ponownie zapewnić dostęp do tej strony. Takie działanie może skutkować brakiem responsywności i dużym wydłużeniem czasu ładowania. Chociaż backend lub renderowanie po stronie serwera jest dobre do tworzenia statycznych stron HTML, może spowolnić wyświetlanie stron internetowych lub ekranu głównego w bardziej skomplikowanych aplikacjach z powodu regularnych wywołań serwera.
Wyższe koszty
Musisz nabyć serwer lub backend bezserwerowy, aby uruchomić aplikację napędzaną przez serwer, co powoduje zwiększenie kosztów operacyjnych. Proces ten może być kosztowny i wymagać dużych zasobów, ponieważ renderowanie sterowane przez serwer nie jest standardem dla stron internetowych w języku JavaScript. Mniejsze firmy mogą mieć trudności z zaoszczędzeniem funduszy na takie serwery.
Niekompatybilność i większy rozmiar HTML
Renderowanie po stronie serwera jest niekompatybilne z niektórymi narzędziami i programami innych firm. Aplikacje napędzane przez serwer mają również większy rozmiar HTML w wyniku zintegrowanego stanu nawodnienia. Należy wziąć to pod uwagę, ponieważ jest to możliwe ryzyko, jeśli zostanie zastosowane niewłaściwie.
Historia interfejsu użytkownika sterowanego przez serwer
Komputery były masywne, kosztowne i przede wszystkim zatrudnione przez większe firmy w latach 60. i 70. Ponieważ nie było możliwe, aby każdy użytkownik miał komputer o szerokości pokoju, powstała technologia mainframe, pozwalająca wielu osobom na korzystanie z jednego systemu komputerowego. Interfejs użytkownika, który był tworzony przy użyciu wyników obliczeń poleceń terminalowych, był następnie dostarczany z powrotem do monitorów w celu prezentacji. Terminale te stały się pierwszymi cienkimi klientami. Cienkie klienty zostały tak nazwane ze względu na ich bardzo ograniczoną moc obliczeniową i zależność od zewnętrznej maszyny do tworzenia interfejsu użytkownika.
Komputer osobisty powstał w wyniku rozwoju mikroprocesora pod koniec lat siedemdziesiątych, co drastycznie zmniejszyło cenę i rozmiary komputerów. Aplikacje były pobierane i działały na przeglądarce każdego użytkownika osobno. PC był samodzielnym komputerem, który był wyposażony we wszystkie niezbędne elementy do wyświetlania interfejsu użytkownika. Te w pełni autonomiczne stacje robocze były pierwszymi grubymi klientami.
Strony internetowe lub aplikacja przeglądana za pomocą przeglądarki internetowej mogła korzystać z wielu zalet cienkiego klienta dzięki powszechnej dostępności Internetu w latach 90. XX wieku. Każdy, kto miał przeglądarkę internetową, a także usługę internetową, mógł korzystać z możliwości obliczeniowych, które znajdowały się centralnie na dedykowanych komputerach zwanych serwerami. Za pomocą HTML, standardowego języka znaczników, serwery tworzyły aplikację interfejsu użytkownika i przekazywały ją do przeglądarki internetowej użytkownika. Przeglądarki internetowe musiały być skonfigurowane na każdej zdalnej przeglądarce, ale miały znacznie mniejsze potrzeby wydajnościowe i często były w stanie rozwiązać problemy operacyjne organizacji.
Telefony komórkowe zaczęły iść do przodu i mieć zdolność do samodzielnego wykonywania aplikacji w latach 2000. Podczas używania telefonu komórkowego jako cienkiego klienta do przeglądania stron internetowych, serwer lub backend musiał przesłać całą aplikację interfejsu użytkownika do telefonu przez internet, podobnie jak w przypadku komputerów osobistych. Jednak w tym czasie, sieci komórkowe były powolne. Przeglądanie stron internetowych było więc frustrujące.
Kiedy w 2007 roku zadebiutował iPhone, zrewolucjonizował to, co można zrobić ze smartfonem. iPhone pojawił się z kompletnym zestawem zainstalowanych programów, zamiast wymagać od użytkowników pozyskiwania oprogramowania za pośrednictwem stron internetowych lub aplikacji. Apple wprowadził App Store, a Android przyjął sklep Google play, umożliwiając zewnętrznym deweloperom tworzenie aplikacji. Te aplikacje zapewniały znacznie lepsze doświadczenie użytkownika, ponieważ wszystko, co było potrzebne do wyświetlania UI, było zawarte w aplikacji i mogło być używane bez usługi internetowej.
W ciągu ostatnich czterdziestu lat dystrybucja oprogramowania odbywała się na przemian na cienkich i grubych klientach, przy czym aplikacje natywne, które są grubymi klientami, dominują na urządzeniach mobilnych. Niektóre z zalet cienkiego klienta zostały rozszerzone na aplikacje natywne przez SDUI. Dzięki strategii rozwoju SDUI, serwery mogą kontrolować porcje interfejsu użytkownika aplikacji natywnej i przesyłać je przez sieć do smartfonów użytkowników. UI wewnątrz aplikacji natywnej może być szybko modyfikowany bez konieczności instalowania nowej wersji oprogramowania.
Ramy i narzędzia dla rozwoju sterowanego przez serwer
Podczas gdy serwer wykonuje renderowanie aplikacji, renderowanie po stronie klienta jest wykonywane przez przeglądarkę. Obecnie dostępne są różne frameworki, a niektóre z najczęściej używanych to:
Jest to darmowy i open-source JavaScript UI framework, który może być połączony z niektórymi innymi narzędziami, aby stworzyć środowisko programistyczne full-stack dla aplikacji internetowych.
Jest to zestaw narzędzi JavaScript, który umożliwia tworzenie elementów aplikacji interfejsu użytkownika wielokrotnego użytku i ich prostą kompozycję w celu budowania ogromnych, wysoce skalowalnych programów.
- Angular
Angular Universal jest narzędziem do rozwoju backend lub napędzanym przez serwer.
Sterowane przez serwer UI i AppMaster
Dzisiaj możesz zbudować aplikację i programy nawet z bardzo małym lub prawie żadnym doświadczeniem w kodowaniu. Jest to możliwe dzięki platformom i narzędziom no-code. Takie platformy pozwalają zarówno programistom, jak i nieprogramistom na tworzenie aplikacji przy użyciu interfejsów użytkownika i konfiguracji, a nie tradycyjnego programowania komputerowego. No-code sprawił, że tworzenie oprogramowania stało się łatwiejsze i bardziej dostępne.
Jest to możliwe dzięki pomocy platform no-code, takich jak AppMaster. Dzięki AppMaster możesz teraz zaprojektować aplikację nawet bez doświadczenia w kodowaniu. Nie musisz też martwić się o prawa do kodu źródłowego, który stworzysz - będzie on należał do Ciebie. Ten kod może być również szybko generowany.
Strategia AppMaster oparta na serwerze umożliwia aktualizacje aplikacji w czasie rzeczywistym. Możesz uzyskać dostęp do sprzętu urządzeń takich jak iPhone'y i iPady bezpośrednio z backendem lub UI napędzanym przez serwer. Twoja aplikacja trafia na rynek prawie 10 razy szybciej niż w przypadku tradycyjnego rozwoju i aktualizacji UI. Możesz wykorzystać użyteczność rozwoju UI opartego na backendzie dzięki AppMaster.
Podsumowanie
Ostateczne pytanie, czy rozwój oparty na serwerze jest odpowiedni dla Twojej aplikacji, zależy od jej funkcjonalności. Jeśli Twoja aplikacja jest dynamiczna i ma wiele elementów, to SDUI może być dla Ciebie dobrym pomysłem. Oprócz korzyści wymienionych powyżej, pomaga również stronom internetowym i aplikacjom w rankingach SEO. Ważne jest, aby zrozumieć zalety i wady rozwoju interfejsu użytkownika sterowanego przez serwer, zanim go wdrożysz. SDUI czasami potrzebuje więcej zasobów, a ty powinieneś być w stanie je zapewnić, jeśli używasz tego samego.
Jeśli chcesz tylko zbudować statyczną stronę internetową, którą chcesz szybko załadować, to użycie prostszego rozwoju po stronie klienta może być dla ciebie lepsze. Ostatecznie powinieneś ocenić potrzeby swojej aplikacji i logikę biznesową, którą wdrażasz, i zdecydować, czy rozwój oparty na backendzie lub serwerze jest dla ciebie odpowiedni.
