JS do backendu - ścieżka warta uwagi ?

0

Cześć, znam js dosc dobrze, a przynajmniej na tyle żeby móc w nim pisać backend, tylko zastanawiam się czy warto.
Wiem że giganty wybierają te drogę dlatego u nas staje się to coraz bardziej popularne, ale nie chciałbym się obudzić z ręką w nocniku przy spędzonych latach w tej technologii.

Tak na zdrowy rozum, warto iść w ta stronę ? Zrobiłem sobie taką selekecje i wyszło mi coś takiego;

C# naprawdę super język ale zbyt dużo integracji z windowsem
Ruby ponoc w Polsce ciezko
Python osobiście mi sie nie podoba
PHP to już wole jsa na backend
Java nad tym się zastanawiam rowniez

Może jest tutaj jakis js dev na backendzie i sie wypowie.

Pozdrawiam

0

"ale nie chciałbym się obudzić z ręką w nocniku przy spędzonych latach w tej technologii." - daj spokoj. Co będzie po latach to nikt nie wie. JS ma się dobrze.

2

title :P

0

Tak, widziałem to juz, w pracy pokazywali, zeby dogryzac js devom ;)

4

W sumie możnaby zakończyć na tym co napisał @członek zarządu, no ale bardziej się rozpisując:

  • jak umiesz i lubisz JSa to ja bym się nie zastanawiał - obecnie trend jest rosnący, mnóstwo nowych rzeczy powstaje w Node.js i raczej szybko to się nie skończy,
  • sam koncept programowania asynchronicznego jest coraz popularniejszy, nie tylko w światku JS - umiejętności te przydadzą sie także jeśli kiedyś będziesz chciał / musiał przjeść na inny język,
  • poza językiem backend to też wszelkiego rodzaju bazy danych, zewnętrzne narzędzia typu message brokery, CI, kontenery, maszyny wirtulalne, itp - wszystko to bardzo cenna wiedza, niezależna od języka, sam język przy tym wszystkim nie jest już tak istotny,
  • nawet jak pomysł pisania backendu w Node.js upadnie, to nadal zostajesz z zaawansowaną wiedzą na temat samego JSa, który jest stosowany na wielu innych polach,
  • z technologią nie żenisz się na całe życie, jak umiesz programować to zmiana języka nie jest taka trudna,
  • nawet jakbyś mógł cofnąć się w czasie o 20 lat i zacząć uczyć np Javy by pisać w niej przez całą karierę to i tak zmian technologii Cię nie ominie - taka Java1 vs Java8 to zupełnie inne światy.

Ja tam nie boję się o swoją przyszłość, teraz w Node.js są dobre pieniądze, ciekawe projekty (zwykle startupy), zainteresowanie rynku rośnie a platforma jest stabilna. Jak będzie trzeba zmienić to zmienię, doświadczenie nie przepadnie. Jak boisz się zmian i martwisz się, że ciągle będzie się trzeba czegoś uczyć to zastanów się nad zmianą branży w ogóle ;)

0

Dziekuje Ci @Maciej Cąderek, ze odpisales. Nie boje sie nauki, zmian, tylko chcialbym (jak na razie) poddac sie jednego jezyka / technologii, zeby nie grzebac w node, java i c# rownoczesnie. Pozniej, jezeli umiejetnosci danej technologii pozwola, to moge sobie wskoczyc gdzie indziej.

Tak jak pisalem, znam js-a dosc dobrze, znam sqla i drazni mnie front (html,css i js dla skryptow ala jquery) wiec gdzie sie przerzucic na backend i wiem ze wskoczenie na node'a bedzie latwiejsze niz na jave w moim przypadku.

@Maciej Cąderek jestes w stanie mi dac jakies wskazowki, co powinienem znac / ogarnac / przeczytac, w edukacji node'a ? Dla osoby, ktora juz cos tam liznela i zna js. (napisalem prosty chat na socketach, apke crud). Jakies best guides, nie wiem, cokolwiek, co uwzasz ze to Ci sie mega przydalo.

Pozdr.

0

Ostatnio został zaktualizowany znany post Tomislava Capana

0

https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e52b#.m91byhluv
autor Express.js porzucił Node

0

sam koncept programowania asynchronicznego jest coraz popularniejszy, nie tylko w światku JS - umiejętności te przydadzą sie także jeśli kiedyś będziesz chciał / musiał przjeść na inny język,

Asynchroniczność w JS jest kulawa, bo mamy jeden wątek. Callbacki to wymóg spowodowany ograniczeniem do jednego wątku. Dość podobnie jest w przypadku programowania GUI np w Javie - jest tam pojedynczy EDT (event dispatch thread), w którym odpalane są wszystkie callbacki zapięte na GUI jak i wszelkie operacje zmieniające postać GUI (np dodawanie przycisków, zmienianie rozmiarów, etc).

Przez to, że jest jeden wątek w JSie to nie trzeba nic synchronizować i się tego oczywiście nie robi (nie ma nawet jak, bo przez to że synchronizacja jest niepotrzebna to nie ma dla niej wsparcia). Próba przenoszenia takiego sposobu myślenia w inne języki skończyłaby się raczej tragicznie, bo w takiej Javie wątków jest zwykle od groma.

Z drugiej strony asynchroniczność działa tak samo w Node.js jak w przeglądarkowym JS, więc umiejętność żonglowania callbackami przyda się w programowaniu frontu w JSie.

1

Node.js jest osom do mniejszych backendów. Jak potrzebujesz serwera do swojej apki na telefonie, albo ogólnie jak potrzebujesz backendu, który pełni rolę takiego bardziej proxy na bazę dancyh, to node.js jest mocnym kandydatem. Jednak gdy ilość kodu produkcyjnego zaczyna się zbliżać albo przekraczać 15k wierszy to zaczynają się problemy. Jeśli zespół nie jest wystarczająco zdyscyplinowany w pisaniu testów automacznych to ryzyko fakapu, który nie miałby prawa się zdażyć w języku projektowanym dłużej niż dwa tygodnie, jest bardzo wysokie.

Asynchroniczność w node.js jest dana "za darmo", nie trzeba się specjalnie nad nią zastanawiać, tyle, że pewnie ugryzie Cię w najmniej spodziewanym momencie, pewnie gdy będziesz chciał przesłać dane z jednej zdalnej lokacji do drugiej i odbiór danych będzie dużo szybszy niż wysyłka - wtedy będziesz musiał się trochę nagimnastykować ;) A jak chcesz łatwo sprawdzić o czym piszę, oskryptuj sobie asynchronicznie w node.js kopiowanie sporej ilości dużych plików z dysku SSD na dysk HDD albo jakiś dysk sieciowy.

Wibowit napisał(a):

Asynchroniczność w JS jest kulawa, bo mamy jeden wątek.

No, nie do końca. Z punktu widzenia JS jest tak jak piszesz, ale pod spodem leży libuv które na potrzeby swojego przetwarzania tworzy sobie cztery wątki.

0

No, nie do końca. Z punktu widzenia JS jest tak jak piszesz, ale pod spodem leży libuv które na potrzeby swojego przetwarzania tworzy sobie cztery wątki.

Spodziewałbym się, że przeglądarka też odpala wiele wątków oprócz wątku, w którym wykonywany jest JS. W końcu ściąganie czy wysyłanie danych nie blokuje pętli zdarzeń. W pętli zdarzeń jest tylko wykonywany callback w momencie gdy wszystkie dane są już dostępne.

0
Wibowit napisał(a):

Asynchroniczność w JS jest kulawa, bo mamy jeden wątek. Callbacki to wymóg spowodowany ograniczeniem do jednego wątku.

Jeden wątek i callbacki (a raczej promisy i async-await, bo we współczesnym Node nikt raczej gołych callbacków nie używa) to cecha reactor pattern - po prostu więcej nie jest potrzebne. Model jak model - każdy ma zalety i wady. Chodzi Ci o to, że w Node.js nie wykorzystasz mocy wielordzeniowego procesora? Wykorzystasz - to, że event loop działa w jednym wątku nie znaczy, że nie możesz mieć kilku event loopów - vide node cluster. Możesz nawet ręcznie utworzyć dodatkowe wątki robocze dla czasochłonnych operacji za pomocą https://github.com/audreyt/node-webworker-threads (też działające asynchronicznie).

Przez to, że jest jeden wątek w JSie to nie trzeba nic synchronizować i się tego oczywiście nie robi (nie ma nawet jak, bo przez to że synchronizacja jest niepotrzebna to nie ma dla niej wsparcia). Próba przenoszenia takiego sposobu myślenia w inne języki skończyłaby się raczej tragicznie, bo w takiej Javie wątków jest zwykle od groma.

