Обслуживать содержимое из файла с базой данных в node

Я делаю новую версию старого статического веб-сайта, который вырос до статических страниц более 50+.

Итак, я создал файл JSON со старым контентом, поэтому новый веб-сайт может быть больше CMS (с шаблонами для общих страниц), и поэтому бэкэнд становится более DRY.

Интересно, могу ли я использовать этот контент для своих представлений из JSON или если я должен иметь его в базе данных MySQL?

Я использую Node.js, а в Node я могу хранить этот файл JSON в памяти, поэтому чтение файла не выполняется, когда пользователь запрашивает данные.

Есть ли для этого правильная практика? существуют ли различия в производительности между ними, обслуживающие кешированный файл JSON или через MySQL?

Файл, о котором идет речь, составляет около 400 КБ. Если размер файла имеет отношение к выбору одной тенологии над другой?

Ответ 1

Обычно база данных используется для частого изменения динамического содержимого, записи имеют отношения "один ко многим" или "многие ко многим", и вам нужно запрашивать данные на основе различных критериев.

В случае, описанном вами, похоже, что вы будете в порядке с файлом JSON, кэшированным в памяти сервера. Просто убедитесь, что вы обновляете кеш всякий раз, когда содержимое файла изменяется, то есть перезагружая сервер, вызывая обновление кеша через HTTP-запрос или контролируя файл на уровне файловой системы.

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

Статические файлы Cache и Gzip (html, js, css, jpg) в памяти сервера при запуске. Это можно легко сделать, используя пакет npm, например connect-static
Использовать кеш браузера для клиента, настроив правильные заголовки ответов. Один из способов сделать это - добавить заголовок maxAge в определении маршрута Express, т.е.

app.use "/bower", express.static( "bower-components", {maxAge: 31536000})

Здесь - хорошая статья о кешировании браузера

Ответ 2

Зачем добавлять еще один слой косвенности? Просто слушайте взгляды прямо из JSON.

Ответ 3

Если вы уже сохраняете свои представления как JSON и используете Node, может быть стоит рассмотреть возможность использования стека MEAN (MongoDB, Express, Angular, Node):

Таким образом, вы можете закодировать все это в JS, включая хранилище документов в MongoDB. Я должен указать, что я сам не использовал MEAN.

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

Независимо от того, хотите ли вы это сделать, это полностью зависит от вашего индивидуального проекта и от того, будет ли оно/как оно может развиваться.

Как вы внедряете новую версию (с CMS) на веб-сайте, это предполагает, что она будет жить и подвержена росту или изменению, и, возможно, хранение JSON в MySQL - это сохранение проблем на будущее. Если это действительно один файл, вытащить из файловой системы и кэшировать его в ОЗУ, вероятно, сейчас проще.

Я сохранил JSON в MySQL для наших проектов раньше, и во всех, кроме нескольких отдельных случаях, закончилось разделение данных компонентов.

Ответ 4

400 КБ крошечный. Все данные будут отображаться в ОЗУ, поэтому ввод/вывод не будет проблемой.

Динамически создавая страницы - все тяжелые нападающие делают это, если не по какой-либо другой причине, кроме вставки рекламы. (Я работал в недрах такой компании. Было много страниц, и только несколько были "статичными".)

Какая CMS - слишком много на выбор. Выберите пару, которая звучит легко; то посмотрите, сможете ли вы с ними позаботиться. Затем выберите между ними.

Linux/Windows; Apache/Tomcat/Nginx; PHP/Perl/Java/VB. Опять же, ваш уровень комфорта является важным критерием на этом крошечном веб-сайте; любой из них может выполнить задачу.

Где это может пойти не так? Я уверен, что вы ударили по веб-страницам, которые довольно медленны для рендеринга. Таким образом, очевидно, что можно пойти в неправильном направлении. Вы уже переключаете передачи; быть готовым переключить передачи через год или два, если ваше решение окажется менее совершенным.

Предотвратите слишком большую CMS, которая слишком сильно связана с схемами EAV (ключ-значение). Они могут работать нормально для 400 Кбайт данных, но они уродливы для масштабирования.

Ответ 5

Хорошая практика для обслуживания json непосредственно из самой ОЗУ, если ваш размер данных не будет расти в будущем. но если данные будут увеличены в будущем, то это станет худшим случаем применения.

Ответ 6

Если вы не ожидаете добавить (m) какие-либо новые страницы, я бы попросил простейшее решение: прочитайте JSON один раз в памяти, а затем откройте память. 400 КБ - очень мало памяти.

Не нужно включать базу данных. Конечно, вы можете это сделать, но это переполняет здесь.

Ответ 7

Я бы рекомендовал генерировать статический html-контент во время сборки (используйте grunt или..). Если вы хотите применить изменения, инициируйте сборку и создайте статический контент и разверните его.