27.09.2025 05:14
Soloist 28 12000 Источник

Каждый раз, когда речь заходит о новом проекте, начинается вечный спор: какой фреймворк выбрать? Go или Rust для производительности? Python для скорости разработки? А может, стоит попробовать что-то на Elixir? Муки выбора знакомы многим. Вместо того чтобы в очередной раз теоретизировать, я решил пойти другим путем: взять и протестировать их все.

Так родилась идея проекта Framework DevBox — универсальной песочницы, где десять популярных фреймворков на разных языках упакованы в Docker-контейнеры и готовы к запуску одной командой.

Проблема: боль настройки

Чтобы по-настоящему «пощупать» фреймворк, недостаточно запустить "Hello, World!". Нужна полноценная среда разработки:

  • Hot-reload: Чтобы видеть изменения в коде мгновенно, а не перезапускать сервер вручную.

  • Линтер: Чтобы код был чистым и соответствовал стандартам.

  • Тесты: Чтобы убедиться, что всё работает как надо.

  • Сборка для продакшена: Чтобы понимать, как приложение будет деплоиться.

Настраивать всё это для каждого отдельного фреймворка — долго и утомительно. Можно потратить целый день на борьбу с зависимостями, версиями Node.js, виртуальными окружениями Python или переменными окружения Go, так и не дойдя до написания кода.

Я решил эту проблему раз и навсегда. Моей основной задачей стало создание такой системы, где для запуска любого фреймворка нужны только Docker и Make.

Решение: Framework DevBox

Framework DevBox — это репозиторий, в котором собраны популярные современные фреймворки, каждый в своей директории, с уже готовой инфраструктурой.

Что внутри «коробки» для каждого фреймворка?

  • Готовая среда разработки: Запускается одной командой make dev и включает hot-reload.

  • Проверка качества кода: Команда make test-prod запускает линтер и тесты, имитируя пайплайн CI/CD.

  • Раздельные Docker-файлы: Dockerfile.dev для разработки и Dockerfile.prod для оптимизированной продакшен-сборки.

  • Единая структура: Все проекты организованы одинаково, что упрощает переключение между ними.

  • Готовые эндпоинты: В каждом фреймворке уже есть простой "Hello World" и API для генерации QR-кодов.

Какие фреймворки вошли в набор?

Я старался выбирать современные и популярные решения с активным сообществом:

Как это работает?

Всё предельно просто. У вас должны быть установлены только Docker и Make.

  • Клонируете репозиторий.

  • Выбираете фреймворк, например, FastAPI.

  • Переходите в его директорию и запускаете dev-режим:

cd fastapi
make dev

Эта команда соберёт dev-образ, установит зависимости и запустит сервер с hot-reload. Ваша локальная папка app будет смонтирована внутрь контейнера, так что вы можете писать код в любимой IDE, а изменения сразу же применятся.

Хотите проверить, готов ли ваш код к продакшену?

make test-prod

Эта команда выполнит полный цикл проверки: прогонит линтер, запустит тесты и соберёт легковесный production-образ.

Единая структура — ключ к простоте

Чтобы не приходилось каждый раз разбираться в новом проекте, я привел все фреймворки к единой структуре:

.
└── [framework-name]/
    ├── app/                # Здесь живёт весь исходный код вашего приложения
    ├── Dockerfile.dev      # Dockerfile для разработки с hot-reload
    ├── Dockerfile.prod     # Многоступенчатый Dockerfile для production-сборки
    └── Makefile            # Файл с командами `dev` и `test-prod`

Такая стандартизация позволяет легко сравнивать фреймворки, не отвлекаясь на детали их конфигурации.

Выводы

После того как я закончил этот проект, мой взгляд на выбор технологий изменился.

  • Все языки хороши. Если выстроить прочную базу (hot-reload, линтер, тесты, CI/CD), комфортно разрабатывать можно на чём угодно.

  • Выбор зависит от задачи. На первый план выходит не сам язык, а экосистема: наличие нужных библиотек для решения конкретной проблемы, скорость разработки и простота поддержки.

  • Не бойтесь пробовать новое. Моя «песочница» как раз и создана для того, чтобы вы могли безболезненно запустить любой из этих фреймворков и решить, подходит ли он вам.

Я не хочу навязывать какой-то конкретный фреймворк. Вместо этого я предлагаю вам самим взять и попробовать. Вы можете просто запустить make dev и начать писать код или же, наоборот, использовать репозиторий как учебное пособие, раскручивая логику от Makefile и Dockerfile.

