Комментарии 9
Nginx тут лишний.
Why?
TLS не терминируется решением, но 443 выставлен наружу. Идея терминировать сервисом хостера, если такой есть, хорошая. Имена хостов захардкожены, это плохая практика - в Swarm будет один, в Kubernetes другой. Бекенд проксировать не обязательно, если нет задачи делать его открытым всему миру. Спеки OpenAPI фронтендер обычно смотрит лишь во время разработки. Трафик с фронтенда на бекенд гонять через nginx не нужно, как API Gateway он так себе. Фронтенд тоже непонятно зачем проксировать, он самодостаточен.
Показалось что автор не вполне понимает оркестрацию. Так себе реклама, но хороший способ научиться самому - научить других.
Уточню, что можно обойтись лишь одним nginx, вместо двух, если в frontend конфигурации прописать для location /api/ перенаправление на backend
Пояснение.
Nginx на фронте тут лишний. Так как перед ним уже стоит nginx.
Спасибо за статью
Ох. Начиналось все с того, что "а давайте сделаем серверный js, чтобы разработчик мог, зная только js разрабатывать и фронт и бэк". Но, надо заметить, получилось в основном довольно удобно в плане реализации, хоть и не без костылей.
А теперь у них и фронт на отдельном сервере запускается. Так сказать, обмажутся своим node js и ... друг друга в ...
Материал просто находка! Заценила, как QA. Статья написана доступным языком и имеет хорошую структуру с пошаговыми инструкциями. Примеры кода показывают, как просто можно создать базовый проект на FastAPI для бэкенда, что идеально для знакомства с современными инструментами в Python-разработке, плюс интеграция с Docker и Nginx помогает понять ключевые моменты развёртывания. Буду рекомендовать начинающим разработчикам в нашей компании.
Было бы здорово увидеть ещё дополнения или новые статьи про управление версионностью API, обеспечение безопасности при деплое и использование CI/CD для автоматизации процесса развертывания.
Как объединить фронтенд с бэкендом и не сломать веб-приложение