Node.js: управление памятью, доступной приложениям, выполняемым в контейнерах

Столкнулся с описанной проблемой на практике в AWS ECS. В моем случае приложение тоже упиралось в порог памяти контейнера, но оставалось работать. При этом, видимо из-за манипуляций с файлом подкачки, генерелись терабайты IO трафика.

Судя по всему, я не один такой — народ скрипты пишет, убивающие контейнеры, застрявшие в подобной ситуации.

Мост из мира .NET в мир JavaScript

Верно, асинхронные вызовы часто используются для подобных задач. Правда, эта идея не столь показательна, если говорить про снижение нагрузки на сервер, однако, в некоторых задачах без нее никуда (та же проверка занятости логина). Для тех, кому интересно как подобное может быть реализовано с помощью Bridge.NET — в этом примере продемонстрировано выполнение Ajax запроса.

По поводу Blazor — безусловно, это интересный фреймворк, и как только Microsoft выведет его из Preview, я думаю, он найдет много последователей. В то же время, и Bridge.NET может занять свою нишу, например, в частности применения binding'ов для существующих JS библиотек, здесь можно посмотреть несколько демок: demos.retyped.com

Проекту Retyped явно есть куда развиваться. Однако уже сейчас для некоторых библиотек предоставлен достаточно годный API. Например, интересно, насколько похожими получились реализация на C# и оригинальный код на JS в данном демо.

Мост из мира .NET в мир JavaScript

Согласен, это один из основных недостатков Bridge.NET. При этом, трудно представить как можно реализовать функции .NET в JS по-другому. Возможно единственное решение проблемы — это разбивка bridge.js на модули. Это позволило бы подключать только те системные классы/библиотеки, которые по факту используются в проекте. Данная функциональность уже давно обсуждается на GitHub.

Сахарный JavaScript

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

Получается, если компилятор указывает на какое-то проблемное место — это можно считать как указание, что следует проанализировать поток данных и добавить необходимую валидацию. Если же проблемное место «закрывается» небезопасным приведением типа (в TypeScript такое тоже есть), или небезопасной инициализацией, как в случае с Number(val), то разработчик сам переносит проблему обратно на стадию исполнения и лишает себя преимуществ строгой типизации.

Guard классы — использовать или нет?

Согласен, nameof сильно облегчил жизнь. Для еще большего упрощения можно было бы воспользоваться Expression и избавиться от аргумента с именем… хотя, наверное, на любителя.

public void Test(object o)
{
    Guard.ArgumentNotNull(() => o);
}

public static class Guard
{
    public static void ArgumentNotNull<T>(Expression<Func<T>> argExpr)
        where T: class
    {
        if (argExpr == null)
        {
            throw new ArgumentNullException(nameof(argExpr));
        }
        
        var arg = argExpr.Compile()();
        if (arg == null)
        {
            var argName = (argExpr.Body as MemberExpression)?.Member.Name;
            throw new ArgumentNullException(argName);
        }
    }
}

Guard классы — использовать или нет?

Думаю, было бы удобно использовать стандартный диалог замены текста с включенной галкой «Use Regular Expressions».

Пример поискового запроса:

^([\t ]*?)Guard.ArgumentNotNull\((\w+), "eventProvider"\);

Пример замены (с сохранением смещения):

$1if ($2 == null)\r\n$1\tthrow new ArgumentNullException("$2");