Ну вот я не вижу, где в примере о бронировании номера хоть какая-то транзакционность или просто атомарность. Незанятость номера проверяется, ага. А если через 1 мс она изменится потому что кто-то другой забукал номер? Если всё это завёрнуто в одну большую транзакцию, то где обработка нарушения ограничений при её коммите?
Похоже, что эти безусловно красивые абстракции только помешают довести этот прототип до уровня production ready
Пишу: для получения списка элементов (например, имена файлов или список урлов, ничего не писал про их содержимое!), нужно прочитать объект-коллекцию (например, директорию), вы говорите, что это штука инородная и чуждая.
А потом говорите, что чтобы получить метаданные файла нужно прочитать файл директории.
Просто мысли вслух по поводу круда (не статьи), если позволите.
Мы можем создать элемент, прочитать его, обновить и удалить. А как насчёт получить список элементов? В этом месте говорят: легко! Это тоже Read, но не элемента, а коллекции. Но по такой логике создание и удаление элемента — это просто обновление коллекции, верно. Тогда зачем в C.R.U.D нужны C и D?
Может быть, это было актуально для HTTP/1.1, но с HTTP/2 браузер может загружать не меньше сотни ресурсов за раз, при этом у каждого запроса внутри коннекции есть приоритет.
Дефёрнутые скрипты грузятся с приоритетом Low Стили — Highest Картинки с Low пока не попадут во вьюпорт, после чего их приоритет динамически повышается до High. Полная таблица тут: https://web.dev/articles/fetch-priority
Поэтому можно сильно не переживать, что кто-то у кого-то будет сильно канал отъедать. К тому же, через fetchpriority можно приоритет подтюнить. Например, если заведомо известно, что одна конкретная картинка будет показываться на первом экране, не грех ей поставить fetchpriority=high
Поэтому скрипты надо подключать перед закрывающим тегом , а не в секции .
Тут, похоже, парсер теги съел.
Если это про подключение скриптов перед закрывающим <body>, то уж сильно дедовский метод. Лучше таки подключать их в <head>, но с атрибутом defer и после стилей. Так они пораньше начнут потихоньку грузиться по сети с приоритетом Low не дожидаясь того, как весь ответ html долетит целиком
Как только данные приходят, соединение закрывается, и клиент сразу же открывает новое. <…> Именно на базе этого подхода реализованы технологии вроде Server-Sent Events (SSE).
Нет, это неправда, не вводите людей в заблуждение! SSE не закрывает соединение после отправки сообщения, у вас же на диаграммах это изображено
Ну справедливости ради, в http/0.9 тоже никаких заголовков не было, был один-единственный метод и ноль майм-типов. И обратную совместимость ломали уже три раза, с каждой мажорной версией. Может быть, и не технические ограничения перевесили чашу весов
HTTPS … где никакая безопасность объективно не нужна … результат потребности в распространении рекламы
Не чтобы спорить, а просто пооффтопить: Моя любимая шапочка из фольги в том, что фразу "Internet is for porn" следует читать буквально.
Когда всё было по HTTP, процветала "спутниковая рыбалка", спутник работает как радио, рассылая ответ всем. Народ вычленял из этого "радио" чужие ответы, прежде всего видосы. Ну и вы понимаете, какой характер носили 60+% видосов. Чтобы прекратить рассылать платный контент в открытом виде, нужно было как-то убедить интернет перейти на шифрование трафика.
Флеш не работает в браузере на айфоне? Нужно дать людям возможность смотреть видео из браузера! Потому что приложения… они наверное не будут ставить, слишком палевно.
Туда же и и крипта. За крипту можно анонимно оплатить всякие видосы. Хорошая вещь, оставляем.
А вот NFT для порно-индустрии бесполезен, вот он и отмер.
Я понимаю, к чему вы, если соединений 6, то дроп одного пакета заафектит только 1 коннекцию из 6. Но вместе с h2 поменялась и манера изготовления сайтов. Мы больше не клеим спрайты, не склеиваем среднего размера джаваскрипты в джамбо-бандлы весом по мегабайту, из-за чего они прилетают на клиент и исполняются быстрее. Мы можем делать запрос двух эндпойнтов в параллель с практически нулевым оверхердом, что дало лучшую попадаемость в кэш.
Да, может быть, дропы стали аффектить коннекцию больше, но h2 открыл нам возможности и техники чтобы в оптимистичном случае всё работало быстрее.
Само собой, если сайт оптимизированный под h1 гонять через h2, могут быть просадки. И наоборот. Но в целом и общем, я бы сказал, что h2 скорее добро, чем зло
Что за язвительная ненависть? Http/2 действительно лучше http/1. Не 6 запросов в параллель, а 100..128. Keepalive дольше, значительно меньше шансы того, что новый запрос потребует установки соединения заново. Приоритеты в конце концов, когда можно поставить один ответ на паузу и послать что-то более важное вперёд.
Http/3 решает и проблемы с "колом встаёт всё". Списки доменов уже не нужны — есть DNS записи HTTPS.
Проблемы с DPI и блокировкой — это гугл виноват? Или может быть кто-то другой?
При проектировани сразу учитывайте ограничения и возможности клиента. Другими словами, загляните на пару уровней абстракции вниз.
HTTP/2+ поддерживает много параллельных запросов по одному соединению (зависит от настроек сервера, типичные значения 100…128). Может быть, вам не нужен батчинг вообще, а будет только вредить из-за плохого попадания в кэш?
Будет ли апишка дёргаться в браузере с другого домена? CORS — это не просто два заголовка. Это ещё и preflight-запросы, избежав которых можно значительно ускорить общее время запроса. Сюда относятся и кастомные заголовки и организация урлов (эффективное использование access-control-max-age)
Публичность/приватность возвращаемых данных, их время жизни. Если смешать в одном ответе данные с долгим временем жизни и коротким, у всего ответа будет короткое время жизни. Если смешать публичные и приватные (юзер-специфичные) данные, весь ответ станет некэшируемым (чаще всего на практике).
При авторизации через куку и кросс-домене: из-за изоляции запросов или все запросы должны быть с кукой, или все без неё. Иначе браузер может отказаться использовать уже открытое соединение.
… и ещё куча всего, но общий посыл: Абстракции текут, можно сразу подставить ведёрко. Или хотя бы предусмотреть место, куда можно будет в будущем его подставить
Ну вот я не вижу, где в примере о бронировании номера хоть какая-то транзакционность или просто атомарность.
Незанятость номера проверяется, ага. А если через 1 мс она изменится потому что кто-то другой забукал номер?
Если всё это завёрнуто в одну большую транзакцию, то где обработка нарушения ограничений при её коммите?
Похоже, что эти безусловно красивые абстракции только помешают довести этот прототип до уровня production ready
SQL-транзакций в языке бизнеса нет, поэтому и в коде не будет?
Я вас не понимаю.
Пишу: для получения списка элементов (например, имена файлов или список урлов, ничего не писал про их содержимое!), нужно прочитать объект-коллекцию (например, директорию), вы говорите, что это штука инородная и чуждая.
А потом говорите, что чтобы получить метаданные файла нужно прочитать файл директории.
Ну как так?
Я имею в виду самый обычный листинг. Чтобы получить список файлов в папке, не обязательно же читать их содержимое?
Understandable, have a nice day.
Просто мысли вслух по поводу круда (не статьи), если позволите.
Мы можем создать элемент, прочитать его, обновить и удалить. А как насчёт получить список элементов?
В этом месте говорят: легко! Это тоже Read, но не элемента, а коллекции.
Но по такой логике создание и удаление элемента — это просто обновление коллекции, верно. Тогда зачем в C.R.U.D нужны C и D?
Тут опечатка? Потому что изменять и модифицировать — это вроде одно и то же
Может быть, это было актуально для HTTP/1.1, но с HTTP/2 браузер может загружать не меньше сотни ресурсов за раз, при этом у каждого запроса внутри коннекции есть приоритет.
Дефёрнутые скрипты грузятся с приоритетом Low
Стили — Highest
Картинки с Low пока не попадут во вьюпорт, после чего их приоритет динамически повышается до High.
Полная таблица тут: https://web.dev/articles/fetch-priority
Поэтому можно сильно не переживать, что кто-то у кого-то будет сильно канал отъедать. К тому же, через
fetchpriorityможно приоритет подтюнить. Например, если заведомо известно, что одна конкретная картинка будет показываться на первом экране, не грех ей поставитьfetchpriority=highТут, похоже, парсер теги съел.
Если это про подключение скриптов перед закрывающим
<body>, то уж сильно дедовский метод. Лучше таки подключать их в<head>, но с атрибутомdeferи после стилей.Так они пораньше начнут потихоньку грузиться по сети с приоритетом Low не дожидаясь того, как весь ответ html долетит целиком
Если бы в английском были отдельно have-служебный и have-обычный-переходный (как haber и tener), вот это добавление got может и не понадобилось бы
Интересно, почему никто не упомянул svgo?
Выбрал картинку наугад.
Сырой вес: 374 346, при передаче клиенту она жмётся гзипом до 231 321 ("wire bytes").
После
npx svgo@latest: 79 409 несжатая, 27 860 по проводу.Похоже, это из какой-то древней методички, просто sha с солью уже давно недостаточно.
NIST рекомендует хотя бы PBKDF2 с хотя бы 600 000 итераций. (Грубо говоря, это sha256 выполненный 600 000 раз).
А ещё лучше, что-нибудь более специализированное и защищённое от перебора на видеокарте.
Пардон за душнения, я понимаю, что это пет-проект. Но не дай боже кто-нибудь это прочитает и в прод утащит)
Нет, это неправда, не вводите людей в заблуждение!
SSE не закрывает соединение после отправки сообщения, у вас же на диаграммах это изображено
Ну справедливости ради, в http/0.9 тоже никаких заголовков не было, был один-единственный метод и ноль майм-типов. И обратную совместимость ломали уже три раза, с каждой мажорной версией.
Может быть, и не технические ограничения перевесили чашу весов
Только векторный гипертекстовый фидонет, только харкор!
Поэтому и говорю, шапочка из фольги. Это оффтопик и есть, сорри, если не в тему
Не чтобы спорить, а просто пооффтопить:
Моя любимая шапочка из фольги в том, что фразу "Internet is for porn" следует читать буквально.
Когда всё было по HTTP, процветала "спутниковая рыбалка", спутник работает как радио, рассылая ответ всем. Народ вычленял из этого "радио" чужие ответы, прежде всего видосы. Ну и вы понимаете, какой характер носили 60+% видосов.
Чтобы прекратить рассылать платный контент в открытом виде, нужно было как-то убедить интернет перейти на шифрование трафика.
Флеш не работает в браузере на айфоне? Нужно дать людям возможность смотреть видео из браузера! Потому что приложения… они наверное не будут ставить, слишком палевно.
Туда же и и крипта. За крипту можно анонимно оплатить всякие видосы. Хорошая вещь, оставляем.
А вот NFT для порно-индустрии бесполезен, вот он и отмер.
Я понимаю, к чему вы, если соединений 6, то дроп одного пакета заафектит только 1 коннекцию из 6.
Но вместе с h2 поменялась и манера изготовления сайтов. Мы больше не клеим спрайты, не склеиваем среднего размера джаваскрипты в джамбо-бандлы весом по мегабайту, из-за чего они прилетают на клиент и исполняются быстрее. Мы можем делать запрос двух эндпойнтов в параллель с практически нулевым оверхердом, что дало лучшую попадаемость в кэш.
Да, может быть, дропы стали аффектить коннекцию больше, но h2 открыл нам возможности и техники чтобы в оптимистичном случае всё работало быстрее.
Само собой, если сайт оптимизированный под h1 гонять через h2, могут быть просадки. И наоборот. Но в целом и общем, я бы сказал, что h2 скорее добро, чем зло
Что за язвительная ненависть?
Http/2 действительно лучше http/1. Не 6 запросов в параллель, а 100..128. Keepalive дольше, значительно меньше шансы того, что новый запрос потребует установки соединения заново. Приоритеты в конце концов, когда можно поставить один ответ на паузу и послать что-то более важное вперёд.
Http/3 решает и проблемы с "колом встаёт всё". Списки доменов уже не нужны — есть DNS записи HTTPS.
Проблемы с DPI и блокировкой — это гугл виноват? Или может быть кто-то другой?
Да вроде бы нода работает так чуть ли не с самого начала. В районе 2015 только добавились микротаски
При проектировани сразу учитывайте ограничения и возможности клиента. Другими словами, загляните на пару уровней абстракции вниз.
HTTP/2+ поддерживает много параллельных запросов по одному соединению (зависит от настроек сервера, типичные значения 100…128). Может быть, вам не нужен батчинг вообще, а будет только вредить из-за плохого попадания в кэш?
Будет ли апишка дёргаться в браузере с другого домена? CORS — это не просто два заголовка. Это ещё и preflight-запросы, избежав которых можно значительно ускорить общее время запроса. Сюда относятся и кастомные заголовки и организация урлов (эффективное использование access-control-max-age)
Публичность/приватность возвращаемых данных, их время жизни. Если смешать в одном ответе данные с долгим временем жизни и коротким, у всего ответа будет короткое время жизни. Если смешать публичные и приватные (юзер-специфичные) данные, весь ответ станет некэшируемым (чаще всего на практике).
При авторизации через куку и кросс-домене: из-за изоляции запросов или все запросы должны быть с кукой, или все без неё. Иначе браузер может отказаться использовать уже открытое соединение.
… и ещё куча всего, но общий посыл: Абстракции текут, можно сразу подставить ведёрко. Или хотя бы предусмотреть место, куда можно будет в будущем его подставить