Pytanie Podnieś, graj! lub BlueEyes (z pakietem Javascript Framework)


Czuję się trochę zakłopotany. Buduję nową, nowoczesną aplikację internetową i nie tylko muszę wybrać technologię, muszę wybrać architekturę. Uważam, że uczciwie jest powiedzieć, że obecnie jest to trudny wybór, ponieważ mamy więcej opcji niż jeszcze 5 lat temu.

Po pierwsze, podjąłem decyzję, że Scala będzie językiem po stronie serwera. Mam swoje powody i nie jest to Scala kontra post XYZ - wybór został dokonany. Doszedłem także do tego, że jesteśmy w Internecie, w chmurze, więc nawet nie spróbuję uciec przed Javascriptem. Może zrobię to z CoffeeScript, ale będę pisał kod obsługiwany przez przeglądarkę.

Teraz, zakładając Scalę, większość ludzi prawdopodobnie przeskoczyłaby do obu Grać! lub Winda. Prawdopodobnie graj! biorąc pod uwagę to potwierdzenie od Typesafe, ale myślę, że mam jeszcze jedno ważniejsze pytanie, na które najpierw trzeba odpowiedzieć. Co to jest architektura? Jeśli chcę bardzo bogatego klienta, czy naprawdę potrzebuję czegoś więcej niż prostej bezpaństwowej warstwy usługowej opartej na tym, że i tak będziemy mieli mnóstwo JavaScript? Nie jestem pewien, czy będzie to pojedyncza strona internetowa, ale jest coś takiego Niebieskie oczy potencjalnie właściwy wybór? Podnieś i graj! są znacznie ważniejsze, ponieważ ponoszą znacznie więcej odpowiedzialności. Generują HTML i dla tych frameworków przeglądarka jest dość głupia. Rzeczy takie jak routing, sprawdzanie poprawności, obsługa Ajax i Comet są problemami po stronie serwera. Ponieważ przeglądarka jest dziś bardziej wydajna, bogate, interaktywne funkcje są zwykle implementowane poprzez generowanie i wstrzykiwanie kodu JavaScript z serwera.

Moje pytanie sprowadza się do tego. Czy idę z tradycyjnym Lift / Play! ramy, w których serwer przejmuje odpowiedzialność zarówno klienta, jak i serwera, czy też mam do czynienia z warstwą usług Rich Client + REST, w której klient zajmuje bardziej znaczącą rolę w aplikacji? Architektura, w której klient zajmuje się routingiem, sprawdzaniem poprawności, wiązaniem itp. Widzę takie frameworki jak KnockOut.js, Sammy.js, Sproutcore, Backbone.js, ... Nie będę ich wszystkich wymieniał, ale wystarczy powiedzieć, że wszystkie te funkcje ramowe przyjmują z perspektywy klienta.

Jeśli wybiorę Play !, czy zrezygnuję z tego bogatego interfejsu? A co z sytuacjami, w których chcę udostępnić API usług do celów integracji / mashup / urządzeń mobilnych? Jak grać! pomóż mi tutaj? Oczywiście BlueEyes dobrze tu gra. Myślę, że potrzebuję warstwy usługi niezależnie.

Jeśli wybieram BlueEyes, jak wygląda mój kod klienta? Ile z tych frameworków opartych na JavaScript potrzebuję, aby dać mi to, czego potrzebuję? Nadal chcę większość logiki biznesowej w mojej warstwie usług, ale routing, bindowanie. Wszystko, co w interfejsie użytkownika byłoby problemem klienta.

Nie jestem pewien, czy istnieje właściwa czy zła odpowiedź, ale myślę, że ta wspólnota prawdopodobnie wskaże mi właściwy kierunek.

Też zaksięgowałem to na moim blogu na http://www.andyczerwonka.com/picking-a-web-technology-isnt-as-easy-as-i- 45228


21
2018-02-09 21:43


pochodzenie


