Czy dobrym pomysłem jest wykonanie interfejsu użytkownika w 100% w JavaScript i dostarczanie danych przez API?

Moim głównym zadaniem jest tworzenie aplikacji HTML. Mam na myśli wewnętrznie używane aplikacje typu CRUD z dużą ilością edytowalnych widoków siatki, pól tekstowych, rozwijanych menu itp. Obecnie używamy formularzy internetowych ASP.NET, które wykonują zadanie, ale wydajność jest w większości ponura i często musisz skakać przez obręcze, aby zdobyć to, czego potrzebujesz. Obręcze zwisające z sufitu i podpalające.

Zastanawiam się więc, czy dobrym pomysłem byłoby przeniesienie całego interfejsu użytkownika na stronę JavaScript. Opracuj silny zestaw kontrolek wielokrotnego użytku, które są specjalnie dostosowane do naszych potrzeb, i wymieniaj dane tylko z serwerem. Tak, podoba mi się paradygmat „kontrolny” (aka „widget”), który jest całkiem odpowiedni dla takich aplikacji. Tak więc po stronie serwera nadal będziemy mieli podstawowy układ podobny do naszego obecnego znacznika ASPX, ale wtedy zostanie on wysłany do klienta tylko raz, a część Javascript zajmie się wszystkimi kolejnymi aktualizacjami interfejsu użytkownika.

Problem w tym, że nigdy wcześniej tego nie robiłem i nigdy nie widziałem, żeby ktoś to robił, więc nie wiem, jakie byłyby problemy. W szczególności martwię się o:

• Wydajność wciąż. Benchmarking pokazuje, że obecnie główne opóźnienie występuje po stronie klienta, gdy przeglądarka próbuje ponownie renderować większość strony po aktualizacji AJAX. Znaczniki generowane przez formaty WWW ASP.NET nadają nowe znaczenie słowu „web”, a bogate formanty Devexpress dodają do tego własną warstwę złożoności Javascript. Ale czy szybsze byłoby ponowne obliczenie wszystkich niezbędnych zmian po stronie Javascript, a następnie zaktualizowanie tylko tego, co należy zaktualizować? Pamiętaj, że mówię o formularzach, które mają kilka edytowalnych widoków siatki, wiele pól tekstowych, wiele list rozwijanych, z których każda zawiera pół zillionów elementów do filtrowania itp.
• Łatwość rozwoju . Teraz byłoby o wiele więcej Javascript i prawdopodobnie mieszałoby się ze znacznikami HTML strony. Taki lub jakiś nowy silnik widoku musiałby zostać wyprodukowany. Intellisense dla Javascript jest również znacznie gorszy niż dla kodu C #, a ze względu na dynamiczny charakter Javascript nie można oczekiwać, że będzie znacznie lepszy. Praktyki kodowania mogą to nieco poprawić, ale niewiele. Ponadto większość naszych programistów to przede wszystkim programiści C #, więc będzie trochę krzywej uczenia się i początkowe błędy.
• Bezpieczeństwo . Wiele kontroli bezpieczeństwa będzie musiało zostać wykonanych dwukrotnie (po stronie serwera i interfejsu użytkownika), a strona przetwarzająca dane będzie musiała zawierać o wiele więcej. Obecnie, jeśli ustawisz pole tekstowe jako przeznaczone tylko do odczytu po stronie serwera, możesz polegać na tym, że jego wartość nie zmienia się podczas obchodu klienta. Struktura ma już wystarczającą ilość kodu, aby to zapewnić (poprzez szyfrowanie viewstate). Dzięki podejściu opartemu tylko na danych staje się trudniejsze, ponieważ musisz ręcznie sprawdzić wszystko. Z drugiej strony być może luki w zabezpieczeniach będą łatwiejsze do wykrycia, ponieważ będziesz mieć tylko dane do zmartwienia.

Podsumowując, czy to rozwiąże nasze problemy, czy pogorszy je? Czy ktoś kiedykolwiek próbował tego i jakie były wyniki? Czy istnieją jakieś ramy, które pomagają w tego rodzaju przedsięwzięciach (pomijając jQuery i równoważniki moralne)?

