Одно большое преимущество, которое я всегда ощущал при использовании NodeJS на сервере, — это возможность совместного использования фрагментов кода между сервером и клиентом (например, проверка ввода). Теперь, когда я на самом деле разрабатываю с использованием NodeJS, я обнаружил, что одна трудность заключается в определении ответственности и контекста, в котором выполняется каждое тело кода. Ниже я перечислю некоторые из трудностей, с которыми я столкнулся, в надежде получить некоторое представление о соглашениях или рекомендациях, которые я мог упустить из виду, которые могли бы помочь поднять эти проблемы.
Код времени сборки
Временной код сборки для проектов, использующих Gulp, Grunt или vanilla NPM, в соответствии с базовой документацией, как правило, довольно прост. Большинство небольших проектов, как правило, хранят весь код в одном файле, и этот файл, как правило, называется обычным именем, например, gulpfile.js, однако в более крупных проектах я видел, как эти сценарии начинают разделяться. Я видел несколько случаев, когда файл gulp разбивается на несколько файлов и помещается в отдельный каталог. Хуже того, я обнаружил случаи, когда файл gulpfile.js даже не назывался как таковой, что заставляло новых разработчиков искать, где находится файл gulpfile, и как только он был обнаружен, команду gulp всегда нужно запускать с определенным < em> --gulpfile.
Выполняемый серверный код
Точка входа для основных приложений узла, по-видимому, просто требует указания определенного файла JavaScript при запуске команды узла (например, node script.js). Для приложений веб-сервера, таких как те, которые используют Express, я заметил, что по соглашению файл точки входа часто называется server.js и обычно находится в корневом каталоге приложения. Однако в некоторых других случаях, например при запуске веб-сервера в среде разработки, я видел, как задачи gulp берут на себя ответственность за запуск Node. В этих случаях кажется, что есть несколько способов включить точку входа, но один пример, который я нашел, — это просто запуск компилятора веб-пакета, за которым следует оператор require для сценария точки входа. Выяснение того, как включить обычное руководство по выполнению типичной команды отладки узла, нетривиально. в этом типе установки. Помимо точки входа в приложение, похоже, не существует каких-либо общих рекомендаций по структуре каталогов для приложений NodeJS/Express, которые хранили бы специфичный для сервера код на своем месте, чтобы помочь найти его и отделить от времени сборки и клиентский код.
История на стороне сервера становится еще более сложной в тех случаях, когда код на стороне сервера используется как для обслуживания статического контента, сгенерированных на стороне сервера представлений (например, с MVC), так и для предоставления API клиенту. боковая сторона. Я предпочитаю отделять API от проекта приложения, но другие считают, что при этом возникает ощущение чрезмерной сложности, когда я вижу в этом разумное разделение задач.
Выполняемый клиентский код
Поскольку код на стороне клиента часто может иметь различные точки входа в зависимости от первой запрошенной страницы, это может быть непросто. Однако из-за общей прозрачности URL-адресов в отношении того, как они сопоставляются с ресурсами в типичных случаях, а также из-за того, насколько мощными стали инструменты отладки в современных браузерах, следовать сценариям не составляет особых проблем. Вместо этого трудность для кода на стороне клиента возникает больше для типичных процессов сборки, которые обычно заканчиваются копированием файлов и помещением их в производственную структуру под другим именем. Примером может служить проект, в котором есть папка с именем src или js, содержащая перемешанный клиентский и серверный код, за исключением того, что только часть файлов быть включенным в задачу сборки, которая преобразует и часто объединяет файлы и помещает их в папку распространения. Известные мне распространенные имена этих папок распространения: dist, public, www и wwwroot. Часто, если не всегда, эти каталоги находятся в корне проекта, что, по крайней мере, упрощает их поиск без необходимости опрашивать сценарии сборки.
Я надеюсь, что есть какое-то общее руководство о том, как разумно собрать все это воедино, возможно, от авторитетного источника, главным образом, чтобы дать руководство тем, кто, как я, хочет начать с правильной ноги. В качестве побочного эффекта, возможно, возможность ссылаться на какой-то стандарт, даже если он нечеткий, также может уменьшить количество шаблонов, которые команда должна изобретать и обсуждать в начале работы. В каждом из перечисленных выше контекстов, очевидно, будут некоторые технологические соглашения, такие как те, которые применяются для AngularJS, Meteor или ReactJS на стороне клиента. Соглашения, которые я ищу, более специфичны для разделения основных контекстов высокого уровня в сквозных приложениях JavaScript, где язык и платформа больше не становятся очевидным способом различения между ними.
