По практическим рекомендациям, если ваш API будет использоваться из браузера.
Пункт 2, если у вас API не для раздачи вэбстраниц, используйте POST метод или вэбсокеты или другие методы. К остальным прибегайте когда это требует браузер.
Пункт 3. Если у вас снова не раздача вэбстраниц, то указанный стандарт не для вас.
По пункту 4 все больше кажется что речь не про раздачу вэбстраниц.
Пункт 11. Убедитесь, что кэшируете в нужном месте, хотя ИИ агент легко объяснит пользователю как сбросить кэш, но осадочек останется
Пункт 12. Ага... вы все таки решили поиграть с браузером в игры, подбери нужный http метод, ну вот, теперь выбирайте POST или вэбсокет😉
Пункт 16, это ISO формат, если вы его не узнали.
Пункт 17. Ну это будет прям не просто.... Лучше используйте ту, что возможно. Не надо имитировать курсоры там, где их нет.
Пункт 18. Используйте HTTP как траспорт, не надо искать куда бы ему в красивое место записать, что-то что кажется вам подходящим. Ну явно же не вэбстраницы раздаёте.
Пункт 19. Вы решили, что ваш API не используется в браузере, обмазались HTTP методами, всё красиво, ещё и кэширующие заголовки трогали, но у клиента стоит кэшируюший DPI на выходе. Вот вам и пу-пу-пу.
На последок, любой API с документацией, лучше чем "стандартный REST", который кажется более понятными, но без документации.
Не рассматривался ли вариант, когда вы накрываете все свои сервисы Auth сервисом, через который проходят все запросы, а остальные сервисы у Auth запрашивают только нужные им роли для обработки запроса. Сервисы между собой просто через SSH общаются. Схема в стиле: Пользователь отправляет подписанный запрос, Auth сервис проверяет что подпись правильная и отправляет его дальше, уже внутренние сервисы запрашивают нужные роли этого пользователя у Auth сервиса им уже ничего проверять не надо, логику Auth тоже размазывать не надо. Надоест JWT просто Auth переедет на что-то более молодёжное, остальные сервисы просто будут смотреть на нужные им роли. Для миграции сервисов на новую версию Auth, можно или всем сразу или временно поддерживать несколько версий. И все проблемы с отзывом ролей сразу пропадают. В случае обмазывания кэшом где либо, при изменении данные из кэша просто удалять, (можно и заменить, но зачем эти сложности).
$mol странный предмет, комменты есть, но либы нет) Если этот коммент был про https://www.npmjs.com/package/mol_fiber, не думаю, что оно для кого либо актуально.
Обычно мнение о useCallback делится на до и после коммита с оборачиванием компонентов для какой нибудь виртуализации. Чтоб намекнуть людям, что такая проблема как-бы есть, сейчас допиливают React Compiler который автоматически будет это делать.
Проблема в том, что статья содержит неверную информацию.
Во первых: А асинхронный код может выполняться параллельно с другими задачами - это не так. Асинхронный код выполняется в один поток. Во вторых: Event Loop обеспечивает параллелизм в смысле возможности выполнять несколько операций одновременно, не блокируя основной поток выполнения. - Event loop тоже работает в один поток, любая тяжелая операция блокирует основной поток выполнения.
На это нам намекает хук renderHook для тестирования хуков. Иначе говоря, наш хук привязан к "экосистеме" компонента.
Это же просто метод для тестирования хуков, после "исправления" просто добавилась другая зависимость. Хуки для того и вводили, чтоб избавится от миксинов и хоков. А тут вместо обычного, понятно всем компонента используется connect чтоб соединить всё, так ещё и надо идти смотреть его доку, чтоб понять, что тут происходит. Из плюсов, читаемость вещь субъективная, процесс тестирование чет особо проще то и не стал это вот точно, хуки прекрасно повторно используются и без этих костылей. (Картинка, раньше было лучше) Опять таки, что делать в этом "магическом" подходе, с хуками которые нужны для UI. Или почему не выбрать redux-saga оно тут больше подходит в плане декомпозиции. Немного истории: https://legacy.reactjs.org/docs/hooks-intro.html#motivation
А если смотреть на REST API, как на спеку, а HTTP как на траспортный протокол. И не иметь интимностей с особенностями кэширования и проксирования разных HTTP методов.
Когда лучше не использовать GET - если ответ меняется чаще чем раз в день.
PUT и POST для создания/обновления записи в базе, нужно использовать если пользователи вам платят за вызовы API.
Исключительно моё мнение. Возможно нужно UX специалистов добавить в команду. Они умеют делать красиво. А то сейчас все товары имеют капинские подписи. ( "Куртка утеплённая...", "Рубашка белая..."). Как-то или описание поверх картинки делать, ну или внизу хотя бы бренд писать, можно места больше под надпись сделать.
Ещё интересно, почему картинки всегда грузятся долго, будто забыли включить кеширование?
Ответ исключительно про велосипед. Если обучать равновесию, то это долгий путь проб и ошибок, человек так и не поймет, почему он может ехать.
Если рассказать, что его равновесие вообще не играет роли, а на самом деле он не заметно для себя поворачивает руль в сторону, в которую падает, обучение пойдет в разы быстрее. Буквально 30 минут и любой человек поедет на велосипеде.
Та же история с реверсивным рулём, когда люди не понимают что происходит и пытаются держать равновесие, но незаметно крутят руль и падают.
Равновесие больше нужно при езде без рук, но там все больше зависит от угла вилки и смешения оси колеса.
Оказывается спутник ещё жив. Некоторым приходится использовать их браузер для доступа к гос закупкам.
Помнится ростелеком делал аналог Steam от Valve. В стиме комиссия была 30%, ростелеком захотел 50%, итого в ноябре 2015 запуск, в мае 2017 закрытие, -14 млн.
Возможно для видео что-то сделают на основе BigBlueButton у них тут как раз 2.2 версия вышла.
Для тех, кто прочитал эту статью и захотел что-то электрическое, для езды по городу, то рекомендую велошлем и электросамокат.
Так-же рекомендую учесть следующее моменты описанные в этом видео www.youtube.com/watch?v=jC8JN2F1zpI.
Так-же интересно вопрос, так как в статье говорится про езду по
оффроаду
, а переключатели данного уровня вообще никак не справляются с удержанием цепи на хоть каких-то кочках. Во что мотор превратит систему, когда слетит цепь. Как быстро мотор слизывает все звезды?
По практическим рекомендациям, если ваш API будет использоваться из браузера.
Пункт 2, если у вас API не для раздачи вэбстраниц, используйте POST метод или вэбсокеты или другие методы. К остальным прибегайте когда это требует браузер.
Пункт 3. Если у вас снова не раздача вэбстраниц, то указанный стандарт не для вас.
По пункту 4 все больше кажется что речь не про раздачу вэбстраниц.
Пункт 11. Убедитесь, что кэшируете в нужном месте, хотя ИИ агент легко объяснит пользователю как сбросить кэш, но осадочек останется
Пункт 12. Ага... вы все таки решили поиграть с браузером в игры, подбери нужный http метод, ну вот, теперь выбирайте POST или вэбсокет😉
Пункт 16, это ISO формат, если вы его не узнали.
Пункт 17. Ну это будет прям не просто.... Лучше используйте ту, что возможно. Не надо имитировать курсоры там, где их нет.
Пункт 18. Используйте HTTP как траспорт, не надо искать куда бы ему в красивое место записать, что-то что кажется вам подходящим. Ну явно же не вэбстраницы раздаёте.
Пункт 19. Вы решили, что ваш API не используется в браузере, обмазались HTTP методами, всё красиво, ещё и кэширующие заголовки трогали, но у клиента стоит кэшируюший DPI на выходе. Вот вам и пу-пу-пу.
На последок, любой API с документацией, лучше чем "стандартный REST", который кажется более понятными, но без документации.
Не рассматривался ли вариант, когда вы накрываете все свои сервисы Auth сервисом, через который проходят все запросы, а остальные сервисы у Auth запрашивают только нужные им роли для обработки запроса. Сервисы между собой просто через SSH общаются.
Схема в стиле:
Пользователь отправляет подписанный запрос, Auth сервис проверяет что подпись правильная и отправляет его дальше, уже внутренние сервисы запрашивают нужные роли этого пользователя у Auth сервиса им уже ничего проверять не надо, логику Auth тоже размазывать не надо. Надоест JWT просто Auth переедет на что-то более молодёжное, остальные сервисы просто будут смотреть на нужные им роли.
Для миграции сервисов на новую версию Auth, можно или всем сразу или временно поддерживать несколько версий.
И все проблемы с отзывом ролей сразу пропадают.
В случае обмазывания кэшом где либо, при изменении данные из кэша просто удалять, (можно и заменить, но зачем эти сложности).
$mol странный предмет, комменты есть, но либы нет)
Если этот коммент был про https://www.npmjs.com/package/mol_fiber, не думаю, что оно для кого либо актуально.
Обычно мнение о useCallback делится на до и после коммита с оборачиванием компонентов для какой нибудь виртуализации. Чтоб намекнуть людям, что такая проблема как-бы есть, сейчас допиливают React Compiler который автоматически будет это делать.
https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024
Проблема в том, что статья содержит неверную информацию.
Во первых:
А асинхронный код может выполняться параллельно с другими задачами - это не так. Асинхронный код выполняется в один поток.
Во вторых:
Event Loop обеспечивает параллелизм в смысле возможности выполнять несколько операций одновременно, не блокируя основной поток выполнения. - Event loop тоже работает в один поток, любая тяжелая операция блокирует основной поток выполнения.
Без негатива. @Wilbemax Посмотрите на https://habr.com/ru/articles/762618/
Обратите внимание на
https://developer.mozilla.org/en-US/docs/Glossary/Thread https://developer.mozilla.org/ru/docs/Web/API/Web_Workers_API/Using_web_workers
Хм... а я кажись нашел источник ошибки
https://developer.mozilla.org/ru/docs/Web/JavaScript/Event_loop Статья на русском в начале разительно отличается от версии на английском. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Event_loop не зря там огромный баннер в начале с предупреждением.
Вот тут на русском вроде без косяков https://learn.javascript.ru/event-loop
Это же просто метод для тестирования хуков, после "исправления" просто добавилась другая зависимость.
Хуки для того и вводили, чтоб избавится от миксинов и хоков. А тут вместо обычного, понятно всем компонента используется
connectчтоб соединить всё, так ещё и надо идти смотреть его доку, чтоб понять, что тут происходит.Из плюсов, читаемость вещь субъективная, процесс тестирование чет особо проще то и не стал это вот точно, хуки прекрасно повторно используются и без этих костылей.
(Картинка, раньше было лучше)
Опять таки, что делать в этом "магическом" подходе, с хуками которые нужны для UI.
Или почему не выбрать redux-saga оно тут больше подходит в плане декомпозиции.
Немного истории: https://legacy.reactjs.org/docs/hooks-intro.html#motivation
А если смотреть на REST API, как на спеку, а HTTP как на траспортный протокол. И не иметь интимностей с особенностями кэширования и проксирования разных HTTP методов.
Когда лучше не использовать GET - если ответ меняется чаще чем раз в день.
PUT и POST для создания/обновления записи в базе, нужно использовать если пользователи вам платят за вызовы API.
Исключительно моё мнение. Возможно нужно UX специалистов добавить в команду. Они умеют делать красиво. А то сейчас все товары имеют капинские подписи. ( "Куртка утеплённая...", "Рубашка белая..."). Как-то или описание поверх картинки делать, ну или внизу хотя бы бренд писать, можно места больше под надпись сделать.
Ещё интересно, почему картинки всегда грузятся долго, будто забыли включить кеширование?
чтоб удалить все дефолтные свойства объекта. А то там ещё немного камней оставили.
Ответ исключительно про велосипед. Если обучать равновесию, то это долгий путь проб и ошибок, человек так и не поймет, почему он может ехать.
Если рассказать, что его равновесие вообще не играет роли, а на самом деле он не заметно для себя поворачивает руль в сторону, в которую падает, обучение пойдет в разы быстрее. Буквально 30 минут и любой человек поедет на велосипеде.
Та же история с реверсивным рулём, когда люди не понимают что происходит и пытаются держать равновесие, но незаметно крутят руль и падают.
Равновесие больше нужно при езде без рук, но там все больше зависит от угла вилки и смешения оси колеса.
Тут вот тудушка есть для реакта.
Помнится ростелеком делал аналог Steam от Valve. В стиме комиссия была 30%, ростелеком захотел 50%, итого в ноябре 2015 запуск, в мае 2017 закрытие, -14 млн.
Возможно для видео что-то сделают на основе BigBlueButton у них тут как раз 2.2 версия вышла.
Получение данных в UI не лучший подход.
Почему у этого лицензия не MIT, не понятно.
Так-же в babel можно включить поддержку с помощью плагинов.
babeljs.io/docs/en/babel-plugin-proposal-nullish-coalescing-operator
babeljs.io/docs/en/babel-plugin-proposal-optional-chaining
Так-же рекомендую учесть следующее моменты описанные в этом видео www.youtube.com/watch?v=jC8JN2F1zpI.
Так-же интересно вопрос, так как в статье говорится про езду по , а переключатели данного уровня вообще никак не справляются с удержанием цепи на хоть каких-то кочках. Во что мотор превратит систему, когда слетит цепь. Как быстро мотор слизывает все звезды?