Linkedin robi to na swojej stronie mobilnej (patrz http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile część 4), i najwyraźniej było to bardzo korzystne dla nich z punkt widzenia wydajności.

Sugeruję jednak unikanie robienia tego samego z różnych powodów.

Pierwszym z nich jest łatwość konserwacji: C # / ASP.net jest, ponieważ jest to platforma po stronie serwera, niezależna od klienta, podczas gdy Javascript nie jest (nawet z frameworkiem takim jak jQuery nie uzyskasz 100% kompatybilności z różnymi przeglądarkami , a nie na przyszłość). Powiedziałbym też, że łatwiej jest zweryfikować funkcjonalność aplikacji o typie statycznym niż dynamicznej, co jest absolutnie konieczne, jeśli budujesz witryny na dużą skalę.

Drugi polega na tym, że będzie ci trudno znaleźć innych ludzi, którzy są w stanie (i chcą) zbudować aplikację czysto javascriptową, o złożoności niezbędnej do uruchomienia całej witryny (w porównaniu ze względną łatwością znalezienia. Programiści NET). Może to nie dotyczyć bezpośrednio Ciebie, ale z pewnością jest to coś, o czym warto pomyśleć w perspektywie długoterminowej.

Trzecim problemem jest kompatybilność z klientem; jeśli budujesz witryny publiczne, pamiętaj, że rozsądna część sieci nadal nie ma włączonej JS (z różnych powodów), więc musisz być absolutnie pewien, że nie wykluczysz dużej części bazy użytkowników, przechodząc na stronę obsługiwaną przez JS.

Co do twoich wypunktowanych obaw:

• Nie martwiłbym się zbytnio kwestią bezpieczeństwa, nie ma powodu, dla którego nie można mieszać paradygmatów i wykonywać przetwarzania po stronie serwera, gdy wymaga się bezpieczeństwa (zamierzasz mieć kod renderujący widok gdzieś, który zwraca HTML , nie ma powodu, dla którego nie można po prostu odpalić połączenia AJAX, jeśli jest to wymagane).

• Łatwość programowania nie jest tak naprawdę problemem, moim zdaniem, istnieją bardzo dobre narzędzia do programowania JS, nie ograniczaj się do VisualStudio, ponieważ jesteś do tego przyzwyczajony! (spróbuj na przykład JetBrains WebStorm).

• Wydajność silników widoków JS jest w większości przypadków absolutnie dobra (znowu, z mojego doświadczenia), używam ich bardzo często na co dzień. Sugeruję unikanie bardziej rozbudowanych frameworków, takich jak knockout.js itp., I zamiast tego udać się do czegoś w rodzaju silnika mikro szablonów Jona Resiga. W ten sposób możesz podłączyć kod pomocniczy w sposób, który jest pewny, że jest szybki i niezawodny.

Gdybym był tobą, zrobiłbym naprawdę zbadanie przyczyn tej zmiany; Możliwe, że po prostu nie używasz skutecznie platformy .NET i musisz ulepszyć swoją grę, WebForms nie jest szczególnie wolnym szkieletem gotowym do użycia, więc być może niektóre z bibliotek innych firm, których używasz spowalniają renderowanie.

Spróbuj wykonać profil wydajności aplikacji za pomocą testu obciążenia i narzędzia do profilowania i sprawdź, gdzie są twoje wąskie gardła, zanim pochłoniesz dużo czasu i wysiłku w bardziej radykalnym rozwiązaniu, prawdopodobnie będziesz zaskoczony tym, co znajdziesz jako sprawca spowolnienia!

Użyj ExtJS, jeśli chcesz iść tą drogą, nie wymyślaj koła ponownie. Ale bądź przygotowany, oznacza to całkowitą zmianę paradygmatu. Umiejętności HTML są prawie przestarzałe. AJAX wszędzie, serwer głównie zapewnia API AJAX. Napiszę o wiele więcej skryptów javascript niż kiedykolwiek, więc lepiej upewnij się, że naprawdę dobrze się posługujesz javascript.

