Лучшие практики с несколькими API-проектами с использованием Maven и Spring Boot - PullRequest
1 голос
/ 07 апреля 2020

Я работаю над проектом, который требует разработки двух отдельных API, которые подключаются к одной и той же базе данных.

API управления

Это внутренний, не -publi c API, который содержит конечные точки для управления несколькими ресурсами. Конечно, эти ресурсы сохраняются в базе данных.

Publi c API

Другой - API publi c, который содержит конечные точки для перечисления некоторых из вышеупомянутые ресурсы и операции выполнения, которые не сохраняются в базе данных.

До сих пор я просто создавал проект загрузки Maven Spring с использованием Spring Initilizr с необходимыми зависимостями и просто начинал разработку ... Как вы можете себе представить, это привело бы к созданию большого монолитного c проекта без какого-либо разделения, без необходимости увеличивая техническую задолженность.

Что было бы лучшим решением для этого случая?

Примерно так:

  • projectname-data : слой данных. Содержит модели и интерфейсы БД
  • projectname-management-api : API управления, который использует projectname-data в качестве зависимости
  • projectname-publi c -api : API Publi c, который использует dataname-data в качестве зависимости

1 Ответ

1 голос
/ 07 апреля 2020

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

Вещи, которые заставят вас задуматься о разделении их ... из того, что вы объяснили, в основном масштабирование. Если API publi c должен иметь возможность масштабировать намного больше, чем API управления, вы можете подумать о том, чтобы сделать его более легким и не масштабировать управление вместе с ним. Сильные ограничения, связанные с доступом, также могут быть проблемой.

Но если это не так, и у вас нет ясности с самого начала, не платите цену за несколько услуг с самого начала для такого простая вещь Если вы не в чём-то не разбираетесь, * * *, если у вас есть необходимые основы, у вас должно быть время и четкое представление о том, как их разделить в будущем.

"Дополнительные услуги" - это не то, чем вы являетесь предоставляется бесплатно.

Это мое 2e c;). Ура! П.Д .: У нас много таких сервисов, внутренних инструментов, и пока нет необходимости делить их. Я консультировался в других местах, где мы начали деление с самого начала, но не для внутренних инструментов, и тогда мы не будем напрямую использовать одну и ту же БД.

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