No ale ja przecież nie mówię o jakimś Springu gdzie jest thread per request, mówię o takich rozwiązaniach jak Vert.x / Ratpack / Netty (JVM), Tornado / Twisted (python) czy EventMachine (Ruby). Tam nie ma od groma wątków, jest max jeden wątek per fizyczny rdzeń procesora - zupełnie jak w Node.js.

several napisał(a):

No, nie do końca. Z punktu widzenia JS jest tak jak piszesz, ale pod spodem leży libuv które na potrzeby swojego przetwarzania tworzy sobie cztery wątki.

Racja, ale wynika to z tego, że nie wszystkie API systemowe są asynchroniczne, inaczej wewnętrzny thread pool nie byłby potrzebny.

0

Chodzi Ci o to, że w Node.js nie wykorzystasz mocy wielordzeniowego procesora? Wykorzystasz - to, że event loop działa w jednym wątku nie znaczy, że nie możesz mieć kilku event loopów - vide node cluster.

Klaster to można stworzyć w praktycznie każdym języku, który obsługuje chociażby system plików czy inny sposób na IPC (inter process communication). W Javce, C++, C#, itp itd zwykle nie używa się jednak IPC tylko wielowątkowość. Wielowątkowość ma mniejszy narzut niż wieloprocesowość.

Możesz nawet ręcznie utworzyć dodatkowe wątki robocze dla czasochłonnych operacji za pomocą https://github.com/audreyt/node-webworker-threads (też działające asynchronicznie).

No są osobne wątki, ale dalej nie ma współdzielenia stanu tylko komunikacja a'la IPC (jak przy osobnych procesach).

Nie twierdzę, że współdzielenie mutowalnego stanu z poziomu wielu wątków to rozwiązanie po które typowy programista powinien sięgać najpierw. Jednak poza JSem jest to w większości przypadków standard i stąd mój sceptycyzm co do transferu wiedzy z JSa do innych języków.

W Scali Future i Aktory są namiętnie używane, ale dalej nie ma ograniczenia do jednego wątku i nie trzeba przejmować się jakąś pętlą zdarzeń. Stąd kod wygląda i tak znacznie inaczej niż w JSie, gdzie trzeba dzielnie walczyć z problemami nieznanymi w żadnym innym języku :)

0

Klaster to można stworzyć w praktycznie każdym języku, który obsługuje chociażby system plików czy inny sposób na IPC (inter process communication). W Javce, C++, C#, itp itd zwykle nie używa się jednak IPC tylko wielowątkowość. Wielowątkowość ma mniejszy narzut niż wieloprocesowość.

Jasne, że można - nie opisuję tego jako unikalnej cechy Noda, próbowałem zgadnąć co uważasz za tak szczególnie kulawe w tej architekturze.

Nie twierdzę, że współdzielenie mutowalnego stanu z poziomu wielu wątków to rozwiązanie po które typowy programista powinien sięgać najpierw. Jednak poza JSem jest to w większości przypadków standard i stąd mój sceptycyzm co do transferu wiedzy z JSa do innych języków.

Transfer wiedzy to nie przełożenie przyzwyczajeń z innego języka 1:1 - myśleć nadal trzeba.

W Scali Future i Aktory są namiętnie używane, ale dalej nie ma ograniczenia do jednego wątku i nie trzeba przejmować się jakąś pętlą zdarzeń. Stąd kod wygląda i tak znacznie inaczej niż w JSie, gdzie trzeba dzielnie walczyć z problemami nieznanymi w żadnym innym języku :)

No ale znowu porównujesz dwie różne rzeczy - aktory i reactor, to dwa różne podejścia do asynchroniczności - nie wiem jak tam chcesz wykorzystać wiedzę z Node'a. Przykładowe odpowiedniki Node'a wypisałem w poprzednim poście.

3
Złoty Ogrodnik napisał(a):

@Maciej Cąderek jestes w stanie mi dac jakies wskazowki, co powinienem znac / ogarnac / przeczytac, w edukacji node'a ? Dla osoby, ktora juz cos tam liznela i zna js. (napisalem prosty chat na socketach, apke crud). Jakies best guides, nie wiem, cokolwiek, co uwzasz ze to Ci sie mega przydalo.

Nie wiem na jakim poziomie jesteś z samym JSem i narzędziami do niego, ogólnie to korzystam głównie z dokumentacji danego narzędzia, jakbym miał coś polecić poza tym to:

Chyba tyle mi przychodzi teraz do głowy, pisane na szybko, może być trochę chaotyczne ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1