Strona serwera JavaScript: Dlaczego?

Question

Czy używane jest po stronie serwera javascript? Dlaczego ktoś miałby go używać w przeciwieństwie do innych skryptów po stronie serwera? Czy istnieje konkretny przypadek użycia, który sprawia, że ​​jest lepszy niż inne języki po stronie serwera?

Co więcej, pomylone, jak zacząć eksperymentować z tym, jestem na freeBSD, co musiałbym zainstalować, aby uruchomić javascript po stronie serwera?

Answer 1

To idzie tak:

serwery są drogie, ale użytkownicy będą ci dać czas przetwarzania w swoich przeglądarkach za darmo. Dlatego kod po stronie serwera jest relatywnie drogi w porównaniu do kodu po stronie klienta w dowolnej witrynie wystarczająco dużej, aby mógł działać więcej niż jeden serwer. Istnieje jednak kilka rzeczy, których nie można pozostawić klientowi, takich jak sprawdzanie i pobieranie danych. Chciałbyś zrobić to na kliencie, ponieważ oznacza to szybsze czasy reakcji dla użytkowników i mniej infrastruktury serwerowej dla ciebie, ale obawy dotyczące bezpieczeństwa i dostępności oznaczają, że wymagany jest kod po stronie serwera.

Zwykle robisz jedno i drugie. Piszesz logikę po stronie serwera, ponieważ musisz, ale ty też piszesz tę samą logikę w javascriptu w nadziei, że dostarczysz szybsze odpowiedzi do użytkownika i zaoszczędzisz swoim serwerom trochę dodatkowej pracy w niektórych sytuacjach. Jest to szczególnie skuteczne w przypadku kodu walidacyjnego.

Ponieważ wszyscy jesteśmy tutaj (głównie) programistami, powinniśmy natychmiast dostrzec nowy problem. Nie tylko dodatkowa praca polega na opracowaniu dwóch zestawów tej samej logiki, ale także na pracy związanej z jej utrzymaniem, nieuchronne błędy wynikające z platform nie pasują do siebie, a błędy wprowadzone jako implementacje zanikają w miarę upływu czasu.

Wprowadź javascript po stronie serwera. Pomysł polega na tym, że możesz napisać kod jeden raz, więc ten sam kod działa zarówno na serwerze, jak i na kliencie. Wydaje się, że rozwiązuje to większość problemu: natychmiast otrzymuje się pełny zestaw logiki serwera i klienta, nie ma dryfowania ani podwójnej konserwacji. Dobrze, gdy programiści muszą znać tylko jeden język zarówno dla pracy serwera, jak i klienta.

Niestety, w prawdziwym świecie nie działa tak dobrze. Problem jest czterokrotny:

1. Widok strony serwera wciąż różni się od widoku strony. Serwer musi być w stanie wykonywać takie czynności, jak bezpośrednia rozmowa z bazą danych, której nie powinno się robić w przeglądarce. Przeglądarka musi robić takie rzeczy, jak manipulowanie DOM, który nie pasuje do serwera.
2. Nie kontrolujesz silnika javascript klienta, co oznacza, że ​​nadal będą występować istotne różnice językowe między kodem serwera a kodem klienta.
3. Baza danych jest zwykle większym wąskim gardłem niż serwer WWW, więc oszczędności są minimalne.
4. Podczas gdy prawie wszyscy znają trochę javascript, niewielu programistów naprawdę zna i rozumie javascript oraz.

To nie są całkowicie niemożliwe do opanowania problemy techniczne: ograniczasz język obsługiwany przez serwer do podzestawu javascript, który jest dobrze obsługiwany w większości przeglądarek, udostępnia IDE, który zna ten podzbiór i rozszerzenia po stronie serwera, wprowadzić pewne zasady dotyczące struktury strony, aby zminimalizować problemy z DOM i dostarczyć trochę skryptu java do obsługi klienta, aby platforma była nieco przyjemniejsza w użyciu. Rezultatem jest coś takiego jak Aptana Studio/Jaxer lub ostatnio Node.js, co może być całkiem miłe.

Ale nie doskonały. Moim zdaniem jest po prostu zbyt wiele pułapek i niewielkich problemów ze zgodnością, aby to naprawdę zabłysnąć. Ostatecznie, dodatkowe serwery są nadal tanie w porównaniu do czasu deweloperów, a większość programistów może być znacznie bardziej wydajna za pomocą czegoś innego niż javascript.

Co naprawdę chciałbym zobaczyć, to częściowy javascript po stronie serwera. Gdy strona jest żądana lub przesłany formularz, platforma serwerowa wymaga potwierdzenia w javascript, prawdopodobnie jako wtyczka do serwera, który jest całkowicie niezależny od reszty, ale odpowiedź została zbudowana przy użyciu wybranej platformy .

Answer 2

Wydaje mi się, że naprawdę fajne użycie Javascriptu po stronie serwera, który nie jest używany prawie na tyle często, to sprawdzanie poprawności danych. Za jego pomocą można napisać jeden plik javascript, aby sprawdzić poprawność formularza, sprawdzić go po stronie klienta, a następnie ponownie go sprawdzić po stronie serwera, ponieważ nie powinniśmy ufać cokolwiek po stronie klienta. Pozwala zachować zasady weryfikacji DRY. Dość przydatny.

zobacz także:

• Will server-side Javascript take off? Which implementation is most stable?
• When and how do you use server side JavaScript?

Answer 3

Javascript to tylko język. Ponieważ jest to tylko język, możesz go używać w dowolnym miejscu ... w przeglądarce, na serwerze, osadzony w innych aplikacjach, autonomicznych aplikacjach itp.

Z tego powodu nie wiem Jest wiele nowych zmian, które powstają dzięki "JavaScriptowi po stronie serwera".

Answer 4

Javascript to doskonale dobry język z podstawą stylu opartego na prototypie i stylem C oraz składnią stylu C. Występują pewne problemy, zobacz JavaScript Dobre części, ale ogólnie jest to język pierwszej stawki. Problem polega na tym, że większość programistów javascript to okropni programiści, ponieważ jest to bardzo łatwo dostępne.

Jeden zespół z Google zbudował Rhino na Railsach, który jest frameworkiem MVC, jak Ruby on Rails, który jest napisany w javascript i działa na Rhino, tłumaczu javascript dla VM Java. W tym przypadku musieli używać maszyny wirtualnej Java, ale chcieli, aby język był szybki (javascript jest szybki), obsługiwany przez pisanie kaczkami i był elastyczny.

Innym przykładem jest coś takiego jak CouchDB, baza danych zorientowana na dokumenty, która wykorzystuje json, ponieważ jest to format transportu i javascript, ponieważ jest to język indeksowy zapytania: &. Chcieli, aby baza danych była tak oryginalna, jak to tylko możliwe.

Javascript jest dobry w manipulacji ciągami i domami (xml), jest piaskownicą, obsługą sieci, rozszerzaniem się itp. Tego typu funkcje są często wykonywane podczas tworzenia aplikacji internetowych.

Wszystko to powiedziawszy, ja faktycznie nie rozwijam javascript po stronie serwera. To nie jest zły pomysł, ale zdecydowanie mniej powszechny.

Answer 5

Używamy javascript na kliencie, ponieważ istnieje, nie dlatego, że z listy języków był naszym wyborem. Nie wybrałbym go do żadnych obowiązków na serwerze.

Możesz uruchomić dowolny język na serwerze, tak naprawdę, jak tylko chcesz.

javascript jest niezawodny i łatwy w użyciu, ale jest zbyt pracochłonny do wykonywania typowych zadań na serwerze.