Если вы создаете ванильное веб-приложение для запросов / ответов, основы будут такими:
Как работает http / s в целом
Пример http-сервера очень распространен в узлемир, потому что в отличие от другого веб-языка, такого как php, ваше нодовое приложение не живет «внутри» веб-сервера apache и т.п.Вы фактически создаете работающий веб-сервер, который будет возвращать ответы на основе запросов.Это совсем другой способ организации программы, чем типичный «вставь свои html / php / любые файлы в корень веба apache» и вперед.Сильной стороной узла является то, что для создания веб-сервера / tcp / udp / cli требуется тривиализация множества неприятных жестких частей, таких как пулы потоков, циклы событий, блокировки и т. Д.
Sessions / cookies / POST+ GET
Потому что вам придется иметь дело с этими вещами более ручным способом (по крайней мере, пока вы не напишете модуль или не выберете модуль для работы с ним).Многие кандидаты, с которыми я беседую по телефону, не могут определить для меня внутреннюю работу того, как типичный язык управляет их хранилищем сеансов.Они просто знают, что вставляют значение X в переменную Y и оно доступно на время сеанса.На самом деле, есть файл cookie, который устанавливается, который ссылается на файл / базу данных / что-либо еще где-то по идентификатору сеанса.В узле вы извлекаете эти значения из заголовков http самостоятельно (или модуль делает это за вас) и строят поверх более простых строительных блоков http.То же самое относится и к данным POST и GET.
При этом вы можете использовать фреймворк, такой как express - http://expressjs.com/, - с большим эффектом, и он будет обрабатывать множество вещей для вас.Тем не менее, он все еще достаточно сырой (что большинство узловодеров предпочитают imo), который вы можете получить во внутренних частях http-запросов.
Постоянство
Большинству веб-приложений потребуется какая-то база данных.Реляционные базы данных, такие как mysql, являются одним из способов решения этой проблемы - многие нодстеры предпочитают что-то вроде mongodb, потому что это дает им немного больше свободы в отношении таких вещей, как схемы + миграция, и немного больше ощущения JavaScript (потому что вещи выглядят как JSON).К счастью, вам не нужно делать сложный и быстрый выбор, потому что у сообщества есть много, много клиентских библиотек для общих баз данных.
Неблокирующая методология
Как уже упоминали некоторые другиеэто то, что может взорвать ваш разум в определенной степени.Во многих других языках, если вы не используете конкретную неблокирующую инфраструктуру, такую как twisted в python или eventmachine в ruby, вы пишете синхронный код почти во всех случаях.Это означает, что когда вы запрашиваете информацию в своей базе данных, вы делаете это следующим образом:
result = query("SELECT * FROM users");
console.log(results);
console.log("howdy");
Вместо этого в узле (или других средах, поддерживающих обратный вызов / основанный на событиях io), вы, скорее всего,напишите код, который выглядит следующим образом:
query("SELECT * FROM users", function(result){
// Do something with your users
console.log(result);
});
console.log("howdy");
В первом примере (из синхронного мира) «howdy» будет напечатан после результатов.Во втором (асинхронном) примере «howdy» печатается перед результатами.
Это может быть сложно, когда вам приходится выполнять много синхронных операций, зависящих друг от друга.Когда вы дойдете до этого момента, пришло время взглянуть на библиотеки управления потоком, такие как https://github.com/caolan/async - они предоставляют инструменты для упорядочения этих операций, чтобы ваш код не выглядел смешно.
Очевидно, что этоширокий вопрос.Лично я думаю, что вы должны просто погрузиться в это и сделать все это.Это действительно хороший способ изучить этот материал.