Zespół, w którym pracuję, zdecydował się na migrację do ExtJS pod koniec 2008 roku. W tym momencie mieliśmy 200 000 liniową aplikację PHP, która cierpiała z powodu problemów z interfejsem. Nasza sytuacja była znacznie gorsza niż twoja, ponieważ mieliśmy ramy kontrolowania formularzy, które były naprawdę złe, i intensywnie korzystaliśmy z ramek iframe do ładowania sekcji strony (architektura wizualna pochodzi z 2005 roku, a zespół nie był tego świadomy z ajax, że wcześnie). W każdym razie musieliśmy zmienić kod, więc to ułatwiło zdecydowaną ponowną zmianę bazy kodu, aby była przede wszystkim po stronie klienta.

Dziś aplikacja ma 300 000 linii, z czego 60 000 linii to kod extjs, a około 3/4 funkcjonalności zostało przeniesionych do ExtJS. Kod extjs jest aplikacją jednostronicową, ale nadal osadza niektóre starsze formularze w ramkach iframe. Najpierw przenieśliśmy się nad kontenerem nawigacyjnym, a następnie przeprowadziliśmy migrację poszczególnych obszarów funkcji fragmentarycznie. Dzięki takiemu podejściu udało nam się przenieść migrację extjs do zwykłego procesu tworzenia funkcji, bez zbytniego spowalniania nas.

• Występ

  Kod ExtJS okazał się znacznie szybszy niż starszy kod. Stary kod był oczywiście bardzo kiepski pod względem wydajności, ale mimo to jesteśmy zadowoleni z wyników. Kod interfejsu użytkownika jest w całości statycznym javascript, więc buforuje się bardzo dobrze (jesteśmy na etapie planowania, aby wrzucić go do CDN). Serwer nie uczestniczy w renderowaniu frontonu, co zmniejsza obciążenie. Pomaga również, że ExtJS zapewnia dużą kontrolę nad cyklem życia interfejsu użytkownika (leniwe renderowanie, łatwe rozładowywanie niewidocznych elementów interfejsu użytkownika). Zazwyczaj po załadowaniu kodu (architektura ładowania na żądanie) większość czasu ładowania ekranu jest spędzana na wywołaniu usługi internetowej w celu pobrania danych. Siatka ExtJS jest naprawdę szybka, szczególnie przy użyciu buforowanych widoków do renderowania widocznych wierszy na przewijaniu.

• Łatwość rozwoju

  Szczerze mówiąc, ta torba jest mieszana. ExtJS to DSL, nie jest to tak naprawdę tworzenie stron internetowych w tradycyjnym tego słowa znaczeniu. Długo zajęło naszym programistom nauczenie się interfejsu API frameworka i nie widzę, aby krzywa była mniej stroma na innych frameworkach po stronie klienta. Wszyscy w zespole muszą być „starszymi” programistami JavaScriptu (z reguły książka Crockforda nie powinna zawierać tajemnic). Mamy problemy z bootstrapowaniem nowych programistów, ponieważ wiedza po stronie klienta nie jest tak powszechna, jak mogłoby się wydawać, a wiedza na temat extj jest prawie zerowa (w Belgii, gdzie się znajdujemy).

  Z drugiej strony, gdy jesteś na bieżąco, doświadczenie deweloperów jest bardzo miłe. ExtJS jest bardzo potężny, więc jeśli jesteś w rytmie, możesz bardzo szybko podnieść niesamowite ekrany. Jeśli chodzi o IDE, korzystamy z PHPStorm, który moim zdaniem jest wystarczająco kompetentny w zakresie kodu ExtJS.

