Zakładanie legowisk azbestowych ...
Wczoraj mój tytuł w Packt Publications, Reactive Programming with JavaScript . To tak naprawdę nie jest tytuł skoncentrowany na Node.js; wczesne rozdziały mają na celu omówienie teorii, a później obszerne rozdziały kodu obejmują praktykę. Ponieważ tak naprawdę nie uważałem za stosowne nie dać czytelnikom serwera WWW, Node.js wydawał się zdecydowanie oczywistym wyborem. Sprawa została zamknięta, zanim jeszcze została otwarta.
Mógłbym bardzo pozytywnie ocenić moje doświadczenia z Node.js. Zamiast tego byłem szczery, jeśli chodzi o dobre i złe punkty, które napotkałem.
Pozwól mi podać kilka istotnych cytatów:
Ostrzeżenie: Node.js i jego ekosystem są gorące - wystarczająco dużo, aby cię ciężko spalić!
Kiedy byłem asystentem nauczyciela w matematyce, jedną z nieoczywistych sugestii, które mi powiedziano, było nie mówienie uczniowi, że coś jest „łatwe”. Powód był nieco oczywisty z perspektywy czasu: jeśli powiesz ludziom, że coś jest łatwe, ktoś, kto nie widzi rozwiązania, może poczuć się (jeszcze bardziej) głupi, ponieważ nie tylko nie rozumie, jak rozwiązać problem, ale problem są zbyt głupie, aby zrozumieć, że jest to łatwe!
Są gotchas, które nie tylko drażnią ludzi pochodzących z Python / Django, które natychmiast przeładowują źródło, jeśli cokolwiek zmienisz. W przypadku Node.js domyślnym zachowaniem jest to, że jeśli dokonasz jednej zmiany, stara wersja będzie aktywna do końca czasu lub do momentu ręcznego zatrzymania i zrestartowania serwera. To nieodpowiednie zachowanie nie tylko drażni Pythonistów; drażni także rodzimych użytkowników Node.js, którzy udostępniają różne obejścia. Pytanie StackOverflow „Automatyczne ponowne ładowanie plików w Node.js” ma w chwili pisania tego tekstu ponad 200 głosów pozytywnych i 19 odpowiedzi; edycja kieruje użytkownika do skryptu niani, nadzorcy węzłów, ze stroną główną pod adresem adresem http://tinyurl.com/reactjs-node-supervisor. Ten problem daje nowym użytkownikom świetną okazję, aby poczuć się głupio, ponieważ myśleli, że naprawili problem, ale stare, błędne zachowanie jest całkowicie niezmienione. I łatwo zapomnieć o odbiciu serwera; Zrobiłem to wiele razy. A wiadomość, którą chciałbym przekazać, brzmi: „Nie, nie jesteś głupi, ponieważ to zachowanie Node.js ugryzło cię w plecy; po prostu projektanci Node.js nie widzieli powodu, aby zapewnić tutaj odpowiednie zachowanie. Spróbuj sobie z tym poradzić, być może korzystając z pomocy przełożonego węzła lub innego rozwiązania, ale nie odchodź, czując się głupio. Nie ty masz problem; problem tkwi w domyślnym zachowaniu Node.js. ”
Ten rozdział, po krótkiej debacie, został pozostawiony, właśnie dlatego, że nie chcę sprawiać wrażenia „to łatwe”. Wielokrotnie przecinam ręce, starając się, aby rzeczy działały, i nie chcę wygładzać trudności i sprawić, że uwierzysz, że sprawne funkcjonowanie Node.js i jego ekosystemu jest prostą sprawą, a jeśli nie jest dla ciebie proste , nie wiesz co robisz. Jeśli nie napotkasz nieprzyjemnych trudności przy użyciu Node.js, to wspaniale. Jeśli to zrobisz, mam nadzieję, że nie odejdziesz, czując: „Jestem głupia - coś musi być ze mną nie tak”. Nie jesteś głupi, jeśli doświadczysz paskudnych niespodzianek związanych z Node.js. To nie ty! To Node.js i jego ekosystem!
Dodatek, którego tak naprawdę nie chciałem po rosnącym crescendo w ostatnich rozdziałach i wnioskach, mówi o tym, co udało mi się znaleźć w ekosystemie i dostarczył obejścia dla kretyńskiego dosłowności:
Inną bazą danych, która wydawała się być idealnie dopasowana, a którą można jeszcze wymienić, jest implementacja magazynu kluczy i wartości HTML5 po stronie serwera. Takie podejście ma główną zaletę interfejsu API, który jest zrozumiały dla większości dobrych programistów front-endów. W tym przypadku jest to również interfejs API, który większość niezbyt dobrych programistów front-endów rozumie wystarczająco dobrze. Ale dzięki pakietowi węzła-localstorage, podczas gdy dostęp do słownika nie jest oferowany (chcesz użyć localStorage.setItem (klucz, wartość) lub localStorage.getItem (klucz), a nie localStorage [klucz]), pełna semantyka localStorage jest implementowana , w tym domyślny przydział 5 MB - DLACZEGO? Czy deweloperzy JavaScript po stronie serwera muszą być chronieni przed sobą?
Jeśli chodzi o możliwości baz danych po stronie klienta, przydział 5 MB na witrynę to naprawdę spora i przydatna przestrzeń do oddychania, umożliwiająca programistom pracę z nią. Możesz ustawić znacznie niższy limit, a jednocześnie zaoferować programistom niezmierną poprawę w stosunku do limpowania wraz z zarządzaniem plikami cookie. Limit 5 MB nie nadaje się bardzo szybko do przetwarzania po stronie klienta Big Data, ale istnieje naprawdę dość hojny limit, z którego zaradni programiści mogą zrobić wiele. Ale z drugiej strony 5 MB nie jest szczególnie dużą częścią większości dysków zakupionych w ostatnim czasie, co oznacza, że jeśli ty i strona internetowa nie zgadzacie się co do rozsądnego wykorzystania miejsca na dysku lub niektóre witryny są po prostu zbyt duże, naprawdę nie kosztuje dużo i nie grozi ci zalanie dysku twardego, chyba że twój dysk twardy był już zbyt pełny.
Jednak można delikatnie zauważyć, że gdy jesteś jedynym, który pisze kod dla swojego serwera, nie potrzebujesz żadnej dodatkowej ochrony przed powiększeniem bazy danych o rozmiar przekraczający 5 MB. Większość programistów nie potrzebuje ani nie chce narzędzi działających jako niania i chroniąc je przed przechowywaniem ponad 5 MB danych po stronie serwera. A limit 5 MB, który jest złotym działaniem równoważącym po stronie klienta, jest raczej głupiutki na serwerze Node.js. (A w przypadku bazy danych dla wielu użytkowników, takiej jak ta opisana w niniejszym dodatku, nieco boleśnie można zauważyć, że nie jest to 5 MB na konto użytkownika, chyba że utworzysz osobną bazę danych na dysku dla każdego konta użytkownika; to 5 MB współdzielone między wszystkie konta użytkowników razem bolesnejeśli staniesz się wirusowy!) Dokumentacja mówi, że limit można dostosować, ale tydzień temu e-mail do programisty z pytaniem, jak zmienić limit, jest bez odpowiedzi, podobnie jak pytanie StackOverflow zadające to samo. Jedyną odpowiedzią, jaką udało mi się znaleźć, jest źródło Github CoffeeScript, gdzie jest ono wymienione jako opcjonalny drugi argument liczby całkowitej dla konstruktora. To jest dość łatwe i możesz określić przydział równy rozmiarowi dysku lub partycji. Ale oprócz przeniesienia funkcji, która nie ma sensu, autorowi narzędzia nie udało się całkowicie przestrzegać bardzo standardowej konwencji interpretowania 0 jako oznaczającej „nieograniczony” dla zmiennej lub funkcji, gdzie liczba całkowita ma określać maksymalny limit dla niektórych zasobów. Najlepszą rzeczą związaną z tym błędem jest prawdopodobnie określenie, że limit to Nieskończoność:
if (typeof localStorage === 'undefined' || localStorage === null)
{
var LocalStorage = require('node-localstorage').LocalStorage;
localStorage = new LocalStorage(__dirname + '/localStorage',
Infinity);
}
Zamiana dwóch komentarzy w kolejności:
Ludzie niepotrzebnie strzelali sobie w stopę, cały czas używając JavaScript jako całości, a częścią JavaScript, który stał się szanowanym językiem, był Douglas Crockford mówiąc w istocie: „JavaScript jako język ma naprawdę dobre i złe strony. Oto dobre części. Po prostu zapomnij, że coś jeszcze tam jest ”. Być może gorący ekosystem Node.js wyhoduje własnego „Douglasa Crockforda”, który powie: „Ekosystem Node.js to kodujący Dziki Zachód, ale można znaleźć kilka prawdziwych klejnotów. Oto mapa drogowa. Oto obszary, których należy unikać za wszelką cenę. Oto obszary z jedną z najbogatszych wypłat w KAŻDYM języku lub środowisku. ”
Być może ktoś inny podejmie te słowa jako wyzwanie i podąży za przykładem Crockforda i napisze „dobre części” i / lub „lepsze części” dla Node.js i jego ekosystemu. Kupiłbym kopię!
Biorąc pod uwagę stopień entuzjazmu i czystą liczbę godzin pracy nad wszystkimi projektami, może być uzasadnione za rok, dwa lub trzy, aby ostro stłumić wszelkie uwagi na temat niedojrzałego ekosystemu poczynione w czasie pisania tego tekstu. Za pięć lat może mieć sens stwierdzenie: „Ekosystem Node.js 2015 miał kilka pól minowych. Ekosystem Node.js 2020 ma wiele rajów. ”