Подтвердить что ты не робот

Raw Node.js без каких-либо веб-фреймворков

Я пытаюсь изучить узел, я видел много материала (как было предложено в этом знаменитом вопросе SO), проблема в том, что все книги, которые я видел, или учебные пособия либо используют веб-фреймворк, такие как экспресс, либо просто ограничивают себя тем, что узел и не идет глубже, чем объяснение того, как создать очень простой HTTP-сервер, который слушает запросы на каком-то порту.
Так что мне действительно интересно, есть ли кто-нибудь, кто использует узел w/oa web framework? Если это так, они, должно быть, узнали это где-то, так что не могли бы вы предложить, где я могу это узнать?
Я знаю, что это очень низкий уровень, но я не против, я уже знаком с тем, как создавать серверы на C.
Мне бы очень хотелось понять, как мы действительно обслуживаем статический контент с узлом (специально организованный в папках) и как мы фактически вводим логику в наш html (я все это посмотрел, но нашел только результаты о том, как это сделать с помощью Express, где логика вводится чем-то вроде <%//code%>, но может ли это быть сделано в чистом узле?).

Вопрос, подобный моему, который уже был задан здесь, на самом деле не имеет ответа. Лучший ответ просто предлагает прочитать официальную документацию nodejs, которая похожа на высказывание:
там у вас есть словарь с миллионами слов на латыни, удачи в его изучении.

Итак, можете ли вы предложить какую-то хорошо документированную, надежную книгу/учебник, где показано, как создать сайт реального мира с использованием исходного узла?
Если нет, я думаю, мне придется придерживаться php + Apache и пытаться оптимизировать их для масштабирования.

4b9b3361

Ответ 1

Node.js сам по себе является механизмом выполнения Javascript (на основе V8), который работает на разных платформах и поставляется со стандартной библиотекой. Он несколько аналогичен любому другому интерпретируемому языку с его стандартной библиотекой (например, Python или PHP). Неверно было бы описать простой node.js как "веб-платформу" самостоятельно. В нем есть основные инструменты, из которых можно сделать веб-платформу, но она также может использоваться для всех видов других видов использования, которые не имеют ничего общего с веб-платформой. Например, я создал из него некоторые средства построения командной строки для выполнения различных форм обработки текста (использование, которое не создает каких-либо сетей).

Поэтому я предполагаю, что "сырой" узел просто означает решение любой проблемы, которую вы хотите решить, не создавая поверх сторонних библиотек (помимо стандартной библиотеки, с которой связан node.js). Лично я не уверен, почему вы действительно этого хотите. Одно огромное преимущество развития node.js - это вся экосистема NPM, в которой есть тысячи предварительно построенных, свободных и открытых исходных модулей, которые решают тысячи проблем. Некоторые из них - несколько функций, но все же полезны, а другие - это все API-интерфейсы, которые разрешают множество проблем. Красота NPM и этой экосистемы заключается в том, что с помощью одной простой команды вы можете добавить любой из этих модулей в свой проект и с помощью нескольких строк кода, вы можете использовать его в своем проекте. Я бы счел глупым избежать этого преимущества.

Таким образом, изучение raw node.js означает изучение Javascript, изучение инструментов, часто используемых для разработки node.js (отладчик, NPM, консоль и т.д.) И изучение стандартной библиотеки, которая поставляется с node.js. Мало кто когда-либо хочет сесть и научиться каждой функции в стандартной библиотеке. Обычно люди делают хороший просмотр всех модулей, доступных в стандартной библиотеке, через каждую страницу, чтобы понять, какие вещи у них есть, а затем найти то, что вы хотите построить, и начать строить его, Поскольку вы вынуждены находить вещи и выяснять, как они работают из документации или поиска Google, или от изучения другого кода node.js, который вы найдете, вы узнаете, как работают части стандартной библиотеки и что она делает. Если вы выполняете операции ввода-вывода (файл, сеть и т.д.), Вы быстро столкнетесь с множеством асинхронных API-интерфейсов в стандартной библиотеке, и вам, как правило, захочется или нужно освоить обработку асинхронных операций (это действительно просто обучение async Javascript), но, вероятно, будет иметь важное значение в проекте node.js.

Если вы действительно хотите "изучить" стандартную библиотеку самостоятельно, то у Amazon и Google есть длинные списки ресурсов, которые вы можете просмотреть, чтобы увидеть, какие из них, похоже, подходят к вещам так, как вы хотите. Просить нас найти такой ресурс для вас считается "вне темы" здесь, в StackOverflow, поэтому я оставлю вас пойти на эти списки и решить, что выглядит интересным. Я сам знал клиентский Javascript и взял node.js, просто прочитав некоторые веб-ресурсы, а затем работал над своими собственными проектами. В конце концов, я построил систему node.js, которая работает на малине Pi, и сидит в моем датчике температуры на чердаке, переключая вентиляторы чердака на основе температурных различий и предлагая веб-интерфейс для управления, настройки и отчетности по всему, что происходит. Это половина веб-приложения и половина автономного контроллера температуры.

К сожалению, документация для стандартной библиотеки node.js не является богатой описательной (я там добрался). Он технически точен, но часто не отвечает на многие распространенные вопросы, которые могут получить у любого, кто хочет использовать API. Предполагается, что вы уже знаете много стандартной библиотеки Unix C, поскольку у нее много подобных функций (особенно для доступа к файлам). Кроме того, один из недостатков документации иерархии объектов (где вещи наследуются от других вещей) заключается в том, что может быть сложно собрать в одном месте все, что делает данный объект. Вместо этого вы должны мысленно собирать и понимать, что делают базовые объекты, а затем попытаться выяснить, как это вписывается в то, что делает объект root. Это не проблема, с которой сталкивается только node.js, у многих объектно-ориентированных систем есть эта проблема с документацией (она использовала для меня орехи с YUI).

Я быстро нашел, что мне действительно нужно было найти соответствующий исходный код библиотеки для любой стандартной библиотечной функции, чтобы я мог посмотреть, как функция была фактически написана, чтобы отвечать на мои вопросы. Это огромное преимущество как с открытым исходным кодом, так и с возможностью поиска GitHub (весь стандартный источник библиотеки находится на GitHub).

Итак, просмотрите все модули в стандартной библиотеке node.js, чтобы ознакомиться с тем, что там и где вы его найдете. Затем найдите приложение, которое вы хотите построить и построить. Если вы создаете веб-приложение, я не могу придумать никаких причин, почему вы когда-либо захотите это сделать, не используя инфраструктуру, которую кто-то уже создал для вас (я использую Express). Там просто нет причин изобретать все сами. Если вы хотите убедиться, что вы понимаете HTTP-модуль перед использованием Express, тогда создайте себе простой веб-сервер, используя только HTTP-модуль, который обслуживает два статических файла и использует HTTP-модуль, идя другим путем, чтобы запросить пару веб-страниц с других серверов, Затем начните использовать Express для создания собственного веб-приложения.

Что касается некоторых из ваших более конкретных вопросов:

Мне бы очень хотелось понять, как мы действительно обслуживаем статический контент с помощью узла (специально организованного в папках)

Некоторые ответы на этот вопрос показывают вам базовый веб-сервер только для узлов, который обслуживает статический контент из файловой системы. Больше примеров и объяснений здесь.

как мы на самом деле вводим логику в наш html (я просмотрел все это, но нашел только результаты о том, как это сделать с помощью Express, где логика вводится чем-то вроде <%//code%>, но может ли это быть сделано в чистом узле?).

Введение "логики" в ваш HTML с нуля означает, что вы сначала создаете систему для обслуживания статических веб-страниц, а затем добавляете к ней систему для разбора через веб-страницы (на сервере), чтобы найти в них директивы, которые означают, что ваш сервер должен сделайте что-нибудь, чтобы изменить или добавить в HTML, прежде чем отправлять его клиенту. Существует много разных способов сделать это, поэтому для этого существует, вероятно, 50 различных систем. Поиск систем шаблонов node.js найдет вам список. Опять же, я понятия не имею, почему вы хотели бы построить один из них с нуля. Это немного исследовательский проект, чтобы выяснить, какая из зиллионов соответствует вашим желаниям наилучшим образом (я использую Handlebars, производную от Mustache), но это должно быть как способ, а не меньше, чем создание собственной системы с нуля. И даже если вам нужны некоторые грандиозные возможности, которые нелегко выполнить с помощью системы запаса, вы также можете начать с системы запаса и расширить ее.

Ответ 2

То, о чем вы просите, кажется, есть две разные вещи, вы хотите сделать необработанный узел, но в то же время знаете, как люди используют его в реальном мире. Практически все используют, по крайней мере, Экспресс (или Коа, если вы на краю кровотечения), как их веб-рамки. Они обеспечивают голые кости для создания надежного веб-сервера. Затем, для вашего фактического интерфейса, вы должны использовать либо AngularJS, либо ReactJS, вы не будете делать рендеринг шаблонов на стороне сервера рендеринга (например, без <%%> кодовых блоков). Если вы решите пойти по маршруту React, вам понадобятся дополнительные библиотеки, такие как BaconJS, чтобы помочь с клеем, так как React - это только уровень представления, тогда как Angular - это всеохватывающая структура MVC.

Один из лучших способов узнать, это посмотреть на генератор MEAN стек yeoman https://github.com/DaftMonk/generator-angular-fullstack. Используйте генератор, чтобы сделать приложение, и прочитайте его источник, чтобы посмотреть, как он структурирован, и просто начните взламывать его, чтобы сделать то, что вы хотите.