• Bezpieczeństwo

  Bezpieczeństwo jest jednym z głównych powodów, dla których warto korzystać z interfejsu użytkownika po stronie klienta. Powód jest prosty: zmniejszenie powierzchni ataku. Interfejsy API usług sieciowych używane przez nasz kod ExtJS są znacznie mniejszą powierzchnią ataku niż warstwa interfejsu użytkownika po stronie serwera. ASVS OWASP określa, że ​​przed użyciem należy sprawdzić poprawność wszystkich danych wejściowych na serwerze. W architekturze usług internetowych oczywiste i łatwe jest, kiedy i jak przeprowadzić sprawdzanie poprawności danych wejściowych. Łatwiej jest mi też uzasadnić bezpieczeństwo w architekturze interfejsu użytkownika po stronie klienta. Nadal mamy problemy z XSS, ponieważ nie jesteś zwolniony z kodowania do HTML, ale ogólnie jesteśmy znacznie lepsi pod względem bezpieczeństwa niż na starej bazie kodu. ExtJS ułatwia sprawdzanie poprawności pól formularza po stronie serwera, więc nie cierpimy z powodu konieczności dwukrotnego pisania kodu.

Jeśli możesz sobie pozwolić na nieobsługiwanie użytkowników bez skryptów, a wyszukiwarki nie dotyczą ciebie, to tak, jest to całkowicie realne podejście. Oto krótki przegląd zalet i wad:

Plusy:

• wszystko w jednym miejscu (javascript)
• możesz ładować dane z serwera, a nie znaczniki, co może zaoszczędzić dużo przepustowości, jeśli zrobisz to poprawnie
• łatwiej uzyskać responsywną aplikację (nadal występuje opóźnienie sieci, ale początkowa reakcja na dane wejściowe użytkownika przychodzi szybciej)
• serwer WWW nie musi renderować żadnego HTML ani rozszerzać żadnych szablonów (tj. nakłady przetwarzania są przenoszone z serwera na klienta)

Cons:

• wszystko musi być w javascript (może, ale nie musi być problemem)
• logika krytyczna musi zostać zduplikowana na serwerze
• stan musi być utrzymywany na kliencie i serwerze i synchronizowany między nimi
• bezpieczeństwo może być trudniejsze do uzyskania (biorąc pod uwagę, jak złośliwi użytkownicy mogą manipulować dowolnym kodem po stronie klienta)
• ujawniasz dużą część swojej bazy kodu (kodu działającego na serwerze nie widać z zewnątrz)

Osobiście myślę, że jeśli pójdziesz tą drogą, ASP.NET UpdatePanels nie są właściwą drogą. Doskonale nadają się do częściowej licytacji istniejących aplikacji internetowych, ale nadal wysyłają HTML przez AJAX, a zarządzanie stanem w ten sposób może być dość owłosione. Lepiej przejdź całą drogę, serwując tylko statyczny dokument HTML, a następnie użyj biblioteki szablonów javascript do renderowania HTML; serwer nie obsługuje żadnego dynamicznego HTML, zamiast tego klient wykonuje wywołania na poziomie logiki biznesowej na serwerze i odbiera surowe dane.

Tak, ale ...

Musisz upewnić się, że masz płynną „degradację”, aby krytyczne części aplikacji nadal działały bez Javascript.

W ten sposób buduję większość aplikacji w stylu „HIJAX”.

Moja strona wciąż jest w powijakach, ale jak dotąd 100% js ui było dla mnie w porządku. Jedyną logiką serwera, która istnieje w interfejsie, są mapowania modeli i adresy URL ajax. Serwer nie ma żadnej wiedzy o interfejsie użytkownika, co jest dla mnie bardzo łatwe w utrzymaniu. Jeśli jesteś zainteresowany, możesz sprawdzić moją stronę, która jest napisana w ExtJS http://coffeedig.com/coffee/ . Moja witryna tak naprawdę nie ma problemów z bezpieczeństwem, ale klient pomaga zwykłemu użytkownikowi poprzez prostą weryfikację. Wiem, że złośliwy użytkownik może naprawdę wysłać dowolną ajax na serwer, więc cała logika „bezpieczeństwa” jest wykonywana na serwerze.

Myślę, że największym problemem dla ciebie jest to, że będziesz całkowicie odwracać to, do czego przyzwyczajony jest twój zespół, pojawi się stroma krzywa uczenia się. Myślę, że najlepszym podejściem byłoby eksperymentowanie z niektórymi frameworkami js i próba sprawdzenia tego, pisząc kilka prostych ekranów.