[WIP] Файловая структура шаблона
ivlevdenis opened this issue · 26 comments
.
├── .circleci/
│ └── config.yml
├── compose/
│ ├── docker-compose.production.yml
│ ├── docker-compose.staging.yml
│ └── docker-compose.yml
├── docker/
│ ├── db/
│ │ └── init_user.sql
│ ├── Dockerfile
│ └── Dockerfile.prod
├── project/
│ ├── api/
│ │ ├── v1/
│ │ │ ├── serializers/
│ │ │ │ └── __init__.py
│ │ │ ├── views/
│ │ │ │ └── __init__.py
│ │ │ ├── __init__.py
│ │ │ └── urls.py
│ │ └── __init__.py
│ ├── apps/
│ │ └── __init__.py
│ ├── settings/
│ │ ├── django/
│ │ │ └── __init__.py
│ │ ├── other/
│ │ │ └── __init__.py
│ │ ├── ci.py
│ │ ├── common.py
│ │ ├── dev.py
│ │ ├── production.py
│ │ └── staging.py
│ ├── tests/
│ │ └── __init__.py
│ ├── asgi.py
│ ├── __init__.py
│ ├── Makefile
│ ├── manage.py*
│ ├── pyproject.toml
│ ├── urls.py
│ └── wsgi.py
├── .dockerignore
├── .editorconfig
├── .gitignore
├── Makefile
└── README.md
А почему отдельная директория project ???
У меня сразу протест по корневым папкам. Папка называется project, но проект это не только бэк но и фронт. А в папке только бэк. Поэтому я за разделение по папкам, frontend/backend/devops.
А зачем нужно два makefile?
Судя по структуре settings, там используется модуль split-settings. Мы его еще не юзали, так что мы тогда тебя спрашивать будем, по примерам использования, видимо.
@akirill0v Что бы куча аппов не смешивалась с остальным.
@akirill0v Что бы куча аппов не смешивалась с остальным.
Вот вопрос как раз - зачем в одном репозитории несколько аппов? Можете привести пример какого уровня аппы там могут быть. Это же не монорепозиторий?
@uhbif19 никакого фронта в беке быть не должно по определению, если это не django templates based проект.
Не понял, зачем разделять api и apps.
Не понял, зачем разделять api и apps.
Для поддержания версионирования. И что бы не смешиывать всё в одном месте.
@ivlevdenis Понятно что в папках джанги фронта не должна быть. Но в репе то он есть, и нужно называть папки для них. Или ты хочешь разделять репы фронта и бэка?
У меня сразу протест по корневым папкам. Папка называется project, но проект это не только бэк но и фронт. А в папке только бэк. Поэтому я за разделение по папкам, frontend/backend/devops.
А зачем нужно два makefile?
Судя по структуре settings, там используется модуль split-settings. Мы его еще не юзали, так что мы тогда тебя спрашивать будем, по примерам использования, видимо.
Нет, там просто импорты с common.py
@ivlevdenis Понятно что в папках джанги фронта не должна быть. Но в репе то он есть, и нужно называть папки для них. Или ты хочешь разделять репы фронта и бэка?
Именно разделять репы. Это уберет проблему деплоя, и разделения разработки фронта и бека, не будут смешиваться коммиты, и тд
Один мейк внутренний в контейнере будет использоваться, один для разработки и упрощения запуска частых комманд.
А почему отдельная директория
project???
Включает в себя всё по проекту - зависимости, приложения, настройки и тд и тп. Именно эта папка будет копироваться в образ.
Добавил страницу в вики, что бы удобнее было отслеживать изменение
Для поддержания версионирования. И что бы не смешиывать всё в одном месте.
В тех случаях что видел я, выделени api приводит к тому, что структура модулей api полностью повторяет структуру аппов. Хочешь поменять логику - проходишься по аппу, а затем ищешь сериалайзер и вью. То есть эти вещи часто меняются вмести, и логично их держать в одном модуле.
Разве нет?
Про версионирование согласен, удобно.
@WinterCitizen @Anon731 Присоединяйтесь.
Именно разделять репы. Это уберет проблему деплоя, и разделения разработки фронта и бека, не будут смешиваться коммиты, и тд
Какую "проблему деплоя" это убирает? Я просто не знаю, часто агитируют за раздельные репы и я так не понял, чем в реальности чем это хорошо.
По моему общий реп не усложняет, а упрощает деплой. Если ты хочешь скоординировать деплой то это просто. Нет неявной зависимость одного репа от другого.
и разделения разработки фронта и бека
А в чем тут проблема с одним репом?
И как работает деплой для разделенных репов?
Именно разделять репы. Это уберет проблему деплоя, и разделения разработки фронта и бека, не будут смешиваться коммиты, и тд
Какую "проблему деплоя" это убирает? Я просто не знаю, часто агитируют за раздельные репы и я так не понял, чем в реальности чем это хорошо.
По моему общий реп не усложняет, а упрощает деплой. Если ты хочешь скоординировать деплой то это просто. Нет неявной зависимость одного репа от другого.
и разделения разработки фронта и бека
А в чем тут проблема с одним репом?
И как работает деплой для разделенных репов?
Давайте рассматривать фронт и бек как отдельные приложения, соответственно если это не django templates. Фронт мы сможем изменять и деплоить независимо от бека. У нас появляется различная для фронта и бека инфраструктура, если смешивать её получится сложноподдерживаемая структура проекта. Программистам разных стеков не нужно мучаться с проблемами не в их приложениях, на примере призмы у меня упорно не хотел собираться фронт из-за некоторых проблем. Переменные окружения не будут смешаны. Запуск тестов будет раздельным, и если у нас падают тесты фронта, то бек от этого не зависит.
И так как мы сейчас в основном разрабатываем api, то это просто интерфейс, которым могут пользоваться различные клиенты, без разделения на фронт, мобилку, другой сервис. Мы же не будем держать это всё в одном репе)
думаю надо посмотреть, как это сделано уже в компании - есть практика по рубистам, наверняка, они также имеют шаблоны.
на мой взгляд, этот шаблон вполне подойдет для больших и очень больших проектов.
в идеале, думается, что можно иметь 2 шаблона - стартовый и продвинуй.
если проект маленький - можно начать со стартового.
если большой - то использовать продвинутый.
также, есть ощущение, что из стартового проекта инкрементально можно создать продвинутый.
На самом деле этот шаблон и для маленьких проектов заходит отлично.
также, думаю надо заюзать cookiecutter и добавить celery или rq для очередей.
когда-то делал кукикаттер - можно что-то оттуда почерпнуть.
Да. Я начал писать сервис для карьеры с использованием данной структуры, там есть celery.
если хочется использовать шаблон для больших проектов - то можно сразу заюзать готовый шаблон от wemake, например. он уже проверенный ребятами и комьюнити - не очень понимаю, зачем писать свое решение.
в этом шаблоне от wemake есть абсолютно все и даже больше - именно то, к чему стремится текущая версия нашего шаблона.