Текущий проект развивался и работает на PHP + SQL Server, при этом база переваливает за терабайт, сама по себе база так же содержит очень много логики.
Сайт сервиса содержит кучу лапши на JavaScript которая через REST (на PHP) получает данные у базы. Всё как делалось 10 лет назад. Рост клиентов и базы идет каждый месяц, кэширования результатов и каких либо запросов к базе до сих пор нет. Начитался документаций по Angular и Meteor.
Появилось желание переехать на Meteor, но базу придется оставить, её использование будет нереактивное.
То есть сайт и вся текущая информация держится в MongoDB, по сути она является кэшем. По запросу кэш прогревается. Так же работает демон который раз в минуту (секунду) чистит кэш от старых данных, а так же синхронизирует все данные с SQL Server.
Есть ли какие-то best practices в моем случае, или я собираюсь использовать не то и не там и Meteor вообще не для продакшена?
Реактивно SQL запускать нам не требуется, так как вызовы слишком дорогие.
Хотелось бы обыграть следующие пункты:
1. Кэширование запросов к базе на стороне бэкэнда
2. Максимальный быстрый коммит данных на бэкэнд, в нашем случае промежуточный, без ожидания их записи в SQL базу.
3. Красота, простота и быстрота (в том числе и написание кода) на фронтэнде.
По сути это кэширование в обе стороны + Angular
Переписывать пока нечего, рассматриваем технологии.
Георгий Григорьев: Почему? Метеор меня тем и подкупает, что он сразу всюду, как цельное приложение. Набросал небольшой дашборд для проекта на нем для теста, пока всё нравится кроме таких мелочей как долгий перезапуск в случае изменения серверных скриптов. Ну и фильтры пока не удалось заставить нормально работать - грузит %100 ядра при получении данных.
"Сайт сервиса содержит кучу лапши на JavaScript", а нужно "Красота, простота и быстрота"
И jquery тут не лучший выбор с точки зрения производительности.
К слову, я честно говоря не задавался вопросом, а в local storage случаем хранится не пара ключ: значение?
Evgeniy Z: именно. Ключ значение. Кеш добавляете на уровне запросов к api.
А что мешает сделать красиво на jquery (конечно если руки есть)
На щёт производительности
Есть шаблон inspinia_admin-v2.3 + нетбук (1.6 проц, 2 озу) + мазила
JQuery версия работает очень быстро (у себя я ещё прикрутил динамическую подгрузку кода с помощью jquery Load), а angular версия тупо крашит браузер. Так что выбор за вами ;D
Владимир Грабко: так написал автор поста. А я спрашивал про localstorage.
Лично я для своего проекта выбрал метеор+реакт, при этом ничуть не жалею. Автор хочет использовать метеор в связке с ангуларом, лично мое мнение - идея имеет место быть и может жить, смотря как подойди к вопросу.
Evgeniy Z: не так вас понял. Я сделал кеш на стороне клиента таким образом
В функции пытаюсь получить json масив из хранилища
если получил то смотрю expiries если действителен то отдаю данные из хранилища пользователю
если любое из условий выше не выполнено то делаю запрос к api и ложу то что вернул апи в локальное хранилище и отдаю пользователю
Владимир Грабко:
Ваше решение мне видится так - "А давайте возьмем ваш велосипед, который конструировался годами и сделаем ещё один такой же на mysql."
1. С базой у нас проблем нет, смысла её куда-то там переводить, с чего вы взяли, что оно заработает лучше?
2. Метеор был выбран для того, чтобы заменить стек языков js + php на просто js. Ну и очень понравился ddp в коробке. Опять же, смысл переводить на nodejs, если можно сразу структурировать на meteor?
3. Кэш хранить на пользователе сомнительная идея. А если 100 пользователей запросили один и тот же контент?
4. Да, скорость интересует, тестил какой-то bootstrap шаблон на Angular - гугхром завис. Опять же, что мешает сделать, чтобы не зависло? К тому же, Angular нравится пока только из-за шаблонизатора.
Основной вопрос тут именно в проблемах которые могут возникнуть при написании приложения на Meteor с работой внутри на SQL Server.
Алексей: да и как по мне то js на серверной стороне не очень хорошая идея (до сих пор не понимаю как можно было додуматься сделать виртуальную js машину для сервера), а метеор пока что не самая хорошая парадигма программирования.
///" Опять же, смысл переводить на nodejs, если можно сразу ///структурировать на meteor"
Код Meteor работает поверх node.js + он ещё и не поддерживается асинхронной модели node.js (аля пляски с бубном)
///Опять же, что мешает сделать, чтобы не зависло?
ангуляр
///" К тому же, Angular нравится пока только из-за шаблонизатора."
Шаблонизатор и есть самой глючной частью всяких js фреймворков.
Средний
