Strategie generowania widoków w przeglądarce

Zielona szkoła
1

Obecnie jest dość chyba mocny trend przerzucania dużej części logiki aplikacji na klienta (przeglądarkę) i implementowanie tego w JS. Serwer wtedy zajmuje się tylko przetwarzaniem requestów i zwracaniem wyników w postaci JSONa przeważnie. Przy takim podejściu nie potrzeba żadnych widoków po stronie serwera.

Moje pytanie jest jakie podejście stosujecie w swoich projektach? Uzywacie partiali i wysyłania mixa HTML + JS do klienta ajaxem, czy wysyłacie tylko dane, a prezentacją zajmuje się klient?

Dodatkowo jakie są wady i zalety obu rozwiązań z punktu widzenia doświadczonych w temacie ludków? Jeśli wysyłacie do klienta partiale, jak miksujecie JS z HTML?

2

Doprecyzowywując twoje stwierdzenie: przerzucana jest część widokowa aplikacji a nie logika. Logika wciąż zostaje po stronie serwera. Wiem, czepiam się.

3

No, to już zależy od aplikacji.

Zalety dzielenia nad mieszaniem:

  • API musi zostać zaimplementowane od razu, więc podpięcie nowych klientów jest ułatwione
  • przy skomplikowanych aplikacjach może to pomóc w utrzymaniu kodu - lepsza izolacja i często lepsze ułożenie kodu js
  • mniej do roboty na serwerze

Zalety mieszania nad dzieleniem:

  • na pewno jest prościej na początku
  • nie trzeba się martwić o ilość requestów po dane, bo wszystko jest składane na serwerze

Według mnie wszystko zależy od tego jakiego typu to aplikacja. Jeżeli nie ma potrzeby, żeby google to crawlował i jest to rzeczywiście aplikacja, to ja bym poszedł w API + klient w javascripcie. Jeżeli jest jakiś content i google to crawluje, to raczej nie ma tego jak wygodnie zrobić. Dużo zależy też od tego jaki masz team, jaki budżet, jak skomplikowana to aplikacja będzie. Na pewno początkowo szybciej i prościej będzie ze “standardową” aplikacją railsową, proporcje odwrócą się przy odpowiednim skomplikowaniu i czasie tworzenia aplikacji.

4

No, to już zależy od aplikacji.[/quote]
Co więcej, czasem ta “logika” znajduje się po stronie serwera i klienta jednocześnie. Zdarza się, że po zaimplementowaniu API w Rubim, implementujemy dokładnie te same rzeczy w JS. W takich przypadkach lepiej zastanowić się nad możliwością współdzielenia tych “bebechów” przez serwera i klienta, co w zasadzie wymusza pisanie całości w JS.

5

Logika to szerokie pojęcie więc długo moglibyśmy tak dyskutować :slight_smile: Nie zmienia to faktu, że duża jej część musi wciąż być po stronie serwera byśmy byli bezpieczni. Walidacje muszą być, w przeglądarke nie wrzucimy łączenia się z bazą i updateowania rekordów bo to zbyt niebezpieczne także. To mniej więcej miałem na myśle ale to chyba każdy wie.

6

No, to już zależy od aplikacji.[/quote]
Co więcej, czasem ta “logika” znajduje się po stronie serwera i klienta jednocześnie. Zdarza się, że po zaimplementowaniu API w Rubim, implementujemy dokładnie te same rzeczy w JS. W takich przypadkach lepiej zastanowić się nad możliwością współdzielenia tych “bebechów” przez serwera i klienta, co w zasadzie wymusza pisanie całości w JS.[/quote]
wspoldzielic tez mozna w druga strone

http://railscasts.com/episodes/297-running-javascript-in-ruby

7

paneq, z tą logiką to fakt - skrot myślowy. Chodziło mi o logikę prezentacji widoków (gdzie chociażby cała logika różnych dziwnych wyliczeń itd jest robiona przez klienta, a nie wypluwana gotowa przez serwer). Oczywiście walidacje itp zostają na serwerze, bezdyskusyjnie.

