🗽vite - будущее уже здесь
Сегодня знаменательный день, мы переехали с webpack5 на vite. Знаменательный он потому, что локальная разработка стала такой-же быстрой, как лет 8 назад, когда я делал простенькие сайтики на чистом html, css и немного js, а галповского лайврелоада хватало с головой.
Для тех кто не в курсе, Vite - это очередной бандлер, но бандлер следующего поколения и сервер в одной туле. Он очень и очень шустрый, как сказал мой коллега - "tested, can confirm, fast as fuck", и супер простой в конфигурации. Если сравнивать webpack и vite, то это как жигуль и тесла роадстер на автопилоте, на тесле - сел и поехал с кайфом, а жигуль сколько не переберай, сильно быстрее он от этого не станет.
Vite настолько быстрый потому, что под капотом использует несколько бандлеров. Во время локальной разработки для JS/TS используется esbuild, для всего остального используется rollup. Для прод билда используется только rollup и terser(для минификации), но начиная с версии 2.6.0 esbuild заменит terser. Как вы уже могли догадаться, вся магия скорости кроется в esbuild, т.к. этот js/ts бандлер написан на go и дает 10-100 кратный прирост скорости по сравнению с другими бандлерами, и в 20-40 раз быстрее терсера (правда компрессия хуже на 1-2%, но это не так критично, не так ли?)! Но дело не только в этом, Hot Module Replacement(HMR) так же безумно шустрый, так как vite использует последний JS и натинвые ES-модули, т.е. esbuild просто транспалит ваш TS в JS и все, а дальше vite грузит все файлы в браузер по http2 и когда что-то меняется в файле, то транспайлтся, грузится и заменяется только этот файл. В то время как остальные бандлеры в браузер грузиться уже сбилженые бандлы, что значительно все замедляет и усложняет HMR...
https://deveasy.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F03697b91-719a-4b4b-a312-bc0525721b01%2FUntitled.png?table=block&id=dd187f65-7e43-45f1-a967-25eeb62f2628
Процесс миграции в первом коменте...
Читать в ноушен: https://bit.ly/3lTicvd
#vite #frontend #tools
Сегодня знаменательный день, мы переехали с webpack5 на vite. Знаменательный он потому, что локальная разработка стала такой-же быстрой, как лет 8 назад, когда я делал простенькие сайтики на чистом html, css и немного js, а галповского лайврелоада хватало с головой.
Для тех кто не в курсе, Vite - это очередной бандлер, но бандлер следующего поколения и сервер в одной туле. Он очень и очень шустрый, как сказал мой коллега - "tested, can confirm, fast as fuck", и супер простой в конфигурации. Если сравнивать webpack и vite, то это как жигуль и тесла роадстер на автопилоте, на тесле - сел и поехал с кайфом, а жигуль сколько не переберай, сильно быстрее он от этого не станет.
Vite настолько быстрый потому, что под капотом использует несколько бандлеров. Во время локальной разработки для JS/TS используется esbuild, для всего остального используется rollup. Для прод билда используется только rollup и terser(для минификации), но начиная с версии 2.6.0 esbuild заменит terser. Как вы уже могли догадаться, вся магия скорости кроется в esbuild, т.к. этот js/ts бандлер написан на go и дает 10-100 кратный прирост скорости по сравнению с другими бандлерами, и в 20-40 раз быстрее терсера (правда компрессия хуже на 1-2%, но это не так критично, не так ли?)! Но дело не только в этом, Hot Module Replacement(HMR) так же безумно шустрый, так как vite использует последний JS и натинвые ES-модули, т.е. esbuild просто транспалит ваш TS в JS и все, а дальше vite грузит все файлы в браузер по http2 и когда что-то меняется в файле, то транспайлтся, грузится и заменяется только этот файл. В то время как остальные бандлеры в браузер грузиться уже сбилженые бандлы, что значительно все замедляет и усложняет HMR...
https://deveasy.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F03697b91-719a-4b4b-a312-bc0525721b01%2FUntitled.png?table=block&id=dd187f65-7e43-45f1-a967-25eeb62f2628
Процесс миграции в первом коменте...
Читать в ноушен: https://bit.ly/3lTicvd
#vite #frontend #tools
🤓1
🦾 local env на стиройдах
Как я уже упоминал несколько раз, весь наш бэкенд построен на микросервисах. Есть сервисы-апишки - общаются с фронтом, сервисы-рантаймы - ранают скилы/экшены/проекты и интегрируются с alexa/google assistant/voiceflow(наш кастомный ассистент)/прочими платформами, ну и куча других сервисов с джобами, nlp/nlu, доступа к данным и тд. На каждую платформу приходится как минимум по 2 сервиса (апишка и рантайм), следовательно кол-во сервисов растет с добавлением новых платформ в проект. Все это работает прекрасно и позволяет нам скейлится по мере необходимости и расширять платформы не боясь, что интеграция с существующей платформой отвалится.
Но во всей этой красоте есть один большой нюанс - local env.
- Во-первых, засетапить такой зоопарк локально достаточно сложно:
- 3 базы данных
- куча сервисов
- практически все сервисы общаются с сервисами доступа к данным и кэшем
- сервисы апишки/рантаймы для платформ (alexa/google/...) общаются с апишкой/рантаймом voiceflow (что бы конвертнуть проект платформы в проект voiceflow или запустить проект у нас в туле, без коммуникации с платформой)
- фронт общается с апишками-платформ, дженерик апишкой, ну и парочку других сервисов
Другими словами сервисы и фронт между собой связанны, и в env-переменных нужно ссылаться друг на друга. Новые члены команды обычно страдали первые пару дней, что бы все это запустить...
- Во вторых, наш фронт сам по себе достаточно тяжелый и dev-server хавает много ресурсов. А если запустить весь этот зоопарк сервисов, то macbook с 16 гигами не справляется и разрабатывать практически невозможно, и не важно что сервисы на ноде и сами по себе не ресурсоёмкие, но их много...
- Ну и в третьих, не совсем относится к local env, но развернуть тестовый env в облаке(где одни сервисы юзают код из своих мастер веток, а другие - из кастомных) - геморно и требует совместной работы с девопсами. Поэтому мы юзали костыль в виде нескольких staging (staging-a, staging-b, etc) веток в каждой репе, и пушили туда свои ветки и проверяли в облаке 😂.
Около годна назад наша инфра-тима решила помочь нам с этим и написала cli-тулу, которая решала первую и третью проблемы, а так же частично вторую. Эта тула может одной командой склонить все наши репы(сервисы, фронт, базы, либы). Создать локальные env файлы и проставить нужные env-переменные, что бы залинковать сервисы и быза. Ну и естественно запустить весь этот зоопарк локально. Есть и набор снипетов, что бы ранать только часть сервисов, например только те сервисы которые необходимы для работы фронта, что позволяло экономить ресурсы. Тула также позволяет одной командой создать env в облаке, все сервисы разворачиваются и ты получаешь урл на новый env. По дефолту сервисы юзают мастер ветки, но есть команда, что бы переключить любой сервис на нужную ветку. Под капотом тула написана на Go, юзает докер и кубик.
В целом на этом можно было и закончить, но проблема с ресурсами не была решена для всех. Некоторым ребятам в команде (в основном бэкендерам) нужно ранать все сервисы, ибо большинство новых фич затрагивают все платформы. Да и к тому же сервисов становится все больше, докер хавает все больше, комп греется все больше, кернел тормозит процесс все больше, в итоге через пару часов активной разработки летом я вырубал мак и клал его в морозилку, что бы усмирить кернел таск, как вам лайфхак?
Продолжение в первом коменте...
Читать в ноушен: https://bit.ly/3Dq9XhX
#tools #longread
Как я уже упоминал несколько раз, весь наш бэкенд построен на микросервисах. Есть сервисы-апишки - общаются с фронтом, сервисы-рантаймы - ранают скилы/экшены/проекты и интегрируются с alexa/google assistant/voiceflow(наш кастомный ассистент)/прочими платформами, ну и куча других сервисов с джобами, nlp/nlu, доступа к данным и тд. На каждую платформу приходится как минимум по 2 сервиса (апишка и рантайм), следовательно кол-во сервисов растет с добавлением новых платформ в проект. Все это работает прекрасно и позволяет нам скейлится по мере необходимости и расширять платформы не боясь, что интеграция с существующей платформой отвалится.
Но во всей этой красоте есть один большой нюанс - local env.
- Во-первых, засетапить такой зоопарк локально достаточно сложно:
- 3 базы данных
- куча сервисов
- практически все сервисы общаются с сервисами доступа к данным и кэшем
- сервисы апишки/рантаймы для платформ (alexa/google/...) общаются с апишкой/рантаймом voiceflow (что бы конвертнуть проект платформы в проект voiceflow или запустить проект у нас в туле, без коммуникации с платформой)
- фронт общается с апишками-платформ, дженерик апишкой, ну и парочку других сервисов
Другими словами сервисы и фронт между собой связанны, и в env-переменных нужно ссылаться друг на друга. Новые члены команды обычно страдали первые пару дней, что бы все это запустить...
- Во вторых, наш фронт сам по себе достаточно тяжелый и dev-server хавает много ресурсов. А если запустить весь этот зоопарк сервисов, то macbook с 16 гигами не справляется и разрабатывать практически невозможно, и не важно что сервисы на ноде и сами по себе не ресурсоёмкие, но их много...
- Ну и в третьих, не совсем относится к local env, но развернуть тестовый env в облаке(где одни сервисы юзают код из своих мастер веток, а другие - из кастомных) - геморно и требует совместной работы с девопсами. Поэтому мы юзали костыль в виде нескольких staging (staging-a, staging-b, etc) веток в каждой репе, и пушили туда свои ветки и проверяли в облаке 😂.
Около годна назад наша инфра-тима решила помочь нам с этим и написала cli-тулу, которая решала первую и третью проблемы, а так же частично вторую. Эта тула может одной командой склонить все наши репы(сервисы, фронт, базы, либы). Создать локальные env файлы и проставить нужные env-переменные, что бы залинковать сервисы и быза. Ну и естественно запустить весь этот зоопарк локально. Есть и набор снипетов, что бы ранать только часть сервисов, например только те сервисы которые необходимы для работы фронта, что позволяло экономить ресурсы. Тула также позволяет одной командой создать env в облаке, все сервисы разворачиваются и ты получаешь урл на новый env. По дефолту сервисы юзают мастер ветки, но есть команда, что бы переключить любой сервис на нужную ветку. Под капотом тула написана на Go, юзает докер и кубик.
В целом на этом можно было и закончить, но проблема с ресурсами не была решена для всех. Некоторым ребятам в команде (в основном бэкендерам) нужно ранать все сервисы, ибо большинство новых фич затрагивают все платформы. Да и к тому же сервисов становится все больше, докер хавает все больше, комп греется все больше, кернел тормозит процесс все больше, в итоге через пару часов активной разработки летом я вырубал мак и клал его в морозилку, что бы усмирить кернел таск, как вам лайфхак?
Продолжение в первом коменте...
Читать в ноушен: https://bit.ly/3Dq9XhX
#tools #longread
🤓1