Упрощение стека проекта?

Question

[ItWheel]

есть веб проект, который читает/пишет данные из трех баз (у обоих есть rest)
1. базы Elasticsearch (только чтение, хранится контент)
2. базы SQL (запись/чтение заказов и личный кабинет)
3. redis (чтение/запись кеш ES одного запроса, и кеш пользовательской сессии)
архитектура SSR

Какой минимальный фреймворк можете посоветовать для данного проекта, orm не используется, данные все читаются и записываются http запросами. Веб часть это просто витрина данных, которую внешние пользователи крутят и максимум что могут сделать это записать заказ и личные данные. От фреймворка требуется только читать данные из rest Elasticsearch, читать/писать в SQL через rest и рендерить страницы на стороне сервера ssr.

Comments

[sim3x]

Какая у вас нагрузка?
Зачем столько баз?
ClojureScript?

[Александр]

• ElasticSearch использовать только как систему для поиска со своим кешем. База не работает стабильно и можно потерять все данные.
  
• Отказаться от SQL базы в пользу Redis или наоборот, тем самым уменьшив количество технологий.
  
• Отказаться от Symfony, указанную в тегах, в пользу какого нибудь js фреймворка. Вам же все равно нужен SSR. Зачем плодить сущности?
  

[ItWheel]

sim3x, ES хранить в себе контент, фасетный поиск, подбор аналогов по критериям и совместимых товаров + поиск
в mysql записывают заказы и личный кабинет пользователя там храниться и читается
redis для кеширования сессий пользователей

[ItWheel]

Александр, ES далеко не только поиск может делать, но и агрегацию документов по критериям (это для нас крайне важный функционал из коробки)

в пользу какого нибудь js фреймворка - я и решил тут задать вопрос, что бы увидите какие вообще бывают варианты

[Александр]

ItWheel, https://guide.meteor.com/vue.html

Answer 1

[grinat]

Ну коли страницы рендерить ему еще надо, то либо nestjs либо loopback

Answer 2

[Flying]

Для работы с Elasticsearch очень хорошо работает ruflin/elastica, хотя есть и более низкоуровневые официальные binding'и: elasticsearch/elasticsearch

Для работы с Redis чаще всего используется predis/predis, но с ним сейчас непонятная ситуация из-за того что автор уже давно не поддерживает библиотеку и сейчас есть проблемы с PHP7.3+. Есть форк исправляющий эту проблему, но большинство библиотек завязаны на predis, так что как разрулится ситуация дальше - пока не очень понятно.

Для работы с HTTP запросами сейчас как правило используют guzzlehttp/guzzle, хотя есть и другие хорошие варианты.

Для работы с SQL есть множество библиотек разной степени развития и популярности. Если хочется именно plain sql - то можно посмотреть на doctrine/dbal, он очень развит и стабилен.

Связать всё это в кучу может любой современный framework, лично я бы смотрел в сторону Symfony (из 4-й версии вполне можно сделать micro framework из-за чего прекратили разработку Silex), но есть и реальные микрофреймворки, к примеру весьма популярен slim/slim

Comments

[ItWheel]

от фреймворка не требуется работа с sql т.к. выше я отметил что это sql база у которой есть rest, т.е. это простые http запросы не более.
Symfony 4 - используем, но считаю его жутко избыточным т.к. найти разработчика крайне сложно на доработки.

[Flying]

ItWheel, я специально указал что Symfony 4 приложение сейчас по факту можно свести чуть ли не к нескольким файлам. Т.е. не стоит рассматривать только Symfony как framework, это в первую очередь набор reusable компонентов, их композиция в виде symfony/framework-bundle - просто официальный способ.

Логическую связь избыточности Symfony и сложности поиска разработчиков на Symfony я, честно говоря, не понял...

[Александр]

ItWheel, rest запросы к базе - это медленно, да и с точки зрения секурности спорно.

[ItWheel]

т.е. фронд должен напрямую обращаться к базе ?

Answer 3

[Vitsliputsli]

От фреймворка требуется только читать данные из rest Elasticsearch, читать/писать в SQL через rest и рендерить страницы на стороне сервера ssr.

Вам не нужен фреймворк.

Фремворк поможет не быть зависимым от разработчика, сейчас эра фреймворков, и разработчики почти все фреймворк ориентированы (даже если он и не нужен)

Выбирать инструмент, потому что модно, не верный подход.
Зависимость от разработчика никуда не денется, фреймворк даёт только инструменты для структурирования, как ими распредиться зависит только от разработчика. Даже в MVC фреймворке нарушают MVC очень часто, а это просто схема разделения данных, со структурой все сложнее.
Фреймворк-ориентированный разработчик это чтото страшное, всякий, конечно, знает одни инструменты лучше других, но ориентированный это больше про того, кто освоил только молоток, и теперь для него все гвозди. Поэтому, если конструированием и архитектурой будет заниматься не специалист, а фреймворк, то вас ждёт много проблем в будущем, потому что инструмент в принципе не может этого сделать.

Comments

[ItWheel]

ок, фремворк не нужен, что тогда нужно ?
api gateway ?

[Vitsliputsli]

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

[ItWheel]

нужна задача - выше написано, доступ к двум БД с rest из веба + ssr рендеринг.
одна вода в вашем "ответе"

[Vitsliputsli]

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