Сервисы которые ходят в одну БД или доп API как единая точка доступа к данным?

 

Архитектурные споры в команде. Кто прав?

Нужен слой REST API
4 - 80,00%
Не нужен слой REST API
1 - 20,00%
Свой вариант
 
 
Сообщения:21
Мне интересно мнение со стороны об архитектуре нашего проекта, точнее об одном очень древнем решении, которое тянется и по сей день. Есть у нас в компании пара среднего размера порталов, которые самостоятельно не ходят в БД, а обращаются к отдельному приложению X, которое предоставляет REST API. Есть также куча небольших сервисов, к которым также обращаются эти порталы. Эти сервисы имеют свое подключение к БД. БД одна, но это другая история.
Вот встал вопрос переписать один из наиболее нагруженных приложений (приложение Y), которое часто ходит в базу и обрабатывает данные и туда же их возвращает. Наша команда в большинстве за то, чтобы написать для этого приложения REST, добавив для него API в X, аргументируя это тем что база - наше слабое место, часто происходит, что количество подключений к БД переваливает за максимальное и поэтому мы можем ограничивать количество подключений в одном месте. А я за то чтобы выделить этому приложению свое подключение и настроить его отдельно. Моя аргументация такая: у нас не будет лишнего слоя, который будет отжирать свою долю памяти, его не надо отдельно поддерживать; изменение в приложении Y не повлечет за собой изменения в X; писать меньше тестов. Но мои доводы как-то не воспринимаются.
Короче, что вы думаете на этот счет, может я что-то не так понимаю?
Изменен:26 окт 2018 07:57
 
 
Сообщения:9731
Если честно, мало что понял из описания (2 раза перечитал). В целом рекомендации - два приложения не должны по возможности общаться с одной БД. Иначе такую БД будет сложно поддерживать.
Если нужно чтоб данные использовались обоими приложениями - одно из них должно предоставлять API, а другое - использовать это API. Ну либо выделить 3е приложение которое предоставляет API (если в этом есть реальная необходимость).
 
 
Сообщения:9
Я бы тоже сделал единую точку подключения к бд, через X. Чтоб не плодить сущности и иметь полный контроль над всеми обращениями к базе.

El pueblo unido jamas sera vencido!
 
 
Сообщения:21
И тут мои доводы проигрывают :)
Может я описал не всю картину. По мимо приложения X в бд ходят еще много других мелких приложений, но делают это они через нашу библиотеку с Hibernate.
По мне так REST API это дополнительные накладные расходы нужно
1. десериализовать данные в java объект;
2. потом сериализовать в json;
3. передать его по сети (тем более что они находятся на одном сервере);
4. снова десериализовать в те же java объекты, но уже на стороне Y;
5. обработать;
6. снова сериализовать в json;
7. передать по сети;
8. десеализовать в объекты;
9. сериализовать в данные.
А в моем представлении можно оставить только пункты 1, 5 и 9. И оттестировать только этот функционал.
 
 
Сообщения:9731
Apacci:
По мне так REST API это дополнительные накладные расходы нужно
Так и есть. Но ходить в одну БД несколькими приложениями делает разработку невыносимо сложной со временем. Если у вас нет астрономических требований по производительности - лучше начать с RESTa. Это проще.

Но внешний API - это не обязательно медленно:
1. Можно использовать кеширование на уровне HTTP сервера (apache, nginx). Тогда есть вероятность что какие-то запросы не будут доходить до сервиса - ответ получится очень быстрым.
2. Можно использовать 2ой уровень кеширование на уровне Hibernate. Т.к. одно приложение будет более нагружено нежели каждый из клиентов по отдельности - то кеш скорей всего будет использоваться более активно.
3. Можно не использовать JSON, а что-то бинарное, тот же Protobuf к примеру. Хотя не думаю что здесь будет ощутимый выигрыш.
Изменен:26 окт 2018 07:52
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет