Согласен, поэтому давно пересел на яндекс.диск и гружу все фото с телефона туда. Но что будет с телефонами на андроид и приложениями? Уже сейчас множество приложений не принимают оплату. Или простым и доступным OAuth по гугл учетке практически на любом сайте? Стоит ли беспокоиться разработчикам kotlin? Вопросы, ответы на которые никто не знает, кроме того что "время покажет". Но можно сокращать риски и начинать готовиться :D

Сборщик мусора в .NET Core автоматически управляет выделением и освобождением памяти в приложениях ASP.NET Core, освобождая разработчиков от необходимости вручную управлять памятью. Но очистка неуправляемых объектов требует ресурсов процессора, поэтому нужно уменьшить количество и объем выделения объектов.

Особенно затратной является сборка мусора для больших объектов размером более 85 000 байт, которые требуют полной сборки мусора второго поколения. В отличие от коллекций первого и нулевого поколения, для коллекции второго поколения может требоваться временная приостановка выполнения приложения. Частое выделение и освобождение больших объектов может привести к проблемам с производительностью.

Для предотвращения дорогостоящих операций выделения нужно:

— Кэшировать часто используемые большие объекты.
— Использовать буферы пула с помощью ArrayPool для хранения больших массивов.
— Избегать выделения множества коротких больших объектов в критических участках кода.

Проблемы с памятью можно диагностировать, проанализировав статистику сборки мусора (GC) любым доступным инструментом мониторинга и проверив:

— Время приостановки сборки мусора.
— Процент времени процессора, затраченного на сборку мусора.
— Количество поколений 0, 1 и 2.

Пустая трата времени.

Пытаюсь найти хоть одну статью, написанную настоящим человеком, хотя бы чуть чуть разобравшегося в теме.

В условиях санкций и ограничений выбор между Android и iOS становится еще более сложным. Пользователям следует учитывать не только технические характеристики и предпочтения, но и возможность долгосрочной поддержки устройства в сложившихся условиях.

В конечном итоге, выбор между Android и iOS в 2024 году будет зависеть от ваших личных потребностей, бюджета и предпочтений, а также от внешних факторов, таких как доступность устройств и санкционные ограничения.

Сколько процентов от этого текста написан не нейросетью? Эти узнаваемые общие слова, обтекаемые фразы. Сколько времени потрачу на то, чтобы найти нормальную статью, и найду ли вообще. Процент мусорных текстов невероятно возрос из-за Chatgpt. Поэтому считаю, что в ближайшее пару лет сильно возрастет ценность приватных бложиков, где есть только один, близкий к аудитории эксперт в своей области. А всякие печатные станки в виде шлако-сайтов загнутся из-за потери доверия. Сейчас конечно им удается перехватывать некий трафик из-за ключевых слов, но читая статьи, я скорее всего в дальнейшем буду стараться наоборот избегать этот источник. Получается, что и гугл с Яндексом загнутся, если не переквалифицируются с поиска по всем сайтам, на поиск в блогах, с индексом проверки на наличие нейросетей и достоверность информации.

Поднимая вопрос о производительности и оптимизации большого объема данных, могу посоветовать следующие способы оптимизации выдачи API (мыслю конечно в контексте dotnet):

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());
}

MinimalAPI vs Controllers

Тут мужик сравнил быстродействие эндпоинтов с использованием вышеупомянутых подходов по декларированию и обработке API. Почитал, ничего сверхъестественного не получилось в итоге. MinimalAPI примерно на 8% быстрее отрабатывает, и в 1.5 раза меньше выделяет памяти в процессе запроса.

Но у MinimalAPI есть свои минусы перед обычными контроллерами:
1) В первую очередь самый большой минус исходит из самого большого плюса: ПРОСТОТА. Простая декларация имеет сложности в поддержке, при росте и усложнении проекта, соответственно простой API лучше использовать для простых приложений.
2) Из-за своей небольшой распространенности, имеет меньше примеров и не все разработчики смогут с наскока с ним работать.

Rate Limiter

А еще, вместо того, чтобы бороться с причинами долгой работы API — можно бороться с его последствиями! Для этого просто ограничим пользователей, чтобы они не могли делать много запросов и тогда мы разгрузим мощности для наших неоптимизированных операций!

Нужно всего лишь добавить NuGet:

$ dotnet add package Microsoft.AspNetCore.RateLimiting

И добавить ограничения:

builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("HundredPerSecondPolicy", opt =>
    {
        opt.PermitLimit = 100;
        opt.Window = TimeSpan.FromSeconds(1);
        opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        opt.QueueLimit = 2; 
    });
});

app.UseRateLimiter();

Так мы запрещаем обращаться к нашему апи, если за секунду к нам пришло больше 100 запросов.

Если без шуток, то это правда имеет реальные бенефиты:
* Большое количество запросов может замедлить работу приложения или даже привести к сбоям.
* Помогает остановить атаки методом перебора, ограничивая количество попыток входа в систему или вызовов API.
* Гарантирует справедливое распределение ресурсов API между всеми клиентами.
* Для облачных сервисов с тарификацией за каждый запрос, сокращение количества запросов может помочь снизить расходы.

В этой-же библиотеке есть и более гибкие способы, с линейным распределением и пр., по ограничению запросов (название соответствует политике, подобно Fixed Window Limiting — options.AddFixedWindowLimiter):
1) Token Bucket Limiting — разрешает пакетный трафик путем накопления токенов. Запросы потребляют токены, и когда их не остается — запросы ограничиваются.
2) Sliding Window Limiting — сглаживает распределение запросов, проверяя частоту по скользящему окну вместо фиксированного временного окна.
3) Concurrency Limiting — ограничивает количество одновременных запросов.

Ну и Best Practice:
1) Детализация ограничений: Ограничения в зависимости от клиента, пользователя или IP-адреса. Например, вам могут потребоваться более строгие ограничения для пользователей, не прошедших проверку подлинности, и более мягкие ограничения для доверенных клиентов.
2) Код ответа: При превышении лимитов скорости возвращаются значимые сообщения с кодом состояния 429 Too Many Requests. С добавлением информации о том, когда клиент сможет повторить попытку снова.
3) Заголовки: Используйте заголовки ограничения скорости X-RateLimit-Limit, X-RateLimit-Remaining и X-RateLimit-Reset, чтобы предоставлять клиентам обратную связь об их текущем состоянии ограничений.

DDD

Сколько разных версий схем DDD существует, это просто мое увожение... Каждый рисует кто во что горазд, и везде разные объяснения одних и тех же вещей)))

🤡

Не нашел в истории, хвастался ли я своими NuGet пакетами, но вот они, и у них уже 22к скачиваний 😁

Ой, как неожиданно и приятно (с)

Это не оверинжениринг если:
1. Тебе было весело
2. PM не заметил

Остановите мой ор ахахахха