Mamy dużą aplikację Ruby on Rails (25 milionów użytkowników miesięcznie), nasze kierownictwo postanowiło przepisać w Node.js, czy jestem szalony?

Proszę mi powiedzieć, jeśli:

Node.js sprawi, że nasza strona będzie szybsza!
Node.js zużywa mniej zasobów serwera, możemy zaoszczędzić pieniądze!
Node.js zwiększy naszą wydajność!
Node.js oznacza, że możemy udostępniać kod JavaScript po stronie klienta i serwera.

Aby to wyjaśnić, przepisujemy serwer frontonu, który będzie rozmawiać z naszą istniejącą aplikacją Ruby on Rails jako API. W międzyczasie zmienimy naszą aplikację Ruby on Rails na usługi.

Więcej szczegółów na temat istniejącej architektury:

Zapisane w pamięci podręcznej dla buforowania częściowych HTML
Redis do sesji i niektóre strukturalne buforowanie danych
MySQL pojedynczy master, wiele slave
- Jest jeden duży stół, który akceptuje wiele zapisów (wyobraź sobie ankietę)
- W przeciwnym razie głównie czyta.
MongoDB dla niektórych metadanych
Ruby on Rails 3.0
nginx i Unicorn

— użytkownik88487
źródło

sheesh, wszystkie te hipsterowe języki. Dobrze napisana aplikacja php będzie się łatwo skalować, tradycyjne narzędzia działają, nie pozwól tym hipstersom powiedzieć inaczej.

— Darknight

Pytanie powinno być bardziej podobne do tego, czy ulepszenia pozwolą zaoszczędzić wystarczająco dużo pieniędzy dla firmy, aby była opłacalna? Może to zaoszczędzić pieniądze w ciągu 5 lat, ale przepisywanie jest kosztowne i czasochłonne - chyba że Twój kod jest okropnym, okropnym bałaganem. Myślę, że twoi menedżerowie są wściekli

— Mikey C

Jeśli rozważane są przepisania, możesz również rozważyć przeniesienie frontonu do javascript po stronie klienta, co oznacza, że nie będziesz już mieć dynamicznego serwera frontonu, tylko pliki statyczne.

— Joeri Sebrechts

@Darknight pamiętaj, że w pewnym momencie PHP było językiem hipsterów, a ludzie pokazujący, że można go wdrożyć w udanych produktach, promowali jego przyjęcie - podczas gdy programiści Perla szydzili z hipsterów PHP.

Jestem bardzo zaskoczony, że nikt nie poruszył artykułu Joela Spolsky'ego Rzeczy, których nigdy nie powinieneś robić . Nie twierdzę, że wszystkie przeróbki są złe, ale zgadzam się z @MikeyC, że należy do nich podchodzić z najwyższą ostrożnością.

— Dan Pichelman

Odpowiedzi:

Na większość zadawanych pytań nie można odpowiedzieć bez kontekstu i są one mniej więcej sporne, biorąc pod uwagę, że kierownictwo dokonało już wyboru dla ciebie ... chyba że pytasz: „czy powinienem rzucić palenie i znaleźć nową pracę w obliczu tej zmiany? ?

Jeśli zamierzasz to rozwiązać, polecam przeczytanie tego postu na ten temat: Jak przetrwać od podstaw, przepisz bez utraty zdrowia psychicznego .

Niedawno zacząłem od przepisywania trochę logiki serwera w node.js. Głównym powodem było to, że obecnie jest napisany w .NET i chcemy migrować z dala od środowisk MS.

Moje dotychczasowe doświadczenia były pozytywne, będziesz mieć wstępną krzywą uczenia się z całym jej nieblokowaniem, ale kiedy przejdziesz, w rzeczywistości jest całkiem fajnie pisać. Wiem, ZABAWA!

Ma to jednak ciemną stronę: każdy mężczyzna i jego pies, którzy dokonali pewnych prac programistycznych w JavaScript - i mam nadzieję, że byłby to każdy programista - jest trochę podekscytowany, gdy wspominasz, że node.js to javascript po stronie serwera „nie oznacza to jednak, że programiści będą mieli doświadczenie wymagane do pisania dobrych aplikacji po stronie serwera.

Z jednej strony należy wziąć pod uwagę, że błąd krytyczny obniży całą aplikację ze względu na jej nie wątkową naturę, więc stawki są nieco wyższe i musisz jawnie sprawdzić i złapać wszystko.

Dla tych, którzy zrobili zarówno front, jak i back - i cieszą się obiema - brak konieczności przełączania kontekstów mentalnych z języków front-end na back-end jest prawdziwym bonusem, który moim zdaniem ostatecznie zwiększy produktywność w naszym zespole.