Надеюсь, мой проект сэкономит кому-то время и поможет сделать осознанный выбор.

Комментарии (28)


  1. randomsimplenumber
    27.09.2025 05:39
    #28887932

    Джентльменский набор веб разработчика, теперь с docker ;)


    1. Kahelman
      27.09.2025 05:39
      #28887996

      Хорошее ренегат проще всю заразу которую bpm притащит с компа убирать. :)


  1. DjUmnik
    27.09.2025 05:39
    #28888032

    Почему нет php?


    1. JBFW
      27.09.2025 05:39
      #28888216

      А что это? Наверное, на латыни или древнегреческом? /s

      В институте же рассказывали, "это устаревший язык без типизации" и немодный )

      А так-то идея засунуть всё в докер - логичная и хорошая, на каком языке не делай. Развернул локально - поработал, сделал, развернул на сервере - запустил в продакшн


      1. savostin
        27.09.2025 05:39
        #28888288

        Расскажите об этом WordPress’у. Посмеемся вместе.

        Холивара ради: Python, как по мне, еще менее типизирован. Хоть и модный, да.


        1. rSedoy
          27.09.2025 05:39
          #28889228

          даже стало интересно, почему ЯП, в котором 1 == '1' false, "еще менее типизирован", чем ЯП в котом это true?


          1. olegl84
            27.09.2025 05:39
            #28889942

            В современном типизированной php это будет исключение. Причем не сложно достаточно легко сделать отловить это с помощью статического анализа. И вообще это будет true если отключить типизацию


        1. santjagocorkez
          27.09.2025 05:39
          #28889246

          Холивара ради: рутноп, может быть, и менее типизирован, но дырявый вордпресс написан всё же на рнр.


          1. savostin
            27.09.2025 05:39
            #28889500

            Только не говорите, что это именно php «дырявый».


            1. santjagocorkez
              27.09.2025 05:39
              #28890490

              Только не говори, что ты не слышал про type hints в рутнопе, которые вполне позволяют статически линтерами прибивать кривые пулл реквесты. Конечно, если пользоваться ими.


              1. savostin
                27.09.2025 05:39
                #28890510

                Т.е. надо ждать пулл реквеста или запускать линтер, чтобы проверить типы? Смешно.


                1. santjagocorkez
                  27.09.2025 05:39
                  #28890650

                  О, я, наверное, пропустил нудную вступительную часть для самых маленьких любителей экстремального поведения.

                  Конечно же, IDE может подсветить нарушение контракта по хинтам. Внимательный разработчик обратит на это внимание и переделает. Однако, этот подход строится на одном лишь доверии. Разработчик может быть в плохом настроении, его могут отвлечь, он может даже намеренно захотеть добавить регрессию в код.

                  Что ж, скажет мой маленький любитель воскликнуть «смотри, как я могу», можно же повесить хук на коммит в репо. Плохой коммит не пройдет. Нет коммита — нет пуша. И мы снова возвращаемся к системе, построенной исключительно на доверии, ведь хук можно и отключить, особенно, если плохое изменение добавляется намеренно.

                  И тут мы возвращаемся к политикам, которые устанавливаются на серверной части нашего репозитория. Например, для того, чтобы мерж был вообще возможен, обязательно должен успешно выполниться pre-checkin build, который будет включать в себя прогон линтера и всех тестов. Упал линтер — мерж блокируется. Код не собрался — аналогично. Упал хоть один тест — ну ты понял. Сверху можно добавить минимальное покрытие тестами, которое оценивается после успешного прогона тестов. И само собой, у разработчика нет доступа к изменению политик. Таким нехитрым способом разработчик становится вынужден не только соблюдать контракт, но и описывать контракт в хинтах для нового кода, чтобы избежать падения линтера на «argument of type Any» или «function returns Any».


          1. olegl84
            27.09.2025 05:39
            #28889960

            Если бы вордпрес был бы написан на питоне, он был бы точно таким же дырявым. Только ещё и более тормозным и ещё мог бы уронить application server из-за утечки памяти


            1. santjagocorkez
              27.09.2025 05:39
              #28892250

              Каким образом? Импорт модуля требует соблюдения иерархии пакетов по всему пути, инклюд из произвольного места невозможен. Чтобы написать утечку в рутнопе, нужно специально стараться, поскольку большинство встроенных типов, особенно скалярных, организованы по модели refcount. Покажи код. Желательно сразу для сравнения быстрее/медленнее, течет/не течет.


              1. olegl84
                27.09.2025 05:39
                #28895630

                Сделать глобальную переменную и туда что-нибудь складывать. Например сделать типо кэш в виде словаря и добавлять туда значения. Постараться нужно, но джуны тебе ещё и не такое напишут. У меня в команде даже профи делают код который падает на больших данных.


                1. santjagocorkez
                  27.09.2025 05:39
                  #28896496

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

                  Что касается утечек, то всё ещё не вижу повода для беспокойства. Объемы записываемого в глобальную переменную невелики. Сервер приложений всё равно прибьет инстанс раньше по квоте обработанных запросов. Если же сервер приложений настроен не прибивать инстансы, то это вопрос к вашему сисадмину. К тому же, сеньеры ваши пулл реквест с таким вот одобрили? Ну вот, говорю же: специально стараться надо.


        1. AlexanderMelory
          27.09.2025 05:39
          #28890910

          По бенчмаркам python быстрее.

          В python есть отличная асинхронная модель, а в пыхе?

          В python неплохая модель многопроцессности, с версии 3.12 которая работает еще более производительно.

          Python не сравнится конечно по скорости с шарпом, джавой, плюсами, тем более растом, однако производительность, которую он выдает, вполне хватает практически на любой проект, где нет овербезумного РПС, и если с умом подойти к организации инфраструктуры, то питончика хватит.

          Так что пыха сдохла не потому что она не модная, а потому что отсталая


          1. dark_sage
            27.09.2025 05:39
            #28890960

            Пыха сдохла?))) Нуну... я скажу так: с прямыми руками без разницы язык, всё летать будет, а с кривыми хоть c, хоть плюсы, хоть шарп всё одно тормозить будет... каждому инструменту своё применение. И раз уж 80% интернета на пыхе, значит это лучший инструмент для большинства ситуаций.


          1. olegl84
            27.09.2025 05:39
            #28895716

            PHP используется в вэбе - каждый запрос выпоняется в отельном потоке. То есть php в принципе нету такое проблемы с многопоточностью. Если нужен асинхронный запрос, то в mysql и curl это есть, но для баз данных испоьзуется редко. В принципе есть и настоящая асинхронность и многопоточность через сторонее модули, но используется это редко так как в вэб это не особо актуально. Вот для консольных приложений да, это очень полезно. Но тут куча вариантов для реализации это через процессы. А вообще питон и пхп по своей идеалогии очень близки, но на пхп куча опенсоурс вэб приложений, на питоне много для ИИ и администрования сделано. На мой взгляд в вэбе джанго не может конкурировать с лавалел. Точно так же как пхп не может конкурировать с питон в написании ИИ приложений и утилит для администрования.


    1. Soloist Автор
      27.09.2025 05:39
      #28890974

      Изначально решил, что будет достаточно текущих. Да, я был предвзят. Но почитал комментарии и в ближайшее время добавлю PHP. Как сделаю — напишу.


      1. goremukin
        27.09.2025 05:39
        #28891436

        Может заодно и .net добавите?)


        1. Soloist Автор
          27.09.2025 05:39
          #28897008

          Хорошо, ждите. Laravel уже сделал.


    1. Soloist Автор
      27.09.2025 05:39
      #28896996

      Добавил Laravel


  1. S0mbre
    27.09.2025 05:39
    #28889556

    Идея интересная. Но в боевых проектах обычно (всегда) заранее выбирается и ЯП, и стек, поэтому много фреймов тестировать явно там не будут. Выбирают один и живут с этим)


    1. Soloist Автор
      27.09.2025 05:39
      #28890916

      Согласен. Мой случай как раз на точке выбора «заранее выбирается ЯП». Я ищу себе мой стек на новый проект.


  1. iredun
    27.09.2025 05:39
    #28889776

    Cookiecutter и "template repository" такие: "Мы что для вас шутка?"


    1. Soloist Автор
      27.09.2025 05:39
      #28890926

      Спасибо, каюсь, в моих знаниях не было этого инструмента. Cookiecutter понравился. Мне надо время на осознание и применение. Спасибо ещё раз.


  1. spiritedflow
    27.09.2025 05:39
    #28891342

    Отлично! Спасибо!

    Зря не написал про бонус разработчику от докера - теперь не нужно вводить эти ненужные пароли чтоб получить рута на хосте (docker run -it -v /:/mnt/root debian). Очень удобно /s