Обслуживать содержимое из файла с базой данных в 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 или..). Если вы хотите применить изменения, инициируйте сборку и создайте статический контент и разверните его.