Не буду спорить что такое «микрофронты», т.к. это придется опускаться на уровень Дяди Боба, и остальной псевдо-науки.
Часто есть смысл в том, чтобы разделить веб-сайт на части так, чтобы можно было их независимо разрабатывать и отдельно деплоить. Часто (но не всегда) удобно разделение репозиториев. И, по определению, требуется чтобы можно было независимо обновлять зависимости. Иначе отдельно деплоить и разрабатывать - не выйдет. А вот эти все вебпаки и rx - не очень про это. Т.е. задачу разрабатывать и деплоить независимо - они не решают.
Мы вот пакуем микрофронты в es6-модули, изолируем через shadow dom, билдим из разных реп, и деплоим независимо. Да, есть оверхед от нескольких реактов, но это осознанный минус, без этого задача разделить разработку - не решается.
Если зависимости есть возможность обновлять одновременно везде - то я не вижу никакого смысла в каких-либо выкрутасах, т.к. стандартный набор инструментов - типа того же vite - умеет все тоже самое, что и этот весь модный тулинг для «микрофронтов».
И мне решительно непонятно зачем нужна module federation, когда есть стандартные es6-модули.
А я и не говорю, что монорепы плохо. Я говорю что если все части юзают одинаковые версии зависимостей и лежат в одной репе - то можно их просто разложить на под-папочки в /src. И получить тоже самое, что дают эти все module federation и nx.
Я считаю, что разделять фронт на части, имеет смысл только если мы хотим разрабатывать эти части разными людьми, или в разном темпе. Это подразумевает, что в разных частях могут получаться разные версии всех зависимостей. Например, какую-нибудь админку заморозили - и там прошлогодний реакт. Также, скорее всего захочется разойтись по отдельным репозиториям. Вероятно - иметь возможность вообще сменить фреймворк.
То, что предлагают nx и webpack - это просто геморройный способ разложить тот же самый монолит по папочкам. Оно не дает никаких приемуществ над монолитным фронтом, порезанным на чанки.
На картридже, вместо обычной ROM, для тайлов была RAM. Там где рисуется 3D - раскладывались уникальные тайлы, и CPU мог в них рисовать. Т.е. получался эдакий нелинейный буфер кадра, куда можно рисовать попиксельно.
public static int Count<T>(this IEnumerable<T> seq) {
switch (seq) {
case Array a: return a.Length;
case ICollection<T> c: return c.Count;
case IReadOnlyCollection<T> c: return c.Count;
// Matches if seq is not null
case IEnumerable<T> _: return seq.Count();
// Discard pattern when seq is null
default: return 0;
}
}
Плохо в null-terminated strings даже не лишние байты и плохие алгоритмы. А то, что одно из 256 значений байта «заныкали». И дальше вот эти все ascii, http, json, регекспы, бесконечный парсинг и сериализация. Только потому что в си последовательность байт где ноль нельзя - отличается от последовательности байт, где ноль - можно.
Мне вот недавно потребовалось сделать на mssql аналог intarray из postgres. Это когда в колонку пишется массив int-ов, и дальше можно фильтровать выражениями типа (1|3)&4&5. И мы расшибли лоб, и так ничего вменяемого и не придумали.
Важна не эта конкретная задача, а то что в mssql если чего-то нет, то это даже сколхозить не из чего: типы данных не добавить, даже массив положить в колонку не во что, и передать в функцию нельзя. T-SQL - просто издевательство, а альтернатив нет. Что-то можно изображать на CLR, но облачные mssql в него не умеют.
И вроде вот они данные, лежат в правильных b-tree как надо, алгоритмы понятно какие надо сделать. Но подлезть не дают.
Обидно даже за нее - т.к. на низком уровне она хорошо сделана.
А зачем вообще тестировать каждую такую форму? Покрыть тестами всякие простые и сложные сочетания компонентов в форме - понятно. Добавить валидацию созданных форм - орфографию, какие-то еще проверки - понятно. Но зачем созданные формы потом тестировать то, что в них может ломаться?
>асинк эвейты это специализированное решение для конкретного кейса, и в рамках этого кейса они лучше генераторов.
Как минимум, await всегда откладывает продолжение на следующий тик, даже если вернуть что-то синхронно. А это было бы полезно, скажем, на беке - чтобы задачу, которая часто может выполниться целиком синхронно (достать все из кешей, например) - не кидать в конец очереди, увеличивая latency, и держа лишнее время все нужные ей ресурсы.
Интересно было бы, кстати, посмотреть на тесты перформанса для этой Effection. А то может оно еще и быстрее работает, чем нативные промисы - как раз за счет этого.
Вот как вот в JS умудрились сделать await-ы хуже, чем получается сделать то же на yield? И зачем вообще этот async делали, если сразу было понятно, что на yield можно запилить любые монадки?
А почему человечество не может придумать какой-то стандарт на ABI, чтобы у был способ запускать бинари на любой ОС? Хотя-бы для серверного софта. Там же вроде многого не надо - сокеты, треды, и файловая система. Веб же вон есть, и там 100500 стандартных API - вплоть до WebGL всяких, и гироскопов на мобилках. А в типичных применениях докера - все сильно проще же. Что я тут не понимаю? Зачем там привязка ко всем накопившимся API ядра того же линукса?
Ну я вот как-то 18 лет работы обхожусь без скриптов на баше. И даже без grep-а и пайпов команд друг в друга. Понятно что в command line вызвать git/openssh/ping/docker/etc - я могу. Но если что-то чуть сложнее - беру просто язык программирования, на котором все остальное в проекте, и на нем делаешь на нём всё что нужно. В человеческих языках, кроме grep-ов по файлам - можно и в API сходить, и сервак выставить, и в БД сходить, и алгоритм какой нетривиальный сделать. Не говоря уже что можно делать функции, циклы и переменные без каких-то нечеловеческих страданий.
Реализации GraphQL для .NET и Java обходят запрос в ширину, по крайней мере насколько я понял. Потому что ну зачем использовать этот хак на промисах и event loop, если можно тоже самое сделать явно, и это будет даже проще.
Шаблон DataLoader - он хорош чтобы батчить тогда, когда у сложно переписать алгоритм, который дёргает какие-нибудь походы в БД или API. Скажем, если бизнес-логика утыкана всякими getUserById, и нет возможности это поменять. Плюс, он вообще возможен только в однопоточной среде (т.е. считай только в ноде).
Отлично эта проблема решилась бы монадами - скажем, если бы в JS, и можно было бы написать свой promise и использовать с ним await. К слову, такое можно сделать на yield-ах.
В общем, как часто бывает - придумали хак, распиарили, и через 10 лет поняли что он вообще был не нужен.
Вариант с JSON - лучше. Потому что с ним понятно как работать, скажем - генерировать из заданных на UI фильтров. Даже если надо будет руками хардкодать запросы в большом количестве - то правильнее будет сделать eDSL, а не впихивать SQL строками в коде.
Честно говоря, непонятно почему сами БД не принимают какой-то машино-читаемый формат, а-ля AST. Потому что в большинстве случаев, запросы к ним тоже генерируют - те же ORM, всякие репортинговые системы а-ля Power BI. И непонятно зачем двум программам разговаривать на языке, придуманном даже не для программистов.
Я в свое штуке делал to be, через оверрайд текущего состояния тупо хард-кодом. Просто поверх мерджился патч, который перешибал часть текущего состояни. И у каждого квадратика и стрелочки - был статус planned и retire. И они рисовались зеленым и красным.
Я как-то делал штуку, которая по метаданным про то же - делает UI, который все это рисует через graphvis. С фильтрами по сервисам и прочему. И можно было, скажем, сделать диаграмму одного сервиса с интеграциями, дальше тыкнуть в какой-нибудь соседний, и сказать «покажи еще его интеграции». Или посмотреть кто юзает определенный топик.
Меня улыбнул кирпичик «postgresql adapter”. Сразу представил типичное бизнес-приложение, написанное по канонам. Обычно там вся логика в дата-леере, а все остальное - красивое, разделенное по слоям, и покрытое тестами - просто перекладывает все между уровнями.
Я вот так и не смог понять про какую такую бизнес-логику все в таких статьях говорят, когда ее отделяют от данных. У меня в бекендах 90% логики - это как данные положить и достать из БД, по дороге денормализуя, кешируя, агрегируя, проверяя права, и т.п. Как отделить такую логику от слоя доступа к данным, не упоров производительность - я за все годы так и не понял. Все статьи про архитектуру строятся на том что это как-то сделать можно, и поэтому для меня выглядят бессмысленными.
Не буду спорить что такое «микрофронты», т.к. это придется опускаться на уровень Дяди Боба, и остальной псевдо-науки.
Часто есть смысл в том, чтобы разделить веб-сайт на части так, чтобы можно было их независимо разрабатывать и отдельно деплоить. Часто (но не всегда) удобно разделение репозиториев. И, по определению, требуется чтобы можно было независимо обновлять зависимости. Иначе отдельно деплоить и разрабатывать - не выйдет. А вот эти все вебпаки и rx - не очень про это. Т.е. задачу разрабатывать и деплоить независимо - они не решают.
Мы вот пакуем микрофронты в es6-модули, изолируем через shadow dom, билдим из разных реп, и деплоим независимо. Да, есть оверхед от нескольких реактов, но это осознанный минус, без этого задача разделить разработку - не решается.
Если зависимости есть возможность обновлять одновременно везде - то я не вижу никакого смысла в каких-либо выкрутасах, т.к. стандартный набор инструментов - типа того же vite - умеет все тоже самое, что и этот весь модный тулинг для «микрофронтов».
И мне решительно непонятно зачем нужна module federation, когда есть стандартные es6-модули.
А я и не говорю, что монорепы плохо. Я говорю что если все части юзают одинаковые версии зависимостей и лежат в одной репе - то можно их просто разложить на под-папочки в /src. И получить тоже самое, что дают эти все module federation и nx.
Я считаю, что разделять фронт на части, имеет смысл только если мы хотим разрабатывать эти части разными людьми, или в разном темпе. Это подразумевает, что в разных частях могут получаться разные версии всех зависимостей. Например, какую-нибудь админку заморозили - и там прошлогодний реакт. Также, скорее всего захочется разойтись по отдельным репозиториям. Вероятно - иметь возможность вообще сменить фреймворк.
То, что предлагают nx и webpack - это просто геморройный способ разложить тот же самый монолит по папочкам. Оно не дает никаких приемуществ над монолитным фронтом, порезанным на чанки.
На картридже, вместо обычной ROM, для тайлов была RAM. Там где рисуется 3D - раскладывались уникальные тайлы, и CPU мог в них рисовать. Т.е. получался эдакий нелинейный буфер кадра, куда можно рисовать попиксельно.
https://elite.bbcelite.com/deep_dives/drawing_vector_graphics_using_nes_tiles.html
Т.е. вот так низя? :(((
Плохо в null-terminated strings даже не лишние байты и плохие алгоритмы. А то, что одно из 256 значений байта «заныкали». И дальше вот эти все ascii, http, json, регекспы, бесконечный парсинг и сериализация. Только потому что в си последовательность байт где ноль нельзя - отличается от последовательности байт, где ноль - можно.
Мне вот недавно потребовалось сделать на mssql аналог intarray из postgres. Это когда в колонку пишется массив int-ов, и дальше можно фильтровать выражениями типа (1|3)&4&5. И мы расшибли лоб, и так ничего вменяемого и не придумали.
Важна не эта конкретная задача, а то что в mssql если чего-то нет, то это даже сколхозить не из чего: типы данных не добавить, даже массив положить в колонку не во что, и передать в функцию нельзя. T-SQL - просто издевательство, а альтернатив нет. Что-то можно изображать на CLR, но облачные mssql в него не умеют.
И вроде вот они данные, лежат в правильных b-tree как надо, алгоритмы понятно какие надо сделать. Но подлезть не дают.
Обидно даже за нее - т.к. на низком уровне она хорошо сделана.
А зачем вообще тестировать каждую такую форму? Покрыть тестами всякие простые и сложные сочетания компонентов в форме - понятно. Добавить валидацию созданных форм - орфографию, какие-то еще проверки - понятно. Но зачем созданные формы потом тестировать то, что в них может ломаться?
>асинк эвейты это специализированное решение для конкретного кейса, и в рамках этого кейса они лучше генераторов.
Как минимум, await всегда откладывает продолжение на следующий тик, даже если вернуть что-то синхронно. А это было бы полезно, скажем, на беке - чтобы задачу, которая часто может выполниться целиком синхронно (достать все из кешей, например) - не кидать в конец очереди, увеличивая latency, и держа лишнее время все нужные ей ресурсы.
Интересно было бы, кстати, посмотреть на тесты перформанса для этой Effection. А то может оно еще и быстрее работает, чем нативные промисы - как раз за счет этого.
Вот как вот в JS умудрились сделать await-ы хуже, чем получается сделать то же на yield? И зачем вообще этот async делали, если сразу было понятно, что на yield можно запилить любые монадки?
А почему человечество не может придумать какой-то стандарт на ABI, чтобы у был способ запускать бинари на любой ОС? Хотя-бы для серверного софта. Там же вроде многого не надо - сокеты, треды, и файловая система. Веб же вон есть, и там 100500 стандартных API - вплоть до WebGL всяких, и гироскопов на мобилках. А в типичных применениях докера - все сильно проще же. Что я тут не понимаю? Зачем там привязка ко всем накопившимся API ядра того же линукса?
Ну я вот как-то 18 лет работы обхожусь без скриптов на баше. И даже без grep-а и пайпов команд друг в друга. Понятно что в command line вызвать git/openssh/ping/docker/etc - я могу. Но если что-то чуть сложнее - беру просто язык программирования, на котором все остальное в проекте, и на нем делаешь на нём всё что нужно. В человеческих языках, кроме grep-ов по файлам - можно и в API сходить, и сервак выставить, и в БД сходить, и алгоритм какой нетривиальный сделать. Не говоря уже что можно делать функции, циклы и переменные без каких-то нечеловеческих страданий.
А зачем знать bash?
Реализации GraphQL для .NET и Java обходят запрос в ширину, по крайней мере насколько я понял. Потому что ну зачем использовать этот хак на промисах и event loop, если можно тоже самое сделать явно, и это будет даже проще.
Шаблон DataLoader - он хорош чтобы батчить тогда, когда у сложно переписать алгоритм, который дёргает какие-нибудь походы в БД или API. Скажем, если бизнес-логика утыкана всякими getUserById, и нет возможности это поменять. Плюс, он вообще возможен только в однопоточной среде (т.е. считай только в ноде).
Отлично эта проблема решилась бы монадами - скажем, если бы в JS, и можно было бы написать свой promise и использовать с ним await. К слову, такое можно сделать на yield-ах.
В общем, как часто бывает - придумали хак, распиарили, и через 10 лет поняли что он вообще был не нужен.
Вариант с JSON - лучше. Потому что с ним понятно как работать, скажем - генерировать из заданных на UI фильтров. Даже если надо будет руками хардкодать запросы в большом количестве - то правильнее будет сделать eDSL, а не впихивать SQL строками в коде.
Честно говоря, непонятно почему сами БД не принимают какой-то машино-читаемый формат, а-ля AST. Потому что в большинстве случаев, запросы к ним тоже генерируют - те же ORM, всякие репортинговые системы а-ля Power BI. И непонятно зачем двум программам разговаривать на языке, придуманном даже не для программистов.
У одной строчки - 27 состояний, лезет а 5 бит. Делаем табличку на 27 значений, пихаем в 3 числа по 5 бит, получаем 15 бит.
Я в свое штуке делал to be, через оверрайд текущего состояния тупо хард-кодом. Просто поверх мерджился патч, который перешибал часть текущего состояни. И у каждого квадратика и стрелочки - был статус planned и retire. И они рисовались зеленым и красным.
Я как-то делал штуку, которая по метаданным про то же - делает UI, который все это рисует через graphvis. С фильтрами по сервисам и прочему. И можно было, скажем, сделать диаграмму одного сервиса с интеграциями, дальше тыкнуть в какой-нибудь соседний, и сказать «покажи еще его интеграции». Или посмотреть кто юзает определенный топик.
Меня улыбнул кирпичик «postgresql adapter”. Сразу представил типичное бизнес-приложение, написанное по канонам. Обычно там вся логика в дата-леере, а все остальное - красивое, разделенное по слоям, и покрытое тестами - просто перекладывает все между уровнями.
Я вот так и не смог понять про какую такую бизнес-логику все в таких статьях говорят, когда ее отделяют от данных. У меня в бекендах 90% логики - это как данные положить и достать из БД, по дороге денормализуя, кешируя, агрегируя, проверяя права, и т.п. Как отделить такую логику от слоя доступа к данным, не упоров производительность - я за все годы так и не понял. Все статьи про архитектуру строятся на том что это как-то сделать можно, и поэтому для меня выглядят бессмысленными.
А версии реакта и других зависимостей - синхронизированы между приложениями и общими пакетами, или могут быть разными?