Интересный подход. Только лучше в начале статьи оговориться что метрика считается как "чем ниже, тем лучше". Ибо сначала идёт пример с оценкой фильма где "чем выше, тем лучше" и потом немного попадаешь в ступор.
Несколько микросервисов не могут стучаться в одну базу данных по определению. Микросервисы делят одну большую базу на несколько штук. Микросервисы позволяют хранить часть данных в очереди сообщений вместо базы.
Тут была проблема в постановке задачи. Микросервисы появились, потому что кто-то захотел поддерживать миллионы пользователей и миллиарды запросов. Возможно так было сделано для того, что бы отточить навыки работы с этими технологиями.
Я вот сейчас считаю киллер-технологией для мелких проектов supabase, здесь ты делаешь фронт который ходит напрямую в базу. А бэкэнда как такового нет. Единственное что придется писать больше кода на sql, что бы делать то что раньше делалось на бэке (авторизация и валидация) и если появиться альтернатива sql (например будет больше возможностей у plv8) прототипы будут делаться только так. А когда увидят на дашбордах, что база не справляется будут к ней дописывать микросервисы.
Я уверен в видео много здравых мыслей, только оно уж очень растянуто. Вот если бы его сократить раз в 10, его бы посмотрело в 100 раз больше людей. То же касается и других видео из серии "препарируем", многим было бы интересно узнать об архитектуре разных фреймворков, но смотреть несколько часов неструктурированной информации как-то не очень.
Количество запросов в Гугле не показатель популярности. В свое время по mysql было написано большое количество туториалов, новички гуглят эти статьи и поднимают статистику, прошаренные ребята (использующие pgsql) гуглят меньше.
Куда репрезентабельнее было бы количество вакансий, где требуется знание pgsql. Я полагаю что в вакансиях слова MsSQL, Oracle и PostgreSQL будут встречаться на порядок чаще чем MySQL.
Когда появился Blazor и начал расти интерес к WebAssembly оказалось, что Wasm и Blazor работает в разы лучше чем на Chrome. Сейчас в хроме ситуация лучше. Видно что конкуренция ведет к развитию.
Лисичке нужны киллер-фичи. Например, встроенные почтовый клиент в браузер, стал для меня киллер-фичей оперы. После их перехода на движок chromium, я не имел ни одном причины сидеть на ней и почему-то перешел на Firefox.
На данный момент я чувствую необходимость фичи по удобной работе со вкладками и превращению их в некое подобие закладок (список для чтения и заметки). Плюс удобные штуки для их сортировки. Сейчас закладки во всех браузерах мне не нравятся. Это очень хорошо может дополнить недавно добавленную синхронизацию между компом и телефоном.
Почему такие вещи как создание шаблонного кода или же выполнение команд должны реализовываться как nx-плагины?
Приведенные вами примеры, можно прекрасно реализовать как скрипты на ts-node или deno, тем самым снизить зависимость от nx. Потому что при обновлении версии nx или же отказе от него все это может сломаться и его долго и больно надо чинить. А если это скрипт на deno то достаточно просто скопировать ts-файл в другой проект и даже не надо будет устанавливать пакеты, так как можно использовать импорты с url на конкретную версию.
Если я правильно понимаю, ошибка вызвана несовместимостью библиотек после обновления. И правильные шаги для этого должны быть такими:
Использовать lock-file и pnpm. (что бы все было детерминировано и каждая библиотека имела доступ к своим версиям зависимостей)
Проверить совместимость библиотек друг с другом (peer dependencies)
Отказаться от обновления на React 18, до того как ваша библиотека станет его поддерживать.
А вот это решение, которое глотает ошибки, может привести к трудноуловимым багам.
P.S. Использовать pre-commit хуки это плохая практика (плохо сочетается с IDE, можно тупо не застейджить фикс и закоммитить без фикса). Лучше сделайте нормальный CI + squash коммитов при мердже.
P.P.S. Ваш скрипт написан на баше (в котором, сами признаете, что не эксперт), хотя вы пишете на TS. В чем проблема написать скрипт на deno или ts-node (хотя бы ради кросплатформенности).
Так экспериментируйте сами, зачем выкладывать это на хабр, что бы другие люди принимали за чистую монету? Ах, да, что бы потом рекламу своих курсов разместить.
О Господи, мало того что Яндекс практикум, так ещё и по 1С. Я конечно понимаю, что новичкам сейчас туго, но пытаться построить карьеру в 1C когда ты не умеешь ни в программирование, ни в экономику, как-то очень сказачно. Курсы по питону на этом фоне не выглядят такими безнадежными.
Вот лично для меня, статья выглядит как какая-то поделка новичка. Если вы хотите раскрыть довольно сложную тему, то нужно показывать куски кода близкие к production-ready. То есть должен быть ts, мало-мальски адекватный код стаил, продуманная система типов. Про паттерны порождения объектов и di написано много статей как и на многие другие темы. А вот качественных шаблонов для той или иной задачи единицы, как раз их я и ожидал прочитав заголовок данной статьи.
Интересный подход. Только лучше в начале статьи оговориться что метрика считается как "чем ниже, тем лучше". Ибо сначала идёт пример с оценкой фильма где "чем выше, тем лучше" и потом немного попадаешь в ступор.
Несколько микросервисов не могут стучаться в одну базу данных по определению. Микросервисы делят одну большую базу на несколько штук. Микросервисы позволяют хранить часть данных в очереди сообщений вместо базы.
Это было бы здорово, но мы даже от am/pm сейчас отказаться не можем.
А так было бы круто перейти на планковскую длину, время и так далее... И сделать положительный заряд у электрона!
Тут была проблема в постановке задачи. Микросервисы появились, потому что кто-то захотел поддерживать миллионы пользователей и миллиарды запросов. Возможно так было сделано для того, что бы отточить навыки работы с этими технологиями.
Я вот сейчас считаю киллер-технологией для мелких проектов supabase, здесь ты делаешь фронт который ходит напрямую в базу. А бэкэнда как такового нет. Единственное что придется писать больше кода на sql, что бы делать то что раньше делалось на бэке (авторизация и валидация) и если появиться альтернатива sql (например будет больше возможностей у plv8) прототипы будут делаться только так. А когда увидят на дашбордах, что база не справляется будут к ней дописывать микросервисы.
Я уверен в видео много здравых мыслей, только оно уж очень растянуто. Вот если бы его сократить раз в 10, его бы посмотрело в 100 раз больше людей. То же касается и других видео из серии "препарируем", многим было бы интересно узнать об архитектуре разных фреймворков, но смотреть несколько часов неструктурированной информации как-то не очень.
PrimeVue, PrimeReact, PrimeNg наверное лучшее, что есть для меня на данный момент.
А ваша демка у меня на телефоне не открывается, позор.
ts-patch + ts-runtime-checks
НодЯЭс?
Количество запросов в Гугле не показатель популярности. В свое время по mysql было написано большое количество туториалов, новички гуглят эти статьи и поднимают статистику, прошаренные ребята (использующие pgsql) гуглят меньше.
Куда репрезентабельнее было бы количество вакансий, где требуется знание pgsql. Я полагаю что в вакансиях слова MsSQL, Oracle и PostgreSQL будут встречаться на порядок чаще чем MySQL.
Вместо Prettier, лучше использовать Prettier ESLint
https://marketplace.visualstudio.com/items?itemName=rvest.vs-code-prettier-eslint
Это тот случай когда регуляторы сделали только хуже. Да следите за мной, мне плевать, но не перекрывайте мне контент этим дерьмом.
JSX вместо tree и я попробую $mol.
Я пробовал onetab, интересно, но не покрывает мои требования. Может быть вы можете подсказать, что-то ещё?
Когда появился Blazor и начал расти интерес к WebAssembly оказалось, что Wasm и Blazor работает в разы лучше чем на Chrome. Сейчас в хроме ситуация лучше. Видно что конкуренция ведет к развитию.
Лисичке нужны киллер-фичи. Например, встроенные почтовый клиент в браузер, стал для меня киллер-фичей оперы. После их перехода на движок chromium, я не имел ни одном причины сидеть на ней и почему-то перешел на Firefox.
На данный момент я чувствую необходимость фичи по удобной работе со вкладками и превращению их в некое подобие закладок (список для чтения и заметки). Плюс удобные штуки для их сортировки. Сейчас закладки во всех браузерах мне не нравятся. Это очень хорошо может дополнить недавно добавленную синхронизацию между компом и телефоном.
Почему такие вещи как создание шаблонного кода или же выполнение команд должны реализовываться как nx-плагины?
Приведенные вами примеры, можно прекрасно реализовать как скрипты на ts-node или deno, тем самым снизить зависимость от nx. Потому что при обновлении версии nx или же отказе от него все это может сломаться и его долго и больно надо чинить. А если это скрипт на deno то достаточно просто скопировать ts-файл в другой проект и даже не надо будет устанавливать пакеты, так как можно использовать импорты с url на конкретную версию.
Ничего не понял, но очень интересно.
Если я правильно понимаю, ошибка вызвана несовместимостью библиотек после обновления. И правильные шаги для этого должны быть такими:
Использовать lock-file и pnpm. (что бы все было детерминировано и каждая библиотека имела доступ к своим версиям зависимостей)
Проверить совместимость библиотек друг с другом (peer dependencies)
Отказаться от обновления на React 18, до того как ваша библиотека станет его поддерживать.
А вот это решение, которое глотает ошибки, может привести к трудноуловимым багам.
P.S. Использовать pre-commit хуки это плохая практика (плохо сочетается с IDE, можно тупо не застейджить фикс и закоммитить без фикса). Лучше сделайте нормальный CI + squash коммитов при мердже.
P.P.S. Ваш скрипт написан на баше (в котором, сами признаете, что не эксперт), хотя вы пишете на TS. В чем проблема написать скрипт на deno или ts-node (хотя бы ради кросплатформенности).
Vue 3 вышел в сентябре 2020. Сейчас август 2023. Прошло не 18 месяцев, а почти 36.
Вы если списываете, то хотя бы перечитывайте.
Так экспериментируйте сами, зачем выкладывать это на хабр, что бы другие люди принимали за чистую монету? Ах, да, что бы потом рекламу своих курсов разместить.
О Господи, мало того что Яндекс практикум, так ещё и по 1С. Я конечно понимаю, что новичкам сейчас туго, но пытаться построить карьеру в 1C когда ты не умеешь ни в программирование, ни в экономику, как-то очень сказачно. Курсы по питону на этом фоне не выглядят такими безнадежными.
Вот лично для меня, статья выглядит как какая-то поделка новичка. Если вы хотите раскрыть довольно сложную тему, то нужно показывать куски кода близкие к production-ready. То есть должен быть ts, мало-мальски адекватный код стаил, продуманная система типов. Про паттерны порождения объектов и di написано много статей как и на многие другие темы. А вот качественных шаблонов для той или иной задачи единицы, как раз их я и ожидал прочитав заголовок данной статьи.
За export default существует отдельный котел в аду.