Считается ли промежуточное ПО connect.static достаточно надежным для обслуживания статического контента, который представляет собой нечто большее, чем просто таблицы стилей и скрипты?
(Я имею в виду такие ситуации, как обслуживание большого количества файлов изображений).
Или было бы более уместно использовать «стандартный» веб-сервер, такой как nginx, вместе со статическим контентом?
Какой-то нагруженный вопрос. Это нормально, пока это не так.
Эти статические промежуточные программы являются удобными методами для преимущественно динамических сайтов. Вы всегда можете переключиться на использование сервера статического контента на основе Node.js, а затем продолжить NginX, который предназначен в первую очередь для обслуживания статического контента, а затем, когда этого недостаточно, вы можете настроить обратный прокси-сервер NginX для нескольких серверов NginX, если дисковый ввод-вывод становится узким местом, и вы можете использовать Циклический DNS для дальнейшего улучшения, если ваш обратный прокси-сервер не может обрабатывать количество входящих подключений и/или вы хотите распространять хостинг по всему миру, и вы всегда можете оплатить всю эту инженерную работу, разместив свой статический контент в CDN.
Итак, сделайте несколько тестов. Сколько запросов, по вашему мнению, будет на вашем сайте? Какой процент будет статическим по сравнению с динамическим контентом? Какая часть этого статического контента может быть кэширована конечным пользователем по второму запросу? Насколько велики эти файлы в среднем?
Как только вы сможете рассчитать что-то вроде «4000 запросов в секунду с общей пропускной способностью 30 МБ в секунду», вы сможете решить, где по скользящей шкале хостинга статического контента вы должны создавать.
