Неправда! Это чтобы народу хуже сделать! Чтобы все на рутуб переходили, и пропаганду смотрели! Чтобы чебурнет свой сделать! Чтобы за народом следить!
🌟 Выгодоприобретатели блокировки Youtube / Habr
🌟 Выгодоприобретатели блокировки Youtube / Habr
Хабр
Выгодоприобретатели блокировки Youtube
Недавно возникшая тема с блокировкой (замедлением) Youtube коснулась практически каждого жителя РФ. При этом до сих пор нет ни одного прямого официального заявления о причастности к этой блокировке....
👍1😁1
Короче, есть такая штука — BFG. Это типа как git-filter-branch, только круче. С ней можно легко и быстро удалить ненужные данные из истории репозитория.
Как это работает:
- Клонируешь репозиторий с флагом --mirror, чтобы сделать копию.
- Запускаешь BFG, чтобы обновить коммиты и ветки.
- Удаляешь ненужные данные с помощью git gc.
- Снова запускаешь BFG, чтобы обновить ссылки на git сервере.
BFG может удалять файлы с именами id_rsa или id_dsa, большие двоичные файлы больше 50 мегабайт, пароли, папки или файлы с именем .git.
BFG работает в 10–720 раз быстрее, чем git-filter-branch и не трогает последний коммит.
https://rtyley.github.io/bfg-repo-cleaner/
Как это работает:
- Клонируешь репозиторий с флагом --mirror, чтобы сделать копию.
- Запускаешь BFG, чтобы обновить коммиты и ветки.
- Удаляешь ненужные данные с помощью git gc.
- Снова запускаешь BFG, чтобы обновить ссылки на git сервере.
BFG может удалять файлы с именами id_rsa или id_dsa, большие двоичные файлы больше 50 мегабайт, пароли, папки или файлы с именем .git.
BFG работает в 10–720 раз быстрее, чем git-filter-branch и не трогает последний коммит.
https://rtyley.github.io/bfg-repo-cleaner/
rtyley.github.io
BFG Repo-Cleaner by rtyley
A simpler, faster alternative to git-filter-branch for deleting big files and removing passwords from Git history.
NET_Microservices_Architecture_for_Containerized_NET_Applications.pdf
11.7 MB
А, ну и небольшая книжка (всего 350 стр.) от майков, про архитектуру микросервисов.
Сразу в PDF да.
Сразу в PDF да.
👍2
Один из способов отличить дипфейк видео от реального:
Стандарт аутентификации C2PA.
C2PA — это организация, которая придумала стандарт Content Credentials.
С его помощью издатели, создатели и потребители могут отслеживать путь разных медиа от производства до потребления. Например, можно узнать, какая камера сделала фото, изменяли его или нет и когда.
C2PA использует шифрование, чтобы зашифровать информацию о происхождении контента. Это значит, что можно узнать, кто, как и когда создал контент.
Было бы классно, если бы не проблемы по оптимизации соцсетей. Практически любой медиаконтент, который мы заливаем на платформы — подвергается изменению. Компрессия, для оптимизации хранения, изменение размера и качества, для выбора качества показываемого медиа, создание дополнительных файлов для превью и прочее.
Во всем этом конвеере, метаданные исходного файла спокойно могут потеряться, а для внедрения полноценной системы проброса метаданных внутри платформы — нужно очень много финансовых затрат. Это не отдельный функционал, а модификация всей вертикали обработки медиа.
Стандарт аутентификации C2PA.
C2PA — это организация, которая придумала стандарт Content Credentials.
С его помощью издатели, создатели и потребители могут отслеживать путь разных медиа от производства до потребления. Например, можно узнать, какая камера сделала фото, изменяли его или нет и когда.
C2PA использует шифрование, чтобы зашифровать информацию о происхождении контента. Это значит, что можно узнать, кто, как и когда создал контент.
Было бы классно, если бы не проблемы по оптимизации соцсетей. Практически любой медиаконтент, который мы заливаем на платформы — подвергается изменению. Компрессия, для оптимизации хранения, изменение размера и качества, для выбора качества показываемого медиа, создание дополнительных файлов для превью и прочее.
Во всем этом конвеере, метаданные исходного файла спокойно могут потеряться, а для внедрения полноценной системы проброса метаданных внутри платформы — нужно очень много финансовых затрат. Это не отдельный функционал, а модификация всей вертикали обработки медиа.
Forwarded from Стой под стрелой (Nikita Prokopov)
Раздражает, как в айтишечке используют слово «требования» (requirements). Типа, звучит как «кровь из носу надо», «без этого не заработает/не полетит» и вообще несдвигаемая какая-то стена и что-то осмысленное и глубоко проанализированное.
А на деле это обычно с потолка взятая цифра, которую за три секунды кто-то придумал. Типа, «нам надо обрабатывать 5000 запросов/секунду». Почему именно 5000? А если 10000 обработаем? А если 1000? Не то чтобы решения будут сильно разными, и не то чтобы кто-то специально будет программу замедлять. Команда напишет код to the best of its abilities, купят сервачок какой-нибудь, а там херакс — и 100,000 вместо 5000 получится. И чего? Обратно отдавать куда-то?
В обратную сторону тоже верно. Написали, получилось тысяча — что теперь, не запускаться? Запустятся все равно, один фиг столько пользователей на старте не будет. А потом посмотрят, сколько придет.
То же самое с reliability, и с дедлайнами, с временем отклика. Все будут стараться, но получится как получится, и запуск будет все равно.
А еще иногда кто-нибудь выходит и говорит гордо: we’ve met our requirements. Типа, выполнили требования. А ты смотришь и видишь — фигню какую-то сделали. Типа, сайт три секунды открывается. А он такой — так у нас и были требования чтобы три секунды.
Ну и нафига тогда требования?
А на деле это обычно с потолка взятая цифра, которую за три секунды кто-то придумал. Типа, «нам надо обрабатывать 5000 запросов/секунду». Почему именно 5000? А если 10000 обработаем? А если 1000? Не то чтобы решения будут сильно разными, и не то чтобы кто-то специально будет программу замедлять. Команда напишет код to the best of its abilities, купят сервачок какой-нибудь, а там херакс — и 100,000 вместо 5000 получится. И чего? Обратно отдавать куда-то?
В обратную сторону тоже верно. Написали, получилось тысяча — что теперь, не запускаться? Запустятся все равно, один фиг столько пользователей на старте не будет. А потом посмотрят, сколько придет.
То же самое с reliability, и с дедлайнами, с временем отклика. Все будут стараться, но получится как получится, и запуск будет все равно.
А еще иногда кто-нибудь выходит и говорит гордо: we’ve met our requirements. Типа, выполнили требования. А ты смотришь и видишь — фигню какую-то сделали. Типа, сайт три секунды открывается. А он такой — так у нас и были требования чтобы три секунды.
Ну и нафига тогда требования?
Testcontainers для .NET — одно из давно искомых, но почему-то ускользавших от меня решений, по созданию окружения при прогоне тестов. Помогает создавать и запускать контейнеры Docker.
С ним можно запускать контейнеры прямо из кода, например, в слое test prepare, в
Оно работает с .NET Docker remote API. Контейнеры очень гибко конфигурируются, можно использовать любые докер образы, настраивать порты и healthcheck'и прямо как в docker compose. Так-же можно использовать свои контейнеры, собранные из Dockerfiles.
Например запуск экземпляра PostgeSQL, с ожиданием полного запуска:
Official page: https://dotnet.testcontainers.org/
Nuget: https://www.nuget.org/packages/DotNet.Testcontainers
С ним можно запускать контейнеры прямо из кода, например, в слое test prepare, в
[OneTimeSetup] (NUnit).Оно работает с .NET Docker remote API. Контейнеры очень гибко конфигурируются, можно использовать любые докер образы, настраивать порты и healthcheck'и прямо как в docker compose. Так-же можно использовать свои контейнеры, собранные из Dockerfiles.
Например запуск экземпляра PostgeSQL, с ожиданием полного запуска:
new ContainerBuilder()
.WithName(containerName)
.WithImage("postgres:17")
.WithHostname(containerHostName)
.WithExposedPort(5432)
.WithPortBinding(5432, true)
.WithEnvironment("POSTGRES_PASSWORD", postgresPassword)
.WithEnvironment("PGDATA", "/pgdata")
.WithTmpfsMount("/pgdata")
.WithWaitStrategy(Wait.ForUnixContainer().UntilCommandIsCompleted("psql -U postgres -c \"select 1\""))
.Build();
Official page: https://dotnet.testcontainers.org/
Nuget: https://www.nuget.org/packages/DotNet.Testcontainers
www.nuget.org
DotNet.Testcontainers 1.6.0
A lightweight library to run tests with throwaway instances of Docker containers.
🔥1
STOMP - это простой протокол взаимодействия, предназначенный для асинхронной передачи сообщений между клиентами через серверы-посредники. Он определяет текстовый формат сообщений, передаваемых между этими клиентами и серверами.
STOMP активно используется в течение нескольких лет и поддерживается многими брокерами сообщений и клиентскими библиотеками. Эта спецификация определяет протокол STOMP 1.2 и является обновлением STOMP 1.1.
https://stomp.github.io/stomp-specification-1.2.html#Overview
STOMP активно используется в течение нескольких лет и поддерживается многими брокерами сообщений и клиентскими библиотеками. Эта спецификация определяет протокол STOMP 1.2 и является обновлением STOMP 1.1.
https://stomp.github.io/stomp-specification-1.2.html#Overview
stomp.github.io
The Simple Text Oriented Messaging Protocol
MQTT - это протокол обмена сообщениями, разработанный OASIS (Организация по продвижению стандартов структурированной информации ), который служит стандартом для связи в Интернете вещей (IoT). Этот протокол разработан как чрезвычайно легкий и эффективный транспортный механизм публикации/подписки, что делает его идеальным для подключения удаленных устройств с минимальной сложностью кода и требованиями к пропускной способности сети.
https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.pdf
https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.pdf
🔥1
.SLNX
Новый формат файла решения (солюшена) .Net. Пока что не входит в шаблон по умолчанию RTM (но уже по умолчанию с версии Visual Studio 2022 v17.12-preview).
Если коротко, то просто все устали читать километры GUID'ов в стандартном .sln файле (скрин №1), и майки перешли в формат XML (скрин №2). В целом стало сильно лучше читаться, и меньше проблем в параллельной разработке, при решении конфликтов (да-да, кто не резолвил это практически наугад, того не существует. скрин №3).
PS. В Rider уже завезли поддержку, с версии v2024.2 (кроме того, что он стал бесплатный⭐️ )
Новый формат файла решения (солюшена) .Net. Пока что не входит в шаблон по умолчанию RTM (но уже по умолчанию с версии Visual Studio 2022 v17.12-preview).
Если коротко, то просто все устали читать километры GUID'ов в стандартном .sln файле (скрин №1), и майки перешли в формат XML (скрин №2). В целом стало сильно лучше читаться, и меньше проблем в параллельной разработке, при решении конфликтов (да-да, кто не резолвил это практически наугад, того не существует. скрин №3).
PS. В Rider уже завезли поддержку, с версии v2024.2 (кроме того, что он стал бесплатный
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
JSON — BSON
JSON (JavaScript Object Notation) — текстовый формат для хранения и передачи структурированных данных, в формате ключ-значение. Поддерживает
BSON (Binary JSON) — бинарный формат для хранения данных (используется в MongoDB), поддерживающий все типы JSON, плюс дополнительные типы. Например
JSON — для передачи данных, BSON — для хранения данных.
Использование BSON в ASP.NET Core:
Для десериализации данных в ASP.NET Core нужно добавить
JSON (JavaScript Object Notation) — текстовый формат для хранения и передачи структурированных данных, в формате ключ-значение. Поддерживает
string, bool, int, float, object, [ ].BSON (Binary JSON) — бинарный формат для хранения данных (используется в MongoDB), поддерживающий все типы JSON, плюс дополнительные типы. Например
date (без пояса), byte[ ], regex, string(len)JSON — для передачи данных, BSON — для хранения данных.
Использование BSON в ASP.NET Core:
Для десериализации данных в ASP.NET Core нужно добавить
BsonMediaTypeFormatter в коллекцию formatters и он будет включаться для обработки запроса «application/bson».This media is not supported in your browser
VIEW IN TELEGRAM
Datadog, CoScreen, парное программирование.
Datadog, на которых я наткнулся, пока искал альтернативы GigaCode и Tabnine, помимо того, что приобрели Codiga, оказалось что имеют так-же очень крутой проект, являющийся альтернативой Code With Me. В общем программой для совместного кодинга, там можно рисовать, имитировать ввод, расшаривать разные конкретные окна, работая вместе одновременно до 10 человек, без прерывания расшаривания, т.е. разные люди одновременно могут расшаривать свои окна, и все могут работать сразу с разными окнами разных людей — это очень круто, аналогов еще не видел. Кроме тогои имеет стандартный набор для конференций — рисовалки, видео с камеры, звук с микрофона.
Ну и да, проект называется CoScreen, и вау, он бесплатный и работает очень даже неплохо.
https://www.coscreen.co/
Datadog, на которых я наткнулся, пока искал альтернативы GigaCode и Tabnine, помимо того, что приобрели Codiga, оказалось что имеют так-же очень крутой проект, являющийся альтернативой Code With Me. В общем программой для совместного кодинга, там можно рисовать, имитировать ввод, расшаривать разные конкретные окна, работая вместе одновременно до 10 человек, без прерывания расшаривания, т.е. разные люди одновременно могут расшаривать свои окна, и все могут работать сразу с разными окнами разных людей — это очень круто, аналогов еще не видел. Кроме тогои имеет стандартный набор для конференций — рисовалки, видео с камеры, звук с микрофона.
Ну и да, проект называется CoScreen, и вау, он бесплатный и работает очень даже неплохо.
https://www.coscreen.co/
Не ИИ а ЦИМ.
В результате наблюдений:
- за развитием ИИ-лихорадки
- за спросом на ML специалистов
- за внедрением нейросетей в организациях
Сделал вывод, что нейросети превращаются в Централизованный Искусственный Мозг организаций. Не только большие, но и малые организации всё больше заходят в эту волну. ИИ в этих организациях начинает играть роль центра принятия решений, так как все чаще начинает мелькать схема "Все имеющиеся данные организации📄 " ➡️ "ИИ 🤖" ➡️ "Решение 💡 ".
И это на примере любой организации. Банк? Пожалуйста:
🔵 "Выдать ли кредит?"
📄 "Данные о заемщике (открытые/закрытые/государственные) + данные о рынке + данные о состоянии банка + данные о геополитике"
➡️ "ИИ: пара минут вычислений, оценка надежности заемщика и стабильности обстановки в мире, оценка возможностей организации, оценка рисков"
➡️ "👍 🙅 Решение: да/нет".
То, на что раньше уходило множество человеко-часов, теперь решается за пару минут, с гораздо меньшими рисками и гораздо более высокой точностью. Все что нужно — много денег, отдел специалистов, вычислительные мощности. Да, очень дорого, но очень точно и очень перспективно.
Еще примеры:
🔵 "Запускать ли новый продукт?":
📄 "Данные о потребительских предпочтениях + данные о трендах на рынке + данные о продажах конкурентов + производственные мощности"
➡️ "🖥 ИИ: пара минут вычислений, оценка потенциального спроса, прогноз окупаемости, анализ конкурентной среды и сезонных факторов"
➡️ "👍 🙅 Решение: запускать/не запускать продукт"
🔵 "Стоит ли запускать производство мерча по фильму?"
📄 "Данные о ранних отзывах на фильм + анализ трендов в соцсетях + данные о похожих успешных фильмах + прогнозируемая аудитория по возрастам и регионам"
➡️ "🖥 ИИ: пара минут вычислений, оценка спроса, прогноз популярности фильма, анализ возможных регионов для запуска мерча"
➡️ "👍 🙅 Решение: запускать/не запускать мерч, объем и ассортимент"
🔵 "Стоит ли продолжать рекламную кампанию?"
📄 "Текущие показатели вовлеченности (CTR, лайки, репосты) + исторические данные по успешным кампаниям + данные о характеристиках аудитории + затраты на рекламу"
➡️ "🖥 ИИ: пара минут вычислений, анализ эффективности, прогноз ожидаемой отдачи, сравнение с предыдущими кампаниями"
➡️ "👍 🙅 Решение: продолжать/остановить кампанию, изменить целевую аудиторию и бюджет"
В результате наблюдений:
- за развитием ИИ-лихорадки
- за спросом на ML специалистов
- за внедрением нейросетей в организациях
Сделал вывод, что нейросети превращаются в Централизованный Искусственный Мозг организаций. Не только большие, но и малые организации всё больше заходят в эту волну. ИИ в этих организациях начинает играть роль центра принятия решений, так как все чаще начинает мелькать схема "Все имеющиеся данные организации
И это на примере любой организации. Банк? Пожалуйста:
То, на что раньше уходило множество человеко-часов, теперь решается за пару минут, с гораздо меньшими рисками и гораздо более высокой точностью. Все что нужно — много денег, отдел специалистов, вычислительные мощности. Да, очень дорого, но очень точно и очень перспективно.
Еще примеры:
Please open Telegram to view this post
VIEW IN TELEGRAM
Минорные коммиты.
Мне очень лень наполнять смыслом сообщения коммитов, которые еще не содержат какого-либо результата и являются либо коммитом просто для персистенции или стэша. Обычно в таких коммитах я ставлю либо +++ либо пишу stash. Потому что он, как отдельно взятый, не будет нести какой-либо ценности, а только в купе с остальными коммитами в фича ветке. Предпочитаю просто сквошить коммиты при слиянии с веткой разработки. Тогда и можно наполнить сообщение коммита смыслом. Хотя для отслеживающих MR/PR сложно понять что изменилось с последнего просмотра.
Очень жду плагин, который будет составлять описание коммита автоматически.
В целом GigaCode уже может делать это через чат, если попросить его, добавив изменения как Patch из гита. (Пример на скринах). Но это все еще не эффективно, потому что при изменении нескольких тысяч строк, патч становится просто гигантским, и нейронка уже отказывается работать.
Мне очень лень наполнять смыслом сообщения коммитов, которые еще не содержат какого-либо результата и являются либо коммитом просто для персистенции или стэша. Обычно в таких коммитах я ставлю либо +++ либо пишу stash. Потому что он, как отдельно взятый, не будет нести какой-либо ценности, а только в купе с остальными коммитами в фича ветке. Предпочитаю просто сквошить коммиты при слиянии с веткой разработки. Тогда и можно наполнить сообщение коммита смыслом. Хотя для отслеживающих MR/PR сложно понять что изменилось с последнего просмотра.
Очень жду плагин, который будет составлять описание коммита автоматически.
В целом GigaCode уже может делать это через чат, если попросить его, добавив изменения как Patch из гита. (Пример на скринах). Но это все еще не эффективно, потому что при изменении нескольких тысяч строк, патч становится просто гигантским, и нейронка уже отказывается работать.
🔥1
Согласен, поэтому давно пересел на яндекс.диск и гружу все фото с телефона туда. Но что будет с телефонами на андроид и приложениями? Уже сейчас множество приложений не принимают оплату. Или простым и доступным OAuth по гугл учетке практически на любом сайте? Стоит ли беспокоиться разработчикам kotlin? Вопросы, ответы на которые никто не знает, кроме того что "время покажет". Но можно сокращать риски и начинать готовиться :D
Forwarded from Бэкдор
Эксперты уверены, что такой штраф платить никто не будет. Тогда у РКН будет легитимный повод просто обрезать Гуглу работу в стране, а у самого Гугла — закрыть регистрацию по русскому номеру.
Чебурнет не за горами.
Please open Telegram to view this post
VIEW IN TELEGRAM
😢1
Сборщик мусора в .NET Core автоматически управляет выделением и освобождением памяти в приложениях ASP.NET Core, освобождая разработчиков от необходимости вручную управлять памятью. Но очистка неуправляемых объектов требует ресурсов процессора, поэтому нужно уменьшить количество и объем выделения объектов.
Особенно затратной является сборка мусора для больших объектов размером более 85 000 байт, которые требуют полной сборки мусора второго поколения. В отличие от коллекций первого и нулевого поколения, для коллекции второго поколения может требоваться временная приостановка выполнения приложения. Частое выделение и освобождение больших объектов может привести к проблемам с производительностью.
Для предотвращения дорогостоящих операций выделения нужно:
— Кэшировать часто используемые большие объекты.
— Использовать буферы пула с помощью ArrayPool для хранения больших массивов.
— Избегать выделения множества коротких больших объектов в критических участках кода.
Проблемы с памятью можно диагностировать, проанализировав статистику сборки мусора (GC) любым доступным инструментом мониторинга и проверив:
— Время приостановки сборки мусора.
— Процент времени процессора, затраченного на сборку мусора.
— Количество поколений 0, 1 и 2.
Особенно затратной является сборка мусора для больших объектов размером более 85 000 байт, которые требуют полной сборки мусора второго поколения. В отличие от коллекций первого и нулевого поколения, для коллекции второго поколения может требоваться временная приостановка выполнения приложения. Частое выделение и освобождение больших объектов может привести к проблемам с производительностью.
Для предотвращения дорогостоящих операций выделения нужно:
— Кэшировать часто используемые большие объекты.
— Использовать буферы пула с помощью ArrayPool для хранения больших массивов.
— Избегать выделения множества коротких больших объектов в критических участках кода.
Проблемы с памятью можно диагностировать, проанализировав статистику сборки мусора (GC) любым доступным инструментом мониторинга и проверив:
— Время приостановки сборки мусора.
— Процент времени процессора, затраченного на сборку мусора.
— Количество поколений 0, 1 и 2.
Пустая трата времени.
Пытаюсь найти хоть одну статью, написанную настоящим человеком, хотя бы чуть чуть разобравшегося в теме.
Сколько процентов от этого текста написан не нейросетью? Эти узнаваемые общие слова, обтекаемые фразы. Сколько времени потрачу на то, чтобы найти нормальную статью, и найду ли вообще. Процент мусорных текстов невероятно возрос из-за Chatgpt. Поэтому считаю, что в ближайшее пару лет сильно возрастет ценность приватных бложиков, где есть только один, близкий к аудитории эксперт в своей области. А всякие печатные станки в виде шлако-сайтов загнутся из-за потери доверия. Сейчас конечно им удается перехватывать некий трафик из-за ключевых слов, но читая статьи, я скорее всего в дальнейшем буду стараться наоборот избегать этот источник. Получается, что и гугл с Яндексом загнутся, если не переквалифицируются с поиска по всем сайтам, на поиск в блогах, с индексом проверки на наличие нейросетей и достоверность информации.
Пытаюсь найти хоть одну статью, написанную настоящим человеком, хотя бы чуть чуть разобравшегося в теме.
В условиях санкций и ограничений выбор между Android и iOS становится еще более сложным. Пользователям следует учитывать не только технические характеристики и предпочтения, но и возможность долгосрочной поддержки устройства в сложившихся условиях.
В конечном итоге, выбор между Android и iOS в 2024 году будет зависеть от ваших личных потребностей, бюджета и предпочтений, а также от внешних факторов, таких как доступность устройств и санкционные ограничения.
Сколько процентов от этого текста написан не нейросетью? Эти узнаваемые общие слова, обтекаемые фразы. Сколько времени потрачу на то, чтобы найти нормальную статью, и найду ли вообще. Процент мусорных текстов невероятно возрос из-за Chatgpt. Поэтому считаю, что в ближайшее пару лет сильно возрастет ценность приватных бложиков, где есть только один, близкий к аудитории эксперт в своей области. А всякие печатные станки в виде шлако-сайтов загнутся из-за потери доверия. Сейчас конечно им удается перехватывать некий трафик из-за ключевых слов, но читая статьи, я скорее всего в дальнейшем буду стараться наоборот избегать этот источник. Получается, что и гугл с Яндексом загнутся, если не переквалифицируются с поиска по всем сайтам, на поиск в блогах, с индексом проверки на наличие нейросетей и достоверность информации.
Леонид Павлов. "It specialist's tricks"
Сборщик мусора в .NET Core автоматически управляет выделением и освобождением памяти в приложениях ASP.NET Core, освобождая разработчиков от необходимости вручную управлять памятью. Но очистка неуправляемых объектов требует ресурсов процессора, поэтому нужно…
Поднимая вопрос о производительности и оптимизации большого объема данных, могу посоветовать следующие способы оптимизации выдачи API (мыслю конечно в контексте dotnet):
0) GraphQL
Понятно, почему я против того, чтобы фронт решал какие данные из БД ему нужны, и как страдает (исчезает) от этого слой бизнес логики бэкенда, но имеет место быть, и не говорить о нем нельзя.
1) Пагинация
Стандартная тема, скипаем n, берем m элементов из БД. На практике, если используются прослойки, например MediatR, то тут универсальности не добъешься, придется в хэндлере медиатора отдавать IQueryable, что не очень подходит как универсальное code-design решение, которое может выбиваться из устоявшегося стиля подхода существующих зрелых проектов.
2) Поток
Почему-то не очень распространенный подход, но очень классный, в своей простоте. Пока фронт отрисовывает всё поступающие элементы, бэк обрабатывает и выдает все новые, не забивая при этом память, т.к. нет потребности хранить весь ответ. Есть те-же минусы, что и у 1, но при этом очень сильный бенефит который этот минус прикрывает.
3) Сжатие
Можно включить сжатие всех ответов на уровне приложения, но это занимает некоторые ресурсы процессора, если есть возможность настроить для конкретных эндпоинтов то круто (не копал глубоко в настройки этой фичи). Но не думаю что комрпессия будет сильно выиграшнее чем просто gRPC или контракт на Protobuf, где убираются самые повторяющиеся части ответов — названия полей.
4) Заголовок Cache-Control
Думаю что для одного и того-же клиента, врятли сильно изменится информация в выдаче в течение 5 секунд или 5 минут, в зависимости от кейса. А мы сэкономим на валидациях, мапперах и обращениях в БД.
0) GraphQL
Понятно, почему я против того, чтобы фронт решал какие данные из БД ему нужны, и как страдает (исчезает) от этого слой бизнес логики бэкенда, но имеет место быть, и не говорить о нем нельзя.
1) Пагинация
Стандартная тема, скипаем n, берем m элементов из БД. На практике, если используются прослойки, например MediatR, то тут универсальности не добъешься, придется в хэндлере медиатора отдавать IQueryable, что не очень подходит как универсальное code-design решение, которое может выбиваться из устоявшегося стиля подхода существующих зрелых проектов.
[HttpGet]
public async Task<IActionResult> Get([FromQuery] int pageNumber = 1, [FromQuery] int pageSize = 100)
{
return Ok(await _dbContext.Data
.Skip((pageNumber - 1) * pageSize)
.Take(pageSize)
.ToListAsync());
}
2) Поток
Почему-то не очень распространенный подход, но очень классный, в своей простоте. Пока фронт отрисовывает всё поступающие элементы, бэк обрабатывает и выдает все новые, не забивая при этом память, т.к. нет потребности хранить весь ответ. Есть те-же минусы, что и у 1, но при этом очень сильный бенефит который этот минус прикрывает.
[HttpGet]
public async IAsyncEnumerable<DataEntity> GetDataAsStream()
{
await foreach (var item in _dbContext.Datas.AsAsyncEnumerable())
yield return item;
}
}
3) Сжатие
Можно включить сжатие всех ответов на уровне приложения, но это занимает некоторые ресурсы процессора, если есть возможность настроить для конкретных эндпоинтов то круто (не копал глубоко в настройки этой фичи). Но не думаю что комрпессия будет сильно выиграшнее чем просто gRPC или контракт на Protobuf, где убираются самые повторяющиеся части ответов — названия полей.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression(options =>
{
options.EnableForHttps = true;
});
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseResponseCompression();
}
4) Заголовок Cache-Control
Думаю что для одного и того-же клиента, врятли сильно изменится информация в выдаче в течение 5 секунд или 5 минут, в зависимости от кейса. А мы сэкономим на валидациях, мапперах и обращениях в БД.
[HttpGet]
[ResponseCache(Duration = 60)] // кэш на 60 секунд
public IActionResult GetData()
{
return Ok(_dbContext.Datas.ToList());
}
🔥1