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

У нас было не так много времени, поэтому мы просто хотели ускориться и написать бизнес-логику, а не тратить время на настройку инструментов вместе.
Единственным ограничением было то, что мы все были JS-разработчиками и хотели писать на JavaScript или TypeScript, а также со стороны DevOps, мы знали, что будем использовать K8s (как бы я ни любил Serverless, к сожалению, этого не было на картинке — может быть, в другой блог в другой раз, чтобы поговорить об этом).

У нас был список предложений, и там у нас были фреймворки или несколько библиотек, работающих вместе. Мы решили вытащить библиотеки, так как хотели, чтобы самоуверенная структура давала нам возможность сосредоточиться на написании кода для логики с первого дня. Конечно, между этими подходами есть компромисс, поскольку у вас будет свобода выбора лучших библиотек (или тех, с которыми вам удобно) или вы можете просто ограничить себя фреймворком и его соглашениями/шаблонами.

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

Но как мы могли решить?

Мы подготовили список функций и соображений, которые нам понравились из фреймворка или библиотеки, и дали им баллы.

  • Только Backend/Frontend или Full-Stack Некоторые фреймворки также предлагают Frontend в своей архитектуре, поэтому нет необходимости иметь отдельный проект, но опять же, вы будете ограничены их шаблонами.
  • Стабильная версия Существует множество замечательных фреймворков, но не все из них готовы к работе!
  • Поддержка сообщества Вы удивитесь, насколько это важно. Когда вы столкнулись со странной ошибкой и хотите закричать и уйти с работы, вы можете просто поискать ее в Интернете или открыть вопрос на Github, и люди вам помогут.
  • Документация Нет необходимости упоминать, насколько это важно.
  • Миграция БД Это одна из недооцененных функций, которая спасет вашу жизнь. Возможность управлять своими миграциями, отменять их или применять к новым средам.
  • Отладка Простая отладка сэкономит много времени разработчикам и ускорит конвейер доставки.
  • Кривая обучения Как всегда, нехватка времени является самой большой проблемой при разработке любого продукта, и это поможет быстро нарастить темпы по мере написания кода.
  • Тестирование Всегда есть способ протестировать код с помощью нужной вам технологии. Это зависит от того, какой тип тестирования. Я бы хотел, чтобы платформа предлагала модульное тестирование из коробки, но для интеграции или сквозного тестирования я мог бы использовать свое решение.
  • Ведение журнала Любому производственному приложению требуется хорошее ведение журнала. Избавьте вас от проблем, когда ваши пользователи сообщают об ошибках.
  • Конфигурация Сколько времени мы потратим на настройку проекта, чтобы его настроить? он высокий или это просто вопрос запуска команды?
  • Инструменты CLI Многие фреймворки предлагают команды CLI, которые упрощают создание и формирование большого количества кода и экономят много времени.
  • Протокол API серверной части Мы хотели иметь Restful, но некоторые также предлагают Graphql!
  • Поддержка машинописного текста Это было необязательным, когда мы принимали решение, но если я вернусь, я сделаю это обязательным.
  • Карьера Когда я хочу изучить технологию X, я думаю: «Каково будущее X?». На этот раз не для меня, а для всей команды. Будут ли разработчики счастливы, когда станут экспертами в этом фреймворке? Когда мы решим нанять новых разработчиков, будут ли они рады работать над этим?

Итак, какие фреймворки?

Наш окончательный список фреймворков:

Решения

Первое решение, которое мы приняли, касалось первого пункта в списке: Only Backend or Full-Stack.
Мы хотели масштабироваться, и мы знали, что у нас будет несколько веб-приложений, использующих наш API, поэтому мы решили разделить наш внешний интерфейс.< br /> Это было легко, Next.js стал победителем, так как он предлагает массу интерфейсов и удовлетворяет большинству наших пунктов в списке.

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

Позже мы избавились от Express + Prisma, потому что для его подготовки нам нужно было много настроек и добавление множества других библиотек для будущих требований.

Таким образом, у нас был окончательный список фреймворков со «Стабильной версией», «Поддержкой сообщества» и хорошей «Документацией». у них были хорошие инструменты или команды CLI или возможности управления миграцией БД.

Среди тех, что мы выбрали NestJS: он обладал почти всеми нужными нам качествами, единственной проблемой в то время была Prisma, которая не была готова к производству, а ее миграция была экспериментальной, но прямо сейчас после более чем в год, мы очень рады тому, что сделали!
Мы увеличили масштабирование в 10 раз на стороне продукта и в 4 раза на стороне разработчиков, и масштабирование NestJ очень хорошо, плюс Prisma выпустила множество функций и упростила для нам масштабировать на стороне БД.
Говоря с разработчиками в команде, они тоже очень довольны. Они изучили фреймворки (как NextJ, так и NestJ), которые отлично подходят для их карьеры!