Nie po to, żeby cię odstraszyć od Scali, ale może ci się spodobać Haskell i Yesod. Yesod jest najwyraźniej bardzo wyluzowany. - Dan Burton


Odpowiedzi:


Play 2.0 Beta zawiera przykładową aplikację, która jest dokładnie tym, czego szukasz (ZenContacts). Jego strona serwerowa to tylko kilka spokojnych interfejsów, podczas gdy strona klienta wykorzystuje coffeescript itp., Aby zbudować bogaty interfejs użytkownika.


4
2018-02-10 23:45



Miły. Zobaczę. Może być dokładnie tym, czego szukam. - andyczerwonka
Aplikacja mówi, że w kodzie kręgowym brakuje modeli i szablonów po stronie klienta i nie jest to zalecane w rzeczywistości. Czy architektura zentasków jest ogólnie zalecana? Dlaczego mielibyśmy potrzebować widoków i modeli w Google Play? - Alexy
Osadziłem się na AngularJS na przednim końcu - andyczerwonka
Dzięki za wzmiankę o ZenContacts! - Flar


Jeśli chcesz tylko API REST na zapleczu, a następnie Podnieś, graj! albo Blueye będzie działało dobrze. Ale wskażę zalety korzystania z windy.

  1. Nie jest prawdą, że Lift stara się narzucić zarówno przód, jak i tył. Wspieramy korzystanie z funkcji Lift tylko z wykorzystaniem Lift i zachęcamy do właściwego projektu.
  2. Podczas gdy Lift pochodzi z jQuery i blueprint, możesz użyć dowolnej biblioteki javascript i frameworku css, obecnie na liście mailingowej znajduje się wiele osób, które pokazują, w jaki sposób używają one Twitter boost z Lift. Zobacz Moduł windy to pomaga w integracji Bootstrapa.
  3. Za pomocą Lift możesz zacząć bezpaństwowcem, a jeśli zauważysz, że zmieniają się twoje potrzeby, możesz przejść do stanu statefull. Możesz nawet mieszać i dopasowywać je do tej samej aplikacji.
  4. Potrzebujesz nowoczesnego wyglądającego interfejsu użytkownika? Wsparcie komety windy jest jednym, jeśli nie najlepszym, tam. Bardzo prosty w obsłudze, sprawdzony i przetestowany na wielu przeglądarkach / obciążeniach. napisałem kilka postów prezentujący wsparcie komety Lift.
  5. Jeśli zdecydujesz się użyć Lift dla obu, z przodu iz tyłu, otrzymasz za darmo aplikację, która jest zabezpieczona domyślnie, nie musisz martwić się o xss, xsrf lub wiele z 10 najlepszych luk w zabezpieczeniach OWASP.
  6. Potrzebujesz wsparcia komercyjnego, pojawia się rosnąca lista tutaj
  7. Potrzebujesz szkolenia? Tam jest Trening podstawowy przyjeżdżając do Londynu i założyciel Lift również zapewnia inne szkolenia.
  8. Dostępnych jest kilka książek o Lift. Podnieś w akcji , Po prostu podnieś i Exploring Lift
  9. Jest bardzo aktywny społeczność gotowy do pomocy.
  10. Kto korzysta z windy? Żeby wymienić tylko kilka: Foursquare , OpenStudy , The Guardian UK, StackMob i wiele więcej.

Cóż, powinienem zatrzymać się tutaj, ale w skrócie, Lift to niesamowity framework, który ma wiele do zaoferowania, bierzesz tyle, ile potrzebujesz.


18
2018-02-10 05:51



Przez kilka lat byłem członkiem społeczności Windy i zbudowałem z nią kilka rzeczy. Jestem zaznajomiony i zgadzam się, że jest on w stanie poradzić sobie z moim przypadkiem użycia. Pytanie dotyczy raczej tego, ile z tego używam. - andyczerwonka
Jeśli w końcu potrzebujesz tylko REST APi, wtedy Lift nie będzie przeszkadzać, po prostu złożysz to razem przedłużając RestHelper i odejdziesz, nie musisz się martwić o mapę witryny, kometę, ajax, cokolwiek. Więc nie czujesz wagi ciężkiej, ani co masz na myśli przez "ile tego używam?" - fmpwizard
Tak, to w porządku. - andyczerwonka
Lubię Winda, ale trochę się boję, że odejdzie. Teraz, kiedy David w większości wyjechał, by robić inne rzeczy z Visi ... Miałem nadzieję, że skoczyłby na Typesafe, ale coś nie dopuściło do tego. Szkoda, bo myślę, że to boli społeczność windy za tonę. - andyczerwonka
Przy okazji, dlaczego dajesz "wsparcie" typesafe tak dużo? Poszedłbym tam, gdzie przedstawiono lepsze rozwiązanie, a nie tam, gdzie została podjęta większa kampania marketingowa. tylko moje kilka centów :) btw nie mam nic przeciwko typesafe, po prostu uważam, że pomysł jest nieco dziwny. - Franz Bettag


O ile mi wiadomo, zarówno Play! a Lift może być w zasadzie "zapleczem", a możesz używać HTML5 + CSS + JS jako swojego "interfejsu"; niekoniecznie ograniczają twoją zdolność do tworzenia pożądanego frontu, więc odrzucenie ich z tego powodu byłoby głupie. Zwróć uwagę na takie rzeczy jak knockout.js, które reklamują, że "działają z dowolnym środowiskiem sieciowym". Jednak może być prawdą, że są bardziej "wadze ciężkiej" niż to, czego potrzebujesz.

Nigdy wcześniej nie słyszałem o BlueEyes, ale wydaje się, że ma na celu konkretny przypadek użycia. Jeśli to pasuje do twojego rachunku, to prawdopodobnie będzie to najbardziej usprawnione rozwiązanie twojego problemu.

Ale jeśli jest to coś, co planujesz umieścić w sieci, "routing, sprawdzanie poprawności, wiązanie itd." Praktycznie potrzeba do obsługi przez tylny koniec; Po prostu nie mogę sobie wyobrazić żadnej z tych rzeczy (bezpiecznie) obsługiwanych przez kod działający w przeglądarce klienta. Ponadto, jeśli Twoi użytkownicy zdecydują się wyłączyć JavaScript, Twoja strona będzie całkowicie bezużyteczna.


4
2018-02-09 23:06



Tak, oczywiście można go wtedy użyć w ten sposób. Lift ma pomocników Rest, które pozwalają ci obsługiwać usługi JSON, ale to nie jest główny przypadek użycia. Podstawowym zastosowaniem platformy Lift jest kompleksowe środowisko sieciowe, nawet domyślnie zakłada ona jQuery i Blueprint, ponieważ nie chce, abyś polegał na czymkolwiek innym. Nie jestem pewien, czy jest to praca z ramami po stronie serwera w nowym świecie bogatych klientów. Niepewny. - andyczerwonka
Twój ostatni komentarz na temat wyłączania JavaScriptu - jeśli użytkownicy uniemożliwiają nie tylko moją aplikację, wyłączają Internet. - andyczerwonka
"w nowym świecie bogatych klientów" :) Będziemy najwyraźniej wiecznie kołysać się pomiędzy "Chmurą / cienkim klientem" a "Bogatym klientem / minimalnym backendem". W każdym razie, jestem prawie pewien, że Lift, Play, a nawet BlueEyes zapewniają wystarczająco dużo elastyczności, aby być użytym w sposób, w jaki sobie tego życzysz, bez wchodzenia w drogę. Większość zręcznego rusztowania i mocy ram będzie niepotrzebna dla twojego projektu, ale niekoniecznie oznacza to, że używanie tych frameworków jest złym pomysłem. - Dan Burton
Myślę, że to kwestia ostrości. Nie sugeruję w ogóle "minimalnego zaplecza", tylko jeden koncentruje się na obsłudze danych, przetwarzaniu, obliczeniach itp. Ponownie, nie jestem pewien, czy istnieje odpowiedź, więc myślę, że szukam plusów / minusów dyskusja. - andyczerwonka


Jeśli wybiorę Play !, czy zrezygnuję z tego bogatego interfejsu?

Co dokładnie masz na myśli przez bogaty interfejs użytkownika? więcej javascript na interfejsie?

Jeśli weźmiesz pod uwagę - HTML5 + CSS3 + jQuery jako bogaty interfejs użytkownika - to działa bardzo dobrze z każdym "zapleczem" (Lift / Play).

Inną rzeczą, którą możesz chcieć rozważyć, jest dojrzałość ramach. Jak wspomniałeś Play 2.0 wspiera Scala natywnie, ma poparcie dla Typesafe i jest szybko adoptowany. Dodatkowo możesz łatwo udostępnić usługi RESTful i skonsumować je w interfejsie (jedno z twoich wymagań).

Przechodząc w stronę HTML5 + CSS3 + jQuery + Play 2.0 :)

tylko moje myśli ...


2
2018-02-10 07:25



Wciąż rozwijana jest gra w wersji 2.0, z poprawionymi błędami każdego dnia i brakiem kompletnej dokumentacji. To nie jest tak dojrzały jako Play 1.0, mimo że Play 1.0 miał mniej dokładną obsługę Scali. - Marcus Downing
Zgadzam się - wyciągam od mistrza i doświadczam go w pierwszej klasie! :-) - andyczerwonka


Co to jest architektura?

Grać! zdecydowanie zachęca twój serwer do korzystania z architektury MVC, tworząc pakiety w standardowym wzorcu:

app/
  controllers/
    Application.scala
  views/
    Application/
      index.scala.html
  models/
public/
  images/
  stylesheets/
  javascripts/

Dzięki temu łatwiej jest podążać za architekturą niż ją łamać.

Nie mogę mówić zarówno o Lift, jak i BlueEyes, ale afaika żadne z nich nie zachęca do tak silnej architektury.


0
2018-02-10 15:51



Powiedziałbym, że Lift to więcej torebek narzędzi. To świetnie, dla odpowiedniego zespołu i właściwego problemu. BlueEyes tak naprawdę nie porównuje tego, że jest bardzo skoncentrowany na obsłudze żądań HTTP i nie przyjmuje żadnych założeń co do konsumenta. - andyczerwonka
Tak naprawdę nie pytam o View-First (Lift) kontra MVC (Play!), Bardziej interesuje mnie, jak bardzo serwer bierze udział w problemach ze strony klienta. - andyczerwonka
W takim przypadku żadna z wymienionych ram nie powinna w ogóle wywrzeć wpływu na architekturę po stronie klienta. - Marcus Downing
Nie muszą grać tej roli, nie. Ale są zbudowane z takim zamiarem. - andyczerwonka


Na pewno popatrz http://twitter.github.com/finagle zanim wymyślisz umysł Yiir. Finagle może zadbać o większość twoich backendowych rzeczy. Wyróżnia się bardzo elastyczną architekturą, która rozróżnia sprytnie przy użyciu filtrów.


0
2018-02-10 21:29



Fajnie, dzięki, bardzo interesujące. Wpadłem na to wcześniej, ale nigdy nie nurkowałem. Wydaje się podobne do BlueEyes (oba są zbudowane na bazie Netty), ale BlueEyes jest tylko HTTP, więc Finagle jest jeszcze dalej w drzewie abstrakcji. The Przykład serwera HTTP wydaje się niesamowicie podobny do BLleEyes. - andyczerwonka


Spojrzałem na kliknięcie Apache, furtkę, trochę Lift (czuję się trochę jak furtka), a następnie gram 1.2.4. Jak na razie dobrze z Play. Naprawdę piękne podejście do tworzenia stron internetowych. Trzymaj się dobrej pracy, graj! zespół.


0
2018-02-13 01:36