Циклические импорты в ESM
В 13-й версии ноды ESM уже доступны и без флага "--experimental-modules". Мы готовися к полноценному переходу на mjs в наших бэкендах. Многие преимущества ESM и так очевидны, но есть некоторые, про которые не так много говорят. Одна из классных фич - это нормальная отработка циклических зависимостей. Обычно циклических зависимостей стоит избегать, но иногда они полезны. В нашем случае они полезны при работе с Sequelize. Для описания моделей Sequelize мы используем ES6. Допустим, у нас есть пользователь и его сообщения, описание моделей может выглядеть так:
Класс User:
Набросал пару отдельных примеров для теста: https://github.com/koorchik/node-import-vs-require
В 13-й версии ноды ESM уже доступны и без флага "--experimental-modules". Мы готовися к полноценному переходу на mjs в наших бэкендах. Многие преимущества ESM и так очевидны, но есть некоторые, про которые не так много говорят. Одна из классных фич - это нормальная отработка циклических зависимостей. Обычно циклических зависимостей стоит избегать, но иногда они полезны. В нашем случае они полезны при работе с Sequelize. Для описания моделей Sequelize мы используем ES6. Допустим, у нас есть пользователь и его сообщения, описание моделей может выглядеть так:
Класс User:
import Message from './Message';Класс Message:
class User extends Base {
static schema = {
id : {
type: DT.UUID,
defaultValue: DT.UUIDV4,
primaryKey: true
}
};
static initRelations() {
this.hasMany( Message,{
foreignKey: 'userId',
as: 'messages'
});
}
}
export default User;
import User from './User';Мы видим, что у нас есть циклический импорт, но зависимости нам нужны уже в рантайме. Метод initRelations вызывается во время инициализации. Вот такая схема отлично работает в ES6, но не будет работать в CommonsJs.
class Message extends Base {
static schema = {
id : {
type: DT.UUID,
defaultValue: DT.UUIDV4,
primaryKey: true
},
userId : {
type: DT.UUID,
references: {
model: 'User',
key: 'id'
}
}
};
static initRelations() {
this.belongsTo(User, {
foreignKey: 'userId',
targetKey: 'id',
as: 'user'
});
}
}
export default Message;
Набросал пару отдельных примеров для теста: https://github.com/koorchik/node-import-vs-require
GitHub
GitHub - koorchik/node-import-vs-require: Handling cyclic dependencies with import and require
Handling cyclic dependencies with import and require - koorchik/node-import-vs-require
Forwarded from Иван Акулов про разработку
Наконец-то настоящий кейс-стади CSS-in-JS-библиотек и того, как они влияют на рантайм-производительность: https://calendar.perfplanet.com/2019/the-unseen-performance-costs-of-css-in-js-in-react-apps/
Web Performance Calendar
The unseen performance costs of modern CSS-in-JS libraries in React apps
CSS-in-JS is becoming a popular choice for any new front-end app out there, due to the fact that it offers a better API for developers to work with. Don't get me wrong, I love CSS, but creating a proper CSS architecture is not an easy task. Unfortunately…
Что почитать в празднкики?! :)
Хочу порекомендовать 3 важные книги по программированию. Я часто замечаю, что разработчики знают синтаксис языка, умеют пользоваться либами, но не очень хорошо проектируют приложения, у них возникают сложности в описании бизнес логики, не умеют создавать проекты, которые легко поддерживать в долгосрочной перспективе, создают неудобные абстракции.
Самое удивительное, что это скилл не улучшается с годами опыта, если этому не уделять должного внимания.
Собственно, книги:
1️⃣ Patterns of Enterprise Application Architecture - Martin Fowler.
2️⃣ Clean Architecture - Robert Martin.
3️⃣ Domain Driver Design - Eric Evans.
Первая книга описывает основные паттерны, которые используются во всех фреймворках. Вторая книга описывает многие идеи нашей бекендовой архитектуры, а третья книга рассказывает, как разрабатывать уже сам проект.
С моей точки зрения, наиболее полезными будут "Clean Architecture" и "Domain Driver Design", поскольку это то, что полезно при написании любого нового проекта. В свою очередь, "Patterns of Enterprise Application Architecture" просто позволит вам увидеть определенные паттерны в существующих фреймворках (и полезно, если вы создаете фреймворк).
Для многих DDD было взрывом мозга и переворотом мышления :)
С Новым Годом! 🥳
Хочу порекомендовать 3 важные книги по программированию. Я часто замечаю, что разработчики знают синтаксис языка, умеют пользоваться либами, но не очень хорошо проектируют приложения, у них возникают сложности в описании бизнес логики, не умеют создавать проекты, которые легко поддерживать в долгосрочной перспективе, создают неудобные абстракции.
Самое удивительное, что это скилл не улучшается с годами опыта, если этому не уделять должного внимания.
Собственно, книги:
1️⃣ Patterns of Enterprise Application Architecture - Martin Fowler.
2️⃣ Clean Architecture - Robert Martin.
3️⃣ Domain Driver Design - Eric Evans.
Первая книга описывает основные паттерны, которые используются во всех фреймворках. Вторая книга описывает многие идеи нашей бекендовой архитектуры, а третья книга рассказывает, как разрабатывать уже сам проект.
С моей точки зрения, наиболее полезными будут "Clean Architecture" и "Domain Driver Design", поскольку это то, что полезно при написании любого нового проекта. В свою очередь, "Patterns of Enterprise Application Architecture" просто позволит вам увидеть определенные паттерны в существующих фреймворках (и полезно, если вы создаете фреймворк).
Для многих DDD было взрывом мозга и переворотом мышления :)
С Новым Годом! 🥳
👍1
Forwarded from CatOps
Cindy Sridharan пишет про lsof и его полезные флаги с точки зрения разработчиков.
Тулза действительно полезная, но всё же, если система уже хорошо нагружена, лучше напрямую по
#toolz
Тулза действительно полезная, но всё же, если система уже хорошо нагружена, лучше напрямую по
/proc шариться, чтобы не усугублять.#toolz
Medium
lsof
I’m used to debugging issues with logs or metrics when they are presented to me on a lovely dashboard with an intuitive UI. However, if for…
Simple Made Easy
Для меня простота системы является одним из ключевых признаков качества и хорошей архитектуры. Систему, которую легче понять, проще ментальная модель, прозрачней решения (принятые и которые нужно принимать), почти всегда легче развивать. В то же время, создать простую и стройную систему всегда сложнее, а сложную - проще :). Простые системы часто имеют меньшую вариативность состояний и более предсказуемы. Это касается и тулинга и бизнес-логики. Также это перекликается с идеей, что если ты не знаешь в какой слой разместить кусок кода, то скорее всего у тебя проблемы с архитектурой (ее нет, ее сложно осознать и тд). Но иногда я встречал решения, которые оптимизированы под легкость использования. Можно ли сказать, что легкость использования и простота системы это одно и то же? По ощущениям эти понятия перекликаются, но часто уклон в легкость использования делается, когда системы слишком сложная. А сложность часто продиктована чрезмерной связаностью частей системы, в результате получается комбинаторный эффект от взаимодействий/состояний. Почему я про это все говорю? Мне просто попался хороший доклад на эту тему :). Докладов, которые не про пересказывание документации, а про осмысление подходов не так много. Сам доклад 2012 года, но актуальности он не потерял. Рекомендую.
ССЫЛКА НА ДОКЛАД - https://www.youtube.com/watch?v=oytL881p-nQ
Для меня простота системы является одним из ключевых признаков качества и хорошей архитектуры. Систему, которую легче понять, проще ментальная модель, прозрачней решения (принятые и которые нужно принимать), почти всегда легче развивать. В то же время, создать простую и стройную систему всегда сложнее, а сложную - проще :). Простые системы часто имеют меньшую вариативность состояний и более предсказуемы. Это касается и тулинга и бизнес-логики. Также это перекликается с идеей, что если ты не знаешь в какой слой разместить кусок кода, то скорее всего у тебя проблемы с архитектурой (ее нет, ее сложно осознать и тд). Но иногда я встречал решения, которые оптимизированы под легкость использования. Можно ли сказать, что легкость использования и простота системы это одно и то же? По ощущениям эти понятия перекликаются, но часто уклон в легкость использования делается, когда системы слишком сложная. А сложность часто продиктована чрезмерной связаностью частей системы, в результате получается комбинаторный эффект от взаимодействий/состояний. Почему я про это все говорю? Мне просто попался хороший доклад на эту тему :). Докладов, которые не про пересказывание документации, а про осмысление подходов не так много. Сам доклад 2012 года, но актуальности он не потерял. Рекомендую.
ССЫЛКА НА ДОКЛАД - https://www.youtube.com/watch?v=oytL881p-nQ
Эффективная разработка на NodeJS или чего ждать в этом году
В разработке софта я уже более 15 лет и за этот период удалось поучаствовать в огромном количестве проектов для различных компаний, включая проекты для 5 компаний из списка Fortune 500. Сейчас мы делаем несколько проектов по автоматизации умного дома, платформу для AMG Mercedes, ряд проектов для фарма-компаний, несколько FinTech проектов, различный e-commerce. Большинство проектов написаны на NodeJS.
В прошлом году я сделал ряд докладов про "рабочую архитектуру веб-приложений" (видео можно посмотреть здесь). Получил большое количество позитивных отзывов, но еще больше различных вопросов :). Тема оказалась очень востребована, и в этом году я решил ее развивать. Идея не просто рассказывать про какой-то аспект разработки, а структурировать весь накопленный опыт и поделиться подходами, которые сработали у нас.
Что планируется?
✅Доклады (и промокоды для подписчиков)
В этом году не планирую слишком много выступлений, пока подтвердил 6 докладов. Прошу у организаторов отдельные скидки для подписчиков канала. Все идут на встречу, промокоды и анонсы докладов буду публиковать отдельным постами. Первым будет доклад будет на JavaScript fwdays 14-го марта в Киеве (анонс с промокодом сделаю отдельным постом).
✅Книга
Изначально я думал, что я просто сделаю доклад на тему Эффективная разработка на NodeJS, но когда начал составлять план, то оказалась, что контента на десяток докладов. В итоге, появилась идея все это оформить в книгу. Ко мне подключился Андрей Кучеренко (тот, который сделал jscpd). Книга будет бесплатная, изначально на русском языке, в открытом доступе. Будет отдельный пост, посвященный книге.
✅Посты в телеге
Сейчас я готовлю серию постов по работе с сессиями (JWT, Cookie, Security, force logout и тд). Хочу двигаться блоками. Контент с канала, по сути, станет основой для книги. Ну, и подписчики канала будут первыми получать доступ к содержимому книги и будут иметь возможность повлиять на нее. В целом, идея канала остается прежней - создавать полезный контент для JavaScript разработчиков, хотя сам контент может быть совсем не про JavaScript :).
Мотивация
У канала немало подписчиков и многих я встречаю вживую на конференциях. Это очень круто! Это мотивирует, поскольку сам канал никаких денег не приносит (рекламу за деньги я не публикую). С точки зрения поддержки, лучшим будет, если ты поделишься ссылкой на канал в соц. сетях (если считаешь контент полезным). Возможно в этом году нас будет 3к :)
В разработке софта я уже более 15 лет и за этот период удалось поучаствовать в огромном количестве проектов для различных компаний, включая проекты для 5 компаний из списка Fortune 500. Сейчас мы делаем несколько проектов по автоматизации умного дома, платформу для AMG Mercedes, ряд проектов для фарма-компаний, несколько FinTech проектов, различный e-commerce. Большинство проектов написаны на NodeJS.
В прошлом году я сделал ряд докладов про "рабочую архитектуру веб-приложений" (видео можно посмотреть здесь). Получил большое количество позитивных отзывов, но еще больше различных вопросов :). Тема оказалась очень востребована, и в этом году я решил ее развивать. Идея не просто рассказывать про какой-то аспект разработки, а структурировать весь накопленный опыт и поделиться подходами, которые сработали у нас.
Что планируется?
✅Доклады (и промокоды для подписчиков)
В этом году не планирую слишком много выступлений, пока подтвердил 6 докладов. Прошу у организаторов отдельные скидки для подписчиков канала. Все идут на встречу, промокоды и анонсы докладов буду публиковать отдельным постами. Первым будет доклад будет на JavaScript fwdays 14-го марта в Киеве (анонс с промокодом сделаю отдельным постом).
✅Книга
Изначально я думал, что я просто сделаю доклад на тему Эффективная разработка на NodeJS, но когда начал составлять план, то оказалась, что контента на десяток докладов. В итоге, появилась идея все это оформить в книгу. Ко мне подключился Андрей Кучеренко (тот, который сделал jscpd). Книга будет бесплатная, изначально на русском языке, в открытом доступе. Будет отдельный пост, посвященный книге.
✅Посты в телеге
Сейчас я готовлю серию постов по работе с сессиями (JWT, Cookie, Security, force logout и тд). Хочу двигаться блоками. Контент с канала, по сути, станет основой для книги. Ну, и подписчики канала будут первыми получать доступ к содержимому книги и будут иметь возможность повлиять на нее. В целом, идея канала остается прежней - создавать полезный контент для JavaScript разработчиков, хотя сам контент может быть совсем не про JavaScript :).
Мотивация
У канала немало подписчиков и многих я встречаю вживую на конференциях. Это очень круто! Это мотивирует, поскольку сам канал никаких денег не приносит (рекламу за деньги я не публикую). С точки зрения поддержки, лучшим будет, если ты поделишься ссылкой на канал в соц. сетях (если считаешь контент полезным). Возможно в этом году нас будет 3к :)
Буду на JavaScript fwdays 2020 с докладом "Эффективная разработка NodeJS приложений"
JavaScript fwdays 2020 пройдет 14-го марта в Киеве. Как уже говорил, организаторы, специально для подписчиков канала, дали 15% скидку. Используйте промокод JABASCRIPT.
Я уже сделал ряд докладов про рабочую архитектуру Web приложений, но это все лишь часть пазла эффективной разработки. В этот раз я покажу весь процесс от старта проекта и до запуска его в продакшен. Расскажу, как мы подходим к идеям "12 Factor App", как мы используем докер, обсудим вопросы развертывания окружения, вопросы безопасности, тестирования, обсудим нюансы SDLC и много всего другого.
Реальный опыт часто отличается от теории, поэтому я всегда стараюсь делиться тем, что работает на практике.
Будете на конфе, пишите! Всегда рад пообщаться вживую! 🙂
JavaScript fwdays 2020 пройдет 14-го марта в Киеве. Как уже говорил, организаторы, специально для подписчиков канала, дали 15% скидку. Используйте промокод JABASCRIPT.
Я уже сделал ряд докладов про рабочую архитектуру Web приложений, но это все лишь часть пазла эффективной разработки. В этот раз я покажу весь процесс от старта проекта и до запуска его в продакшен. Расскажу, как мы подходим к идеям "12 Factor App", как мы используем докер, обсудим вопросы развертывания окружения, вопросы безопасности, тестирования, обсудим нюансы SDLC и много всего другого.
Реальный опыт часто отличается от теории, поэтому я всегда стараюсь делиться тем, что работает на практике.
Будете на конфе, пишите! Всегда рад пообщаться вживую! 🙂
Fwdays
JavaScript fwdays'20
Конференція для JavaScript розробників
Уже постил про этот канал и думаю большинство уже там, но сделаю это еще раз. Я знаю как тяжело регулярно писать в канал. Не знаю, как у Сереги это получается, он как робот) Если интересно, как развивается сам JavaScript, то это лучшее место, чтобы следить за этим. Подписывайтесь! Это моя личная рекомендация)
Forwarded from Вебня (Sergey Rubanov)
Несколько дней назад число подписчиков превысило 5000 человек! Это очень мотивирует не останавливаться и постить интересные новости и статьи и дальше. Оказывается, я занимаюсь этим уже более полутора лет 😮. Большое спасибо всем читателям! Если Вам нравится, то делитесь с коллегами и друзьями :)
Напомню, что я принципиально отказываюсь постить здесь всякую рекламу. Если хочется поддержать канал, то это можно сделать на Patreon.
Напомню, что я принципиально отказываюсь постить здесь всякую рекламу. Если хочется поддержать канал, то это можно сделать на Patreon.
Yet another JSON RPC Library
Что может быть проще JSON-RPC? Мы делаем проект по автоматизации умного дома и нам нужна была JSON RPC библиотека, но в результате оказалось, что ничего подходящего в экосистеме NodeJS найти нельзя. Основная проблема в архитектуре этих библиотек.
JSON RPC это один из самых простых вариантов RPC, с минималистичной и простой спекой, протокол не зависит от транспорта. Хотелось найти что-то, что следует этим же идеям.
Нам нужно было:
✅ Независимость от транспорта (WebSockets, MQTT, WebRTC, HTTP etc).
✅ Динамическая регистрация транспортов.
✅ Двунаправленная коммуникация через один канал.
✅ Современный API.
✅ Сервер и клиент, которые могут работать и в браузере.
✅ Простую реализацию, идеально, чтобы ядро без внешних зависимостей.
✅ Простой способ добавлять новые транспорты (все сложные части должны быть абстрагированы).
✅ Простой способ тестировать новые транспорты.
В итоге, более года назад появился Mole-RPC, который решил все эти проблемы. Могу сказать, что выстроить правильные абстракции часто бывает не просто и не всегда получается с первого раза.
Доклад про это на KyivJS - https://www.youtube.com/watch?v=84Y5n32tX5E.
В докладе я рассказал про задачу, показал проблемы ряда популярных JSON RPC библиотек и постарался продемонстрировать, как мы подходим к проектированию и как выстраивать абстракции.
Рекомендую к просмотру всем, кто пишет свои библиотеки 🙂
Что может быть проще JSON-RPC? Мы делаем проект по автоматизации умного дома и нам нужна была JSON RPC библиотека, но в результате оказалось, что ничего подходящего в экосистеме NodeJS найти нельзя. Основная проблема в архитектуре этих библиотек.
JSON RPC это один из самых простых вариантов RPC, с минималистичной и простой спекой, протокол не зависит от транспорта. Хотелось найти что-то, что следует этим же идеям.
Нам нужно было:
✅ Независимость от транспорта (WebSockets, MQTT, WebRTC, HTTP etc).
✅ Динамическая регистрация транспортов.
✅ Двунаправленная коммуникация через один канал.
✅ Современный API.
✅ Сервер и клиент, которые могут работать и в браузере.
✅ Простую реализацию, идеально, чтобы ядро без внешних зависимостей.
✅ Простой способ добавлять новые транспорты (все сложные части должны быть абстрагированы).
✅ Простой способ тестировать новые транспорты.
В итоге, более года назад появился Mole-RPC, который решил все эти проблемы. Могу сказать, что выстроить правильные абстракции часто бывает не просто и не всегда получается с первого раза.
Доклад про это на KyivJS - https://www.youtube.com/watch?v=84Y5n32tX5E.
В докладе я рассказал про задачу, показал проблемы ряда популярных JSON RPC библиотек и постарался продемонстрировать, как мы подходим к проектированию и как выстраивать абстракции.
Рекомендую к просмотру всем, кто пишет свои библиотеки 🙂
Что можно сделать с JSON-RPC?
В продолжение к предыдущему посту, решил рассказать про варианты использования JSON-RPC.
mole-rpc - это сама библиотека.
✅ Реализует протокол JSON-RPC, но ничего не знает про сам транспорт.Транспорт можете выбрать любой из существующих (https://www.npmjs.com/search?q=keywords:mole-transport) или можете написать свой.
✅ Транспорты максимально простые и ничего не знают даже про сам JSON-RPC.
✅ Полностью совместима с JSON RPC v2 (включая уведомления и пакетные запросы).
✅. Без внешних зависимостей.
✅ В версии 1.0 существенно обновил документацию и доработал обработку ошибок.
mole-rpc-autotester
Если пишете свой транспорт, то можно использовать этот автотестер, чтобы протестировать всю основную функциональность. Решил вынесли его в отдельный пакет.
Транспорты и варианты использования
Вы можете использовать Mole-RPC, чтобы устроить коммуникацию поверх чего угодно. Вот ряд интересных примеров:
Отправка задачи в веб-воркер
Допустим, вы хотите отправить вычисления в браузере в веб-воркер. Для этого вы используете postMessage и будете отправлять структуру вида {id, method, params}, а в ответ ждать {id, result}. id нужен, чтобы соотнести запрос и ответ, если будет отправлено несколько задач. Так вот, это по сути и есть JSON RPC. Зачем тогда тратить время на свою реализацию, если можно взять готовое решение. mole-rpc-transport-webworker позволяет это сделать в 2 строчки и обработать еще все граничные кейсы.
Коммуникация микросервисов многие ко многим
Обычно для таких случаев вам нужен message broker. MQTT одно из самых легких и достаточно мощных решений. Организовать JSON RPC общение через MQTT можно при помощи mole-rpc-transport-mqtt. Мы используем это решение в продакшене. В документация я постарался описать все детали.
Обход NAT
Допустим, у вас есть сервис в локальной сети и ему нужно посылать команды из интернета. В таком случае можно подключать не клиент к серверу, а сервер к клиенту. Это тоже реализуемо при помощи mole-rpc-transport-ws. Есть пример на Github.
Подключение браузера к серверу через WebSocket
Для этого можно использовать тот же транспорт mole-rpc-transport-ws. Также есть пример на Github.
Напиши свой транспорт :)
На прошлых выходных, for fun, сделал транспорт, которые позволяет использовать telegram, как канал общения между клиентом и сервером (пока в паблик не выкладывал) :).
Если вы пишите свой транспорт и возникли любые вопросы или пожелания - можете писать мне в личку или чат канала 🙂
В продолжение к предыдущему посту, решил рассказать про варианты использования JSON-RPC.
mole-rpc - это сама библиотека.
✅ Реализует протокол JSON-RPC, но ничего не знает про сам транспорт.Транспорт можете выбрать любой из существующих (https://www.npmjs.com/search?q=keywords:mole-transport) или можете написать свой.
✅ Транспорты максимально простые и ничего не знают даже про сам JSON-RPC.
✅ Полностью совместима с JSON RPC v2 (включая уведомления и пакетные запросы).
✅. Без внешних зависимостей.
✅ В версии 1.0 существенно обновил документацию и доработал обработку ошибок.
mole-rpc-autotester
Если пишете свой транспорт, то можно использовать этот автотестер, чтобы протестировать всю основную функциональность. Решил вынесли его в отдельный пакет.
Транспорты и варианты использования
Вы можете использовать Mole-RPC, чтобы устроить коммуникацию поверх чего угодно. Вот ряд интересных примеров:
Отправка задачи в веб-воркер
Допустим, вы хотите отправить вычисления в браузере в веб-воркер. Для этого вы используете postMessage и будете отправлять структуру вида {id, method, params}, а в ответ ждать {id, result}. id нужен, чтобы соотнести запрос и ответ, если будет отправлено несколько задач. Так вот, это по сути и есть JSON RPC. Зачем тогда тратить время на свою реализацию, если можно взять готовое решение. mole-rpc-transport-webworker позволяет это сделать в 2 строчки и обработать еще все граничные кейсы.
Коммуникация микросервисов многие ко многим
Обычно для таких случаев вам нужен message broker. MQTT одно из самых легких и достаточно мощных решений. Организовать JSON RPC общение через MQTT можно при помощи mole-rpc-transport-mqtt. Мы используем это решение в продакшене. В документация я постарался описать все детали.
Обход NAT
Допустим, у вас есть сервис в локальной сети и ему нужно посылать команды из интернета. В таком случае можно подключать не клиент к серверу, а сервер к клиенту. Это тоже реализуемо при помощи mole-rpc-transport-ws. Есть пример на Github.
Подключение браузера к серверу через WebSocket
Для этого можно использовать тот же транспорт mole-rpc-transport-ws. Также есть пример на Github.
Напиши свой транспорт :)
На прошлых выходных, for fun, сделал транспорт, которые позволяет использовать telegram, как канал общения между клиентом и сервером (пока в паблик не выкладывал) :).
Если вы пишите свой транспорт и возникли любые вопросы или пожелания - можете писать мне в личку или чат канала 🙂
Telegram
Жабаскрипт
Yet another JSON RPC Library
Что может быть проще JSON-RPC? Мы делаем проект по автоматизации умного дома и нам нужна была JSON RPC библиотека, но в результате оказалось, что ничего подходящего в экосистеме NodeJS найти нельзя. Основная проблема в архитектуре…
Что может быть проще JSON-RPC? Мы делаем проект по автоматизации умного дома и нам нужна была JSON RPC библиотека, но в результате оказалось, что ничего подходящего в экосистеме NodeJS найти нельзя. Основная проблема в архитектуре…
"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 приложениях (фронтенд и бекенд).
Эффективная разработка NodeJS приложений
Не так давно я делал доклад на fwdays на тему "Эффективная разработка NodeJS приложений." Это был мой первый онлайн доклад. Впечатления конечно смешанные. Тяжело, когда не видишь аудитории, но зато удобно было показывать код 🙂
Изначально я хотел поделиться идеями и концепциями, к которым нам в WebbyLab удалось прийти за годы разработки на NodeJS. Я наивно полагал, что смогу уместить это в один доклад, но по факту контента оказалось часов на 8. В резульатате, я взял только часть, но все равно вместо 40 минут доклад занял 90 минут. Хорошо, что мой доклад был последним 😁
В докладе:
✅ Прошелся еще раз по архитектуре.
✅ Показал пример чат-бота на этой же архитектуре.
✅ Рассказал про Sequelize - ряд вещей, которых нет в документации. Как использовать ES6 классы, как работать с конфигами (поскольку примеры из доки противоречат правилам "12 factor app"). Немного про транзакции.
✅ Затронул конфиги для фронтенда.
✅ Прошелся по докеризации и основным вопросам, которые часто возникают у разработчиков.
ЗАПИСЬ ДОКЛАДА: https://www.youtube.com/watch?v=g0I2dNwK1BE
PS: Серия постов по 12-ти факторам на подходе. Уже написал половнину. Будет по 1-му посту в день :)
Не так давно я делал доклад на fwdays на тему "Эффективная разработка NodeJS приложений." Это был мой первый онлайн доклад. Впечатления конечно смешанные. Тяжело, когда не видишь аудитории, но зато удобно было показывать код 🙂
Изначально я хотел поделиться идеями и концепциями, к которым нам в WebbyLab удалось прийти за годы разработки на NodeJS. Я наивно полагал, что смогу уместить это в один доклад, но по факту контента оказалось часов на 8. В резульатате, я взял только часть, но все равно вместо 40 минут доклад занял 90 минут. Хорошо, что мой доклад был последним 😁
В докладе:
✅ Прошелся еще раз по архитектуре.
✅ Показал пример чат-бота на этой же архитектуре.
✅ Рассказал про Sequelize - ряд вещей, которых нет в документации. Как использовать ES6 классы, как работать с конфигами (поскольку примеры из доки противоречат правилам "12 factor app"). Немного про транзакции.
✅ Затронул конфиги для фронтенда.
✅ Прошелся по докеризации и основным вопросам, которые часто возникают у разработчиков.
ЗАПИСЬ ДОКЛАДА: https://www.youtube.com/watch?v=g0I2dNwK1BE
PS: Серия постов по 12-ти факторам на подходе. Уже написал половнину. Будет по 1-му посту в день :)
YouTube
Эффективная разработка NodeJS приложений [ru] / Виктор Турский
Видео с онлайн-конференции JavaScript fwdays'20, которая прошла 21 марта 2020 года.
Описание доклада:
За 15 лет в разработке мне удалось принять участие в создании большого количества различных проектов. Я уже сделал ряд докладов о рабочей архитектуру Web…
Описание доклада:
За 15 лет в разработке мне удалось принять участие в создании большого количества различных проектов. Я уже сделал ряд докладов о рабочей архитектуру Web…
6 способов взломать твое JavaScript приложение.
В 2019 я несколько раз выступал с докладом на эту тему. Сейчас готовлю версию на англоязычную онлайн конфу, повод выложить оригинальное видео в канал 🙂
Я заметил, что если людям указать на потенциальный вектор атаки, то они не оценят риск пока ты не запустишь эксплоит, который взломает их приложение и уведет аккаунт. В связи с этим я сделал демо приложение на React + NodeJS и написал 6 эксплоитов, чтобы показать, как различные мелкие недочеты приводят к серьезным уязвимостям.
Все случаи мы находили на реальных проектах и все эксплоты настоящие. На KharkivJS были люди, которые думали, что это все фейк, теперь я показываю код эксплоитов 😁
ВИДЕО С JSFest 2019 (доклад попал в Top-3 лучших докладов конфы) - https://www.youtube.com/watch?v=tBXZRC1f34E
Не сильно грузящее видео, чтобы скрасить времяпровождение во время карантина)
В 2019 я несколько раз выступал с докладом на эту тему. Сейчас готовлю версию на англоязычную онлайн конфу, повод выложить оригинальное видео в канал 🙂
Я заметил, что если людям указать на потенциальный вектор атаки, то они не оценят риск пока ты не запустишь эксплоит, который взломает их приложение и уведет аккаунт. В связи с этим я сделал демо приложение на React + NodeJS и написал 6 эксплоитов, чтобы показать, как различные мелкие недочеты приводят к серьезным уязвимостям.
Все случаи мы находили на реальных проектах и все эксплоты настоящие. На KharkivJS были люди, которые думали, что это все фейк, теперь я показываю код эксплоитов 😁
ВИДЕО С JSFest 2019 (доклад попал в Top-3 лучших докладов конфы) - https://www.youtube.com/watch?v=tBXZRC1f34E
Не сильно грузящее видео, чтобы скрасить времяпровождение во время карантина)
YouTube
6 способов взломать твое JavaScript приложение. Виктор Турский. JS Fest 2019 Spring
The talk from JS Fest conference in Kyiv, Ukraine.
Это будет 6 живых демо взлома. Идея не обсудить сухую теория, а увидеть на практике, как не всегда очевидные ошибки являются источником серьезных уязвимостей в твоем JavScript приложении.
Presentation:…
Это будет 6 живых демо взлома. Идея не обсудить сухую теория, а увидеть на практике, как не всегда очевидные ошибки являются источником серьезных уязвимостей в твоем JavScript приложении.
Presentation:…
NodeJS бойлерплейт: какие платформы поддерживать?
Мы готовим наш бойлерплейт к релизу. И тут возник вопрос по поддержке операционных систем. Решили, что самый правильный способ - это спросить у комьюнити 🙂. Опрос: В основном я пишу бэкенд на NodeJS в:
Мы готовим наш бойлерплейт к релизу. И тут возник вопрос по поддержке операционных систем. Решили, что самый правильный способ - это спросить у комьюнити 🙂. Опрос: В основном я пишу бэкенд на NodeJS в:
Anonymous Poll
33%
Linux
43%
MacOS
4%
Windows с WSL (Windows Subsystem for Linux)
9%
Windows без WSL
12%
Я не пишу бэкенд на NodeJS
Мой доклад занял первое место по результатам голосования (если кто осилит посмотреть, получилось 80 минут, буду рад любому фидбеку):
Forwarded from Tetiana Bukhanova
Вже готовий топ-3 доповідей онлайн-конференції JavaScript fwdays'20 від 21 березня за голосуванням учасників 🤩
1️⃣ @koorchik "Effective NodeJS Application Development"
2️⃣ Олександр Мостовенко " 'Devide et impera' with GraphQL and SSR"
3️⃣ @tshemsedinov "Web Locks API in Node.js and browser"
Посилання на доповіді:
👉 https://www.youtube.com/playlist?list=PLPcgQFk9n9y9jbWCnublMA1D2qbJPLukf
1️⃣ @koorchik "Effective NodeJS Application Development"
2️⃣ Олександр Мостовенко " 'Devide et impera' with GraphQL and SSR"
3️⃣ @tshemsedinov "Web Locks API in Node.js and browser"
Посилання на доповіді:
👉 https://www.youtube.com/playlist?list=PLPcgQFk9n9y9jbWCnublMA1D2qbJPLukf
YouTube
JavaScript fwdays'20 online March 21 - YouTube
Зарелизил Confme 1.0.0 - библиотека для работы со сложными конфигамии в NodeJS приложениях с одновременной поддержкой идей "Twelve-Factor App".
Решил, что библиотека прошла хорошую апробацию и имеет правло получить v1 🙂 Ну, и добавилась поддержка JSON5.
Про причины создания писал тут:
✅ Часть 1 - https://t.me/jabascript/34
✅ Часть 2 - https://t.me/jabascript/35
Ссылка на NPM-пакет - https://www.npmjs.com/package/confme
Ссылка на Github - https://github.com/koorchik/node-confme
Решил, что библиотека прошла хорошую апробацию и имеет правло получить v1 🙂 Ну, и добавилась поддержка JSON5.
Про причины создания писал тут:
✅ Часть 1 - https://t.me/jabascript/34
✅ Часть 2 - https://t.me/jabascript/35
Ссылка на NPM-пакет - https://www.npmjs.com/package/confme
Ссылка на Github - https://github.com/koorchik/node-confme
http://sergeyteplyakov.blogspot.com/2014/06/is-tdd-dead-5.html
Очень классная статья. Помню, как я ждал каждый раз новой части "TDD is Dead". Это был крутой наброс от DHH)
Очень классная статья. Помню, как я ждал каждый раз новой части "TDD is Dead". Это был крутой наброс от DHH)
Blogspot
Is TDD Dead. Часть 5
В то время, как в Виларибо спорят жив ли TDD или мертв, в Вилабаджо думают, а стоит ли компилировать код перед коммитом. На днях вышла зак...
Небольшой апдейт для тех, кто спрашивал про наш бойлерплейт для NodeJS.
Завтра в 8 утра (EEST) у меня доклад на Node.js Global Summit (https://geekle.us/). Это будет доклад про эффективную разработку NodeJS приложений ( https://t.me/jabascript/78 ), но в этот раз на английском. Ну, и все готово для опенсорса нашего бойлерплейта. Планирую сделать это во время доклада. Уже все на Github, осталось только щелкнуть свитчер в настройках 🙂
Сделаю еще отдельный анонс
Завтра в 8 утра (EEST) у меня доклад на Node.js Global Summit (https://geekle.us/). Это будет доклад про эффективную разработку NodeJS приложений ( https://t.me/jabascript/78 ), но в этот раз на английском. Ну, и все готово для опенсорса нашего бойлерплейта. Планирую сделать это во время доклада. Уже все на Github, осталось только щелкнуть свитчер в настройках 🙂
Сделаю еще отдельный анонс
Сделать онлайн трансляцию (или Zoom митинг) типа "Ask Me Anything"? Где я смогу ответить на любые вопросы и по бойлерплейту да и вообще сможете задать любые вопросы.
Anonymous Poll
68%
Делай
32%
Не уверен, что есть в этом необходимость