Какова структура сервера приложений node.js?

Question

Я делаю node.js приложение с socket.io и мне интересно, какова правильная структура папок. У меня есть эти файлы.

• Сервер. js
• пакет. json

и

• Клиент . js
• Индекс. html

У меня также есть несколько изображений (png), которые я хочу отобразить в своем индексе. html. (https://www.tutorialsteacher.com/nodejs/serving-static-files-in-nodejs) Некоторые имена папок, которые я видел, это publi c, stati c, сервер и приложение, но я не уверен, для чего каждое из них, если. Мое приложение использует socket.io, http, path и express.

Это мой первый вопрос, поэтому извините, если он не был сформирован правильно.

Спасибо.

Answer 1

Как вы организуете свои файлы на стороне сервера, полностью зависит от вас, и есть много разных способов сделать это, и ни одного «правильного» или «оптимального» способа. Для удобства развертывания вам просто нужно согласованное относительное расположение между всеми частями, чтобы все они могли использовать относительные пути для ссылки друг на друга и не зависеть ни от каких абсолютных путей.

Единственное, что абсолютно должно быть правдой является то, что ваши publi c файлы (вещи, которые отправляются клиенту), как правило, должны быть в своей собственной иерархии, которая может иметь общий родительский файл с файлами сервера, но файлы сервера не должны быть внутри publi c иерархия. Итак, что-то вроде этого было бы хорошо:

 project
      server
           server.js
           package.json
      public
           client.js
           index.html

В зависимости от того, сколько у вас файлов publi c и кто еще может над ними работать, обычно их разделяют по типу:

project
    server
         server.js
         package.json
         node_modules
            various modules you're using in your server code
    public
         scripts
             client.js
         html
             index.html
         images
             logo.png
         style
              main.css
    database
         database stuff here

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

Если у вас есть файлы базы данных, вы можете поместить их в другой каталог. на том же уровне, что и сервер.

Как именно вы размещаете файлы сервера или файлы publi c в их иерархиях, зависит только от вас и от того, что вам нужно, если вы храните их отдельно.

Некоторые моменты для рассмотрения:

1. Вы что-нибудь переносите или компилируете? Если это так, вам понадобятся исходная и распределительная иерархии.
2. Вероятно, это сейчас или в будущем проект с несколькими людьми. Если да, есть ли в проекте люди, которые должны иметь доступ только к определенным частям проекта (например, GUI дизайнеры, которые могут иметь доступ только к HTML, CSS и файлам изображений)? Если это так, вы, вероятно, захотите структурировать вещи таким образом, чтобы обеспечить более простой доступ.
3. Используете ли вы express.static() или что-то для автоматического обслуживания файлов определенных типов. Если это так, они должны быть чисто изолированы в каталоге или каталогах, что делает использование express.static() простым и безопасным.

Answer 2

Не существует структуры папок проекта "хорошо для всех". Это действительно зависит от проекта, над которым вы работаете, и может сильно зависеть от архитектурных решений.

Для небольшого проекта и в целях обучения вы можете использовать «стандартную» структуру папок, например такую, которая Express. js использует в своем express -генераторе , или вы можете использовать нечто подобное , упомянутому здесь .

Для проектов с одним человеком Я бы посоветовал вам сделать это проще и просто пытаться установить некоторые границы между модулями с пресловутыми различными обязанностями, такими как routers, база данных models, tests, assets, templates и логистика бизнеса c связанные services. Достаточно, чтобы сохранить его организованность и попытаться начать думать о том, как поддерживать разъединенные компоненты во время обучения.

Для более крупных проектов я бы посоветовал вам провести дальнейшее исследование топической c, чистой архитектуры Роберта C. Мартин - удивительная книга для вас, чтобы углубиться в архитектуру программного обеспечения и придумать развивающуюся структуру проекта, которая лучше соответствует вашим потребностям и проекту.