Ciekawi mnie poprostu obecne podejście do tematu w dobie prężnie rozwijających się i powstających frameworków MVC i innych pomocnych rzeczy pod JS.
Dzięki za info.

8

Wyłącznie na serwerze? Ja bym tej kwestii nie nazwał bezdyskusyjną :-D.

9

A widzisz gdzieś tu “wyłącznie”?
Bezdyskusyjne jest dla mnie to, że na serwerze MUSI być walidacja. Czy część z niej zduplikujemy po stronie klienta to już inna bajka.

10

trochę odgrzebię temat :wink:

jeżeli już zdecydujemy się rozdzielić appke na API i frontend w JS to co waszym zdaniem jest najlepszym wyborem (mówię tu o frameworkach js)? To co pierwsze “rzuca się w oczy” to Sproutcore, Backbone.js, Cappucino, Spine, JavaScriptMVC i pewnie multum innych.

Cappucino odrzucam na wstępnie ze względu na składnie Obj-J a’la Obj-C.

Najbardziej podoba mi się Sproutcore, ale nie ma w dokumentacji nic o podpięciu do server-side API (jest coś tylko w deprecated wiki). Backbone i Spine natomiast wspominają o podpięciu Railsów (co prawda to może być każde inne RESTowe API, ale fajnie że podają akurat na przykładzie ror).

Jest może jakieś rozwiązanie która działałoby automagicznie jak ActiveResource?

11

[quote=zlw]trochę odgrzebię temat :wink:

jeżeli już zdecydujemy się rozdzielić appke na API i frontend w JS to co waszym zdaniem jest najlepszym wyborem (mówię tu o frameworkach js)? To co pierwsze “rzuca się w oczy” to Sproutcore, Backbone.js, Cappucino, Spine, JavaScriptMVC i pewnie multum innych.

Cappucino odrzucam na wstępnie ze względu na składnie Obj-J a’la Obj-C.

Najbardziej podoba mi się Sproutcore, ale nie ma w dokumentacji nic o podpięciu do server-side API (jest coś tylko w deprecated wiki). Backbone i Spine natomiast wspominają o podpięciu Railsów (co prawda to może być każde inne RESTowe API, ale fajnie że podają akurat na przykładzie ror).[/quote]
Sproutcore jak sam zauważyłeś jest słabo udokumentowany, więc jakbyś zaczynał to przygotuj się do kopania w kodzie :wink: Pisałem plugin do railsów, do łatwego spięcia sproutcore’a i railsów: https://github.com/drogus/bulk_api, w teorii wystarczy określić tylko jakie modele chcesz udostępnić i używasz BulkApi datasource. Pomysł i częściowo API było Yehudy, ja to zaimplementowałem jako eksperyment, ale to się raczej nie sprawdzi dla bardziej skomplikowanych case’ów. Dodatkowo datastore jest z czasów 1.x i też nie wiadomo czy nie będzie przepisany. Jednym słowem grząski grunt jeżeli oczekujesz czegoś kompletnego na tą chwilę. Prawdopodobnie w najbliższych tygodniach będę robił coś w strobę poprawienia sytuacji, ale nie wiadomo czy i kiedy coś z tego wyjdzie.

Co do samego pytania, to tutaj akurat mógłbyś korzystać z deprecated wiki, bo nie ma nowego datastore’a dla 2.x, więc wszystko działa tak samo jak w 1.x (jeżeli chodzi o modele i datasource).

Co do Backbone’a, to jest to fajny i malutki projekt, ale nie załatwia Ci automatycznego update’u widoków, więc dalej musisz sam reagować na zmiany. Będę go chyba używał do jednej prostej aplikacji, więc może niedługo będę mógł więcej powiedzieć.

Cappucino wygląda bardzo fajnie, ale dla mnie również odpada ze względu na Obj-J. Dla developerów iosa pewnie to będzie bardzo fajny wybór.