— dave.zap
źródło

„Jedną z rzeczy, które należy wziąć pod uwagę, jest to, że błąd krytyczny obniży całą aplikację ze względu na jej nie wątkową naturę, więc stawki są nieco wyższe i musisz jawnie sprawdzić i złapać wszystko” - to byłoby moje zmartwienie.

— tentimes 24.04.13

Tak, moja główna uwaga w tym stwierdzeniu była taka, że tylko programiści zwykle nie są szczególnie wybredni, jeśli chodzi o obsługę wyjątków. Chodź, już prawie 2017!

— dave.zap,

Cóż, nie sądzę, że przepisywanie aplikacji było dobrym pomysłem, chyba że działało słabo. Aby odpowiedzieć na pytania:

Node.js nie jest magią. Twoja aplikacja ma ogromną liczbę użytkowników, więc nie ma pewności, że przyspieszy.
Cóż, tak, Node.js w rzeczywistości zużywa mniej zasobów serwera. Dzięki temu możesz nie tylko zaoszczędzić pieniądze na zasobach, ale możesz także zrobić więcej z istniejącymi. Wynika to głównie z jednowątkowego charakteru Node.js. Nie ma narzutu dodatkowych wątków.
Ponownie Node.js nie jest magią. Powiedziawszy to, może być w tym trochę prawdy. Node.js ma bardzo aktywną społeczność, która stworzyła setki modułów dla każdego możliwego zadania. Jest więc całkiem prawdopodobne, że większość pracy została wykonana dla Ciebie. Musisz tylko dopasować elementy do siebie.
Teoretycznie tak. Ponieważ Node.js to JavaScript, możesz współdzielić kod między klientem a serwerem. Ale nie wiem dokładnie, co zostanie udostępnione. Nie napisałem żadnego kodu, który mógłby zostać ponownie użyty na kliencie. Rzeczy, które robimy na serwerze, zwykle nie mają nic wspólnego z klientem. Ważniejszy jest dla mnie brak przełącznika kontekstu. Łatwiej jest mi napisać kod na kliencie i serwerze w jednym języku.

Ponieważ Node.js jest jednowątkowy, chyba że jest to wyraźnie skonfigurowane , nie może korzystać z wielu procesorów .

Spójrz również na komentarze. Zapewniają dobry wgląd w działanie Node.js.

— Akshat Jiwan Sharma
źródło

Mniej zasobów z powodu jednego wątku? Jak myślisz, co robią te dodatkowe wątki?

— Joe

@Joe, o ile rozumiem, sumują się. W węźle js najlepszą praktyką jest usunięcie żądania tak szybko, jak to możliwe, albo przez wykonanie go za jednym razem, albo przez wznowienie go następnym razem. jest jedyną technologią, dla której stworzyłem aplikacje produkcyjne, więc mogę nie być najlepszą osobą, aby porównać ją z innymi technologiami po stronie serwera. Dlatego powstrzymałem się od dokonywania porównań i po prostu włożyłem to, co wiem o węzłach js w moja odpowiedź.

— Akshat Jiwan Sharma

Tak, pojedynczy wątek z pewnością ogranicza wykorzystanie zasobów, ponieważ serwer może wykonać tylko jedną czynność w pętli zdarzeń. Ogranicza również użycie serwera, ponieważ może zrobić tylko jedną rzecz naraz. Bardzo ważne jest, aby cytować funkcje (jednowątkowe) oraz zalety i wady, a nie tylko zalety. Node.js nadaje się do niektórych zastosowań, ale dla innych jest złym pomysłem. Gdy na serwerze jednowątkowego węzła występują problemy z pojemnością, może być konieczne dodanie innej instancji węzła. Teraz masz serwer wieloprocesowy.

— Joe

Rozumiem, co masz na myśli. Niedługo zaktualizuję odpowiedź (przeczytane po niektórych badaniach)

— Akshat Jiwan Sharma

Nie chodzi tylko o procesory. Powodem, dla którego ważne jest, aby obsłużyć każde żądanie tak szybko, jak to możliwe (w systemie jednowątkowym bez innej współbieżności), jest to, że serwer nie może obsłużyć wielu żądań jednocześnie, więc każde żądanie musi czekać, aż zakończysz obsługę wszystkich wnioski przed nim. Właściwa współbieżność oznacza mniej czekania. Korzystanie z wątków nie jest z natury obciążeniem wydajnościowym, a jednowątkowość (domyślnie lub w inny sposób) nie stanowi przewagi wydajnościowej.

— Peter Hosey