Przy okazji Rails Rumble publikowane są zestawienia komponentów aplikacji webowych.
Chciałem zapytać o wasz optymalny zestaw, w odniesieniu do nastepujących elementów:
Odpowiedzi mogą być bardzo subiektywne (tzn. nie używam tego w swoich projektach, ale chciałbym/chciałaby), ale fajnie gdyby poprate to było jakimś uzasadnieniem.
język szablonów: Slim
Składnia bardzo “czysta” i maksymalnie podobna do składni selektorów CSS (brakuje mi tylko żeby atrybuty były jak w CSS [attribute=x] a nie (attribute=y) ). Kod jest bardzo przejrzysty.
język szablonów CSS: SCSS
Wstecznie kompatybilny z CSS więc wystarczy zmienić rozszerzenie starego szablonu na .scss i zacząć dodawać zmienne
Do tego normalna obsługa pętli (nie to co w less gdzie trzeba kombinować z rekurencją).
komponenty frontendu (responsywność, listy, iknoy, itp.): ZURB Foundation 4.0
Głownie ze względu na to że to scss, do tego fajny grid. Ostatnio niestety wypuścili nową wersję gdzie wycięli spooooro kompatybilności (IE 9 jest ledwo obsługiwane o ile pamiętam), i używają rem do czcionek co uważam za błąd osobiście, preferuję em lub px - rem to taki bastard trochę który rozwiązuje problem który nie istnieje praktycznie.
Więc ZURB 4.0 albo jak klient jest tolerancyjny to 5.0 można. Możliwe że będzie trzeba poszukać czegoś nowego
testy: minitest
Generalnie RSpec dla mnie nie jest czytelny a strasznie utrudnia debugowanie przez dodawanie własnych metod (w RSpec 2.0 to zauwazyli i stworzyli obiekty “opakowujące”, co jest dla mnie przyznaniem się do błędu I wielkim “A nie mówiłem!”)
Tak więc minitest raczej z braku alternatywy (chociaż pracuję nad zmianem tego stanu).
framework JS: ExtJS jak już trzeba widgetów, Angular/Ember/Knockout jak dla mnie to jedno wielkie G które tylko generuje błędy, komplikuje kod i utrudnia debugowanie. Zwykle korzystam z jQuery a ostatnio nawet od tego staram się odchodzić.
ORM: ActiveRecord lub Sequel (w gemach/lżejszych projektach).
To jest raczej kwestia modelu w jakim tworzy się aplikacje. Jeżeli ktoś robi widoki (szablony) w Railsach, to nie ma specjalnie sensu używanie frameworków JS. Ogólnie jednak ostatnio jest silny trend, aby tworzyć aplikacje API-Centric, gdzie backend udostępnia jedynie API. Dzięki takiemu podejściu generalnie łatwiej później forkować się w aplikacje (np. mobilne). W takiej sytuacji jak najbardziej konieczny będzie framework frontendowy.
Piszę dosyć regularnie rozwinięte i nietrywialne aplikacje w JS/Coffeescript i niestety podtrzymuję opinię.
Robiłem rozpoznanie kazdej z tych bibliotek, i większość niestety nadal cierpi na błedy młodości, ciężko (naprawdę ciężko) się je debuguje. Większość wymusza konkretne ramy, i sprawdza się dopóki robisz dokładnie to co sobie twórcy biblioteki obmyślili, jak potrzebujesz coś odrobinę nieszablonowego to nagle zaczynają się schody.
Ale nie offtopujmy może Napisałem co napisałem bo @apohllo prosił o uzasadnienie. Takie jest moje
To zdecydowanie nie jest offtopowanie Opinię o tym, że Rails dzisiaj to coraz częściej tylko backend do aplikacji JSowej/iOSowej/Androidowej słyszę już od dość dawna. W moim scenariuszu oczywiście wersja mobilna ma również zdecydowany priorytet, ale w pierwszym etapie jedynie webowa.
Angular, wczesniej troche Ember, oba z uzyciem CS zamiast czystego JS
Mam odmienna opinie od @swistak84 , mi Angular ulatwia prace zdecydowanie przy rozbudowanych interfejsach, np:
edytor do pytan w ankietach, wiele typow pytan, z roznych zachowaniem, z modalami, podzialem na strony, przenoszenie gora-dol pytan czy stron, przenoszenie miedzy stronami - przy zachowaniu zasady OCP dodawanie nowych typow pytan zajmowalo mi minuty
mini aplikacja do rozwiazywania zadan, rozne typy zadan, poziomy - tutaj bardzo pomaga ui-router, ktory pozwala zamieniac takze “podwidoki”, domyslnie Angular pozwala podmienic jedynie glowny widok
Ember uzylem w jednej z wczesniejszych wersji do w miare prostych gier, i ulatwia architekture - glownie przez stany (wiem, mozna to samemu oprogramowac)
Natomiast faktem jest, ze do zwyklych prostych dynamicznych akcji czy zwyklych komponentow nie ma sensu wykorzystywac tych frameworkow i wystarczy Javascript/jQuery.
Require.JS mówimy NIE. Za każdym razem jak korzystałem z node.js (który ma podobną filozofię) kurwica mnie brała bo wszystko było prywatne, jak chciałem zmodyfikować cokolwiek czy weksportować jakiś symbol musiałem forkować bibliotekę zmieniać klasę, obiek, funkcję na publiczną, i potem utrzymywać tego forka. Generalnie jedno wielkie G - nie mogę uwierzyć że ludzie nie wysunęli wniosków z fiaska jakim było “private” w Javie.
full text search - zależy od skali, TSearch w postgresie lub dla większych wdrożeń Sphinx. Ale tutaj sporo sporo zalezy od przypadku i pod konkretny projekt trzeba dobrać konkretne rozwiązanie.
baza - Postgfresql po wsze czasy naszym królem jest. ACID, MVVC, Rozbudowane widoki, pl/pgSQL, PostGIS, spatial indices, widnowing functions, TSearch. Mógłbym wymieniać w nieskończoność. Wersja 9.3 skoczyła lata świetlne przed MySQL, zarówno pod względem funkcjonalnosci jak i szybkości. a dodatkowo Oracle robi wszystko żeby MySQL wykończyć. PostgreSQL dla każdego nowego projektu
Replikacja bazy - tutaj zależy sporo od admina http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling Generalnie od wersji 9 jest binary WAL replikacja stała się sporo prostsza. Powiedziałbym standardowo Master->Slave i HotStandby a jak potrzeba czegoś sporo większego warto zatrudnić Depesza powie ci co robić
Caching - Varnish, Memcache, Redis, MemcacheDB zależnie od potrzeb.
Load Balancing - Varnish /Nginx / HA Proxy - w zależności od wielkości strony.
Ember miał przewagę że był pierwszy (jeszcze pod starą nazwą), potem pojawiły się lepsze alternatywy.
Glownie z powodu dyrektyw, bardziej przezroczystego “two way binding” i sposobu dzialania kontrolerow (kazdy ma wlasny scope).
Jak masz chwilke rzuc okiem na wrapper formularza w Angular (http://docs.angularjs.org/guide/forms), z wykorzystaniem dyrektyw mozna powiedziec, ze tworzysz wlasny jezyk szablonow.
Polecalbym Ci (jesli jestes zainteresowany) zakup ksiazki - przyklady czy wpisy na blogach to za malo, zeby zrozumiec jak wszystko dziala od srodka.
O bazę nie pytałem, bo odpowiedź jest dla mnie dość oczywista: postgres, ze względu na znacznie większe możliwości niż mysql oraz wydajność przy złożonych zapytaniach (choć wiedzę opieram na starszych wersjach i być może mysql nadgonił trochę w tym zakresie wydajności, dla prostych zapytani mysql jest chyba nadal znacznie szybszy).’
EDIT
Widzę, że @swistak84 już tutaj szczegółowo opisał dlaczego postgres rządzi. Faktycznie, kwestia przejęcia MySQLa przez Oracle też nie jest bez znaczenia.
Drążąc jeszcze team frameworków JSowych - w moim scenariuszu chciałbym zastosować progressive enhancement, ale w perspektywie są aplikacje mobilne.
Czyli strony HTML będą pierwotnie serwowane jako statyczne. Jak jednak pożenić to z RESTowym API, które będzie podstawą dla natywnych mobilnych wersji aplikacji? Osobna aplikacja webowa, która gada ze wspólnym API, czy może jednak jedna aplikacja, która ma API jako “feature”? Jaki język template’ów? Idealnie byłoby wykorzystać te same template’y dla serwowanego statycznie HTML, co dla renderowanych po stronie klienta widoków. Czy simple wspiera takie rozwiązanie?
Aplikacja HTML + API jako dodatek. po to jest przecież respond_to
Jako język templatów polecam ponownie slim - szczególnie że jest on bardzo podobny do http://jade-lang.com/ to znaczy większość widoków można przeportować do JS poprzez kopjuj-wklej
Dodatkowo jest dosyć obiecujący projekt https://github.com/jfirebaugh/skim pozwalający eksportować te same templaty do JS
Dodatkowo jak dla mnie to tworzenie apki na androida czy ios jest w tej chwili trochę bez sensu. Zrobiłbym responsywną stronę, a do zbudowania aplikacji na androida/ios po prostu stworzyłbym szkielet który odpala stronę w webkicie (jest zreszta kilka generatorów apek które na to pozwalają, podajesz adres strony - dostajesz APKa czy odpowiednik na ios który po prostu wyświetla responsywną stronę).
Zacznę od tego - nie wszystko da się zrobić w aplikacji webowej, ale inaczej - dużo rzeczy się da, ale pogarsza to mocno User Experience. Jako przykład weźmy przesłanie zdjęcia do apki - oczywiście użytkownik może zrobić zdjęcie i potem je załadować przez formularz, ale znacznie lepiej jeśli z poziomu apki robi zdjęcie, które jest automatycznie wysyłane na serwer. Realny przykład - SaveUp.
I to się wiąże z respond_to - faktycznie jeśli przewidujemy tylko responsywną aplikację webową, to robienie osobnych aplikacji jednej do API a drugiej do frontendu jest niepotrzebnym komplikowaniem. Natomiast jeśli ma być wiele frontendów, to imho taki zabieg (tzn. podejście strice serwisowe) ma istotne zalety. W szczególności jest dokładnie wyznaczona granica pomiędzy tym co jest backendem a frontendem.
Nie mówię że nie można robić native apki, ale zacząłbym własnie od responsywnej wersji strony i apki “wrapującej” tą stronę, po czym dodawał elementy natywne tam gdzie ma to sens.
Korzystając z twojego przykładu w Androdzie po prostu dodałbym calla do API pozwalającego na upload, po czym do aplikacji androidowej dodałbym Activity wywoływane po naciśnięciu przycisku migawki które korzysta z tego API.
PS. Nie wspominając już zupełnie o tym że ten sposób jest bardzo DRY, większość zmian wystarczy wprowadzić na stronie WWW i apki “aktualizują” się automatycznie, nie trzeba wprowadzać zmian, nie trzeba płacić deweloperom Androida/iOS
(sam pewnie przesiadłbym się na Postgresa gdyby nie naprawdę sporo lat doświadczenia z MySQL, fajne możliwości tworzenia zapytań, natomiast brakuje upserta)
W moich zastosowaniach nie widzę potrzeby przesiadania się na Postgresa, na pewno nie dla jednego zapytania. Poza tym w MySQL-u do tej pory udało mi się zrobić wszystko to, co zaplanowałem, mam z nim ponad 10 lat komercyjnego doświadczenia i znam jego wady i zalety.
Ale ponieważ to jałowy wątek tej dyskusji to EOT.
A co do wyszukiwania - elasticsearch jest potężny, ale trzeba się dobrze zastanowić czy potrzeba czegoś aż tak wielkiego. Raz się na to zdecydowałem ze względu na kilka mi potencjalnie potrzebnych ficzerów i mnie ta potencjalność ugryzła. Orientujecie się czy thinking_sphinx albo inny gem potrafi już dobrze obsłużyć real-time search w Sphinxie i wstawianie danych przez Sphinxowego SQL-a?
Opinię o tym, że Rails dzisiaj to coraz częściej tylko backend do aplikacji JSowej/iOSowej/Androidowej słyszę już od dość dawna. W moim scenariuszu oczywiście wersja mobilna ma również zdecydowany priorytet, ale w pierwszym etapie jedynie webowa.