"The Twelve-Factor Appp" и JavaScript
Неделю назад я делал доклад на fwdays про эффективную разработку NodeJS приложений (через 2-3 недели будет видео) и пообещал сделать серию постов на тему 12-ти факторов в канале. Вроде простая и всем понятная концепция, но не всегда ясно, что должен делать разработчик на практике.
Зачем нужны 12 факторов?
В WebbyLab, когда мы используем различные облачные решения, всегда стараемся минимизировать "vendor lock". Я придерживаюсь идеи, что лучше всего, когда ваше приложение без проблем можно будет запустить в любом облаке или даже на собственном железе. Мне нравится фраза Роберта Мартина, что работа архитектора это не принимать решения, а откладывать их насколько это возможно. Другими словами - сделать систему такой, чтобы критические решения можно было принять позже, когда будем иметь больше знаний о специфике задачи и предметной области. Так вот, ребята из Heroku разработали 12 правил, которые, хоть в контексте деплоймента, позволяют не принимать решения сразу.
12 правил, которые говорят, как написать приложение, чтобы оно обладало максимальной переносимостью между окружениями (локальное, облако, в docker-контейнере и тд) и было легче масштабировать. Считаю эти правила очень полезными и мы их используем и для бэкенда, и частично для фронтенда.
Правила - https://12factor.net/ru/
Настоятельно рекомендую с ними ознакомиться, даже если ты пишешь только фронтенд.
В следующих постах я пройдусь по каждому правилу и расскажу, как мы применяем их в JavaScript приложениях (фронтенд и бекенд).
Неделю назад я делал доклад на fwdays про эффективную разработку NodeJS приложений (через 2-3 недели будет видео) и пообещал сделать серию постов на тему 12-ти факторов в канале. Вроде простая и всем понятная концепция, но не всегда ясно, что должен делать разработчик на практике.
Зачем нужны 12 факторов?
В WebbyLab, когда мы используем различные облачные решения, всегда стараемся минимизировать "vendor lock". Я придерживаюсь идеи, что лучше всего, когда ваше приложение без проблем можно будет запустить в любом облаке или даже на собственном железе. Мне нравится фраза Роберта Мартина, что работа архитектора это не принимать решения, а откладывать их насколько это возможно. Другими словами - сделать систему такой, чтобы критические решения можно было принять позже, когда будем иметь больше знаний о специфике задачи и предметной области. Так вот, ребята из Heroku разработали 12 правил, которые, хоть в контексте деплоймента, позволяют не принимать решения сразу.
12 правил, которые говорят, как написать приложение, чтобы оно обладало максимальной переносимостью между окружениями (локальное, облако, в docker-контейнере и тд) и было легче масштабировать. Считаю эти правила очень полезными и мы их используем и для бэкенда, и частично для фронтенда.
Правила - https://12factor.net/ru/
Настоятельно рекомендую с ними ознакомиться, даже если ты пишешь только фронтенд.
В следующих постах я пройдусь по каждому правилу и расскажу, как мы применяем их в JavaScript приложениях (фронтенд и бекенд).
