Вопрос о том, нужно ли запускать сервис с API и сайт на разных портах, в контексте Go, зависит от требований вашего проекта и особенностей вашей архитектуры.
Во-первых, при использовании Go вы можете разрабатывать и запускать как монолитные приложения, так и микросервисы. Если у вас есть отдельный сервис API и отдельный веб-сайт, вы можете рассмотреть два подхода к развертыванию.
Первый подход - использование разных портов. В этом случае вы можете запустить ваш сервис API на одном порту (например, 8000), а ваш веб-сайт на другом порту (например, 8080). Это позволит вам разделить две части вашего приложения и обеспечить изоляцию их функциональности. Такой подход особенно полезен, если у вас есть различные требования к безопасности или разрешениям доступа к API и веб-сайту.
Второй подход - использование одного порта для обоих компонентов. Go обладает мощным маршрутизатором (router) в стандартной библиотеке, например, net/http, благодаря которому вы можете определить различные обработчики для разных типов запросов. Вы можете создать маршруты и обработчики для ваших API-запросов и веб-страниц в одном и том же сервере на одном порту. Это может быть удобно, если у вас нет строгих требований к изоляции функциональности или если у вас есть общая аутентификация и авторизация между API и веб-сайтом.
Выбор между этими двумя подходами зависит от вашего проекта и его потребностей. Если у вас есть явные требования к безопасности или функциональности, и вам потребуется различать доступ к API и сайту на уровне сервера, использование разных портов может быть предпочтительным. Однако, если у вас нет таких требований или если вам нужно обеспечить изоляцию функциональности на уровне приложения, использование одного порта может быть более простым и удобным решением.
В любом случае, важно иметь хорошо проработанный и логически структурированный код, чтобы обеспечить четкую раздельность между вашим API и веб-сайтом, независимо от того, выберете вы один или два порта. Это поможет сделать ваше приложение легко поддерживаемым и расширяемым в будущем.