Spine też jest ciekawy, ale twórca go ostatnio zbyt często nie aktualizuje i nie jest zbyt popularny, więc nie wiadomo jak będzie z rozwojem. Ale sprawdzić pewnie warto, być może kod jest na tyle prosty, że nie trzeba się bać.

12

Widziałem Twojego gem-a i właśnie czegoś takiego szukam - dedykowanego rozwiązania dla fw client-side i server-side, ale trochę odstraszyło mnie

Będziecie jakoś rozwijać to (lub podobne) rozwiązanie? W sumie dziwi mnie, że Sproutcore nie ma wgrzanej (albo chociaż jakiegoś production ready pluginu) fajnej pracy z RoR, w końcu paru Railsowców macie w teamie :wink:

13

Co do bulk_api, to nie jestem przekonany, że to jest dobra droga. Tzn. może jak uproszczę plugin i zaznaczę, że to tylko do najprostszych sytuacji, w których nie wychodzisz dużo poza CRUDa. Kłopot w tym, że połowa ludzi zaczynała by pewnie od CRUDa, a kończyła na wielkiej złożonej aplikacji i krzyczeliby, że przez bulk_api muszą sie męczyć :wink: Na pewno będę chciał pociągnąć temat, ale tak jak mówiłem, nie wiem co, kiedy i jak.

Co do samego podłączenia railsów i sproutcore’a, to można zrobić to bez żadnych pluginów, ale niestety mało o tym dokumentacji. Przed 17 grudnia pewnie nie znajdę na to czasu, ale później bliżej świąt mogę sprobować napisać jakieś guide’y o tym jak to robić.

14

Wiadomo, że się da. Fajnie by było gdyby był do tego jakiś dedykowany plugin (coś jak ActiveResource).

Ooo, byłoby super :wink: Bo teraz trochę ciężko przebrnąć przez brak dokumentacji. Przynajmniej na początku, później to wiadomo, że szybciej zajrzeć w kod i zobaczyć jak coś działa :smiley:

15

@drogus a używałeś może sproutcore-resource? wygląda całkiem fajnie. pytanie tylko jak sprawuje się w praktyce

16

Na pierwszy rzut oka wygląda fajnie, przyjrzę się :slight_smile:

17

[quote=zlw]Najbardziej podoba mi się Sproutcore, ale nie ma w dokumentacji nic o podpięciu do server-side API (jest coś tylko w deprecated wiki). Backbone i Spine natomiast wspominają o podpięciu Railsów (co prawda to może być każde inne RESTowe API, ale fajnie że podają akurat na przykładzie ror).

Jest może jakieś rozwiązanie która działałoby automagicznie jak ActiveResource?[/quote]
Sprawdź http://batmanjs.org/. Strukturę kodu ma podobna do rails’ów. Pisze się w coffeescript wiec składnia też jest bliższa ruby. Ma też proste zapisywanie obiektow do aplikacji napisanej w railsach.

18

[quote=martinciu][quote=zlw]Najbardziej podoba mi się Sproutcore, ale nie ma w dokumentacji nic o podpięciu do server-side API (jest coś tylko w deprecated wiki). Backbone i Spine natomiast wspominają o podpięciu Railsów (co prawda to może być każde inne RESTowe API, ale fajnie że podają akurat na przykładzie ror).

Jest może jakieś rozwiązanie która działałoby automagicznie jak ActiveResource?[/quote]
Sprawdź http://batmanjs.org/. Strukturę kodu ma podobna do rails’ów. Pisze się w coffeescript wiec składnia też jest bliższa ruby. Ma też proste zapisywanie obiektow do aplikacji napisanej w railsach.[/quote]
O, właśnie zapomniałem tego podrzucić. Nie używałem, ale wygląda obiecująco. No i ten przyklad na stronie głównej (kolekcja wyświetlana jako lista ul z dorzuconym na końcu zupełnie innym elementem li), jest teraz właściwie nie do zaimplementowania w sproutcorze, ze względu na to jak działa helper ‘collection’.