😜 Есть такой эффект, и я иногда чувствую вину за его распространение: человек только осваивает язык и платформу, но попадает на сложную лекцию о том, как все устроено внутри, о недокументированных функциях, оптимизациях, высоконагруженных и распределенных системах, многопоточности, сборке мусора, метапрограммировании, ивентлупе и т.д. и вот ему дают задачу (или он сам себе ее ставит) например: «сделать апи для получения с сервера списка городов» и тут он вспоминает про асинхронные генераторы, бекпрешер в стримах, про инверсию управления и начинается... нужно все сделать по науке, чтоб миллион пользователей пришло и что будет, если каждый 10 раз в секунду будет выкачивать список, в котором сотни тысяч записей, а может быть давайте не в JSON слать, а придумаем для этого бинарный протокол и сэкономим на кавычках и запятых, будем строки разделать байтом FF, и обязательно предусмотреть отмену получения списка и докачку, если соединение разорвалось с того же места и чтоб кеширование работало, но была возможность принудительно кеш обновлять... А если справочник меняется, то нужно вебсокетами присылать изменения, нужно придумать в каком формате, и таймаут держать в памяти, что если докачка не началась в течении 5 минут, то уже не начнется, а если соединение восстановлено, но мы подключились к другому процессу или потоку, а если сервер перегрузился нужно же... и это бесконечно, так складывание двух чисел можно защищать от влияния космических лучей... я уже не говорю про микротесты и нагрузочные тесты, которые непременно нужно нужно гонять пару часов. Ну... все это... конечно способствует освоению платформы, это интересно и через пару лет может дать полезные результаты и я не хочу отговаривать от экспериментов, но признайтесь себе, сколько будет пользователей, данных и интенсивности через год, два, три, прикиньте грубо, ну на 2 можно умножить и дать себе отчёт в действительных целях своего R&D

👩‍💻 Документация к библиотекам и платформам обычно так делается, чтоб примеры были короткие и ради краткости в них смешивают в небольшом фрагменте код, который не должен даже в одном файле находиться. Примеры наглядные, но они попадают в руки людям без опыта архитектуры систем и без понимания архитектурных границ, зацепления, закона Деметры, слоев абстракции... и, если они приведены в доке, то их просто копипастят, и такие примеры потом можно встретить в реальных проектах, так что, какие примеры в доках, такие и проекты будут.

🖼 За эту неделю я потратил порядка 6 часов и написал около 70% документации по Метархии. Примеры в ней и короткие и понятные и копипастить их можно. Потому, что Метархия сразу так разрабатывалась, чтобы нужно было меньше знать про ноду, про архитектуру и про паттерны, а заниматься исключительно предметной областью. Вот тут можно посмотреть то, что есть на текущий момент и предложить правки, а к понедельнику будет все полностью: https://github.com/metarhia/Docs

🖼 Технологический стек Metarhia теперь с документацией и готовится курс быстрой разработки и примеры приложений. https://github.com/metarhia/Docs 🎉

∙ Первый сервер приложений для Node.js с масштабированием потоками
∙ Поддержка изоляции выполнения между пользователями и запросами
∙ Автоматическая маршрутизация API-вызовов к API эндпоинтам
(нет необходимости добавлять маршруты вручную)
∙ Тайм-ауты и очередь выполнения запросов с ограничением ожидания
∙ Схемы для контрактов API, авто-валидация структур данных и моделей
∙ Поддержка нескольких протоколов: HTTP, HTTPS, WS, WSS
∙ Разные стили API: RPC через AJAX и через Websocket, REST и веб-хуки
∙ Обновление кода и SSL сертификатов на лету, без перезагрузки процесса
∙ Автозагрузчик модулей и graceful shutdown с хуками start и stop
∙ Авто-генерация пространств имен для кода и зависимостей
∙ Минимум как прикладного кода, так и кода платформы, нет зависимостей
∙ Слоеная архитектура: api, бизнес-логика, доступ к данным, системный код
∙ Песочницы для улучшенной безопасности и изоляции контекстов выполнения
∙ Предотвращение загрязнения глобального контекста, загрязнения ссылками
∙ Встроенный балансировщик с перенаправлением на порты воркеров
∙ Кеширование в памяти для API и статических файлов
∙ Автозагрузка конфигов с вариантами для разного окружения
∙ Слой доступа к базе, совместимый с PostgreSQL, с защитой от инъекций
∙ Персистентные сессии с аутентификацией, группами или анонимные
∙ Буфферизованный лог (ленивая запись) с ротацией (хранение N дней)
∙ Интегрированный нативный тест раннер node.js и табличными тестами
∙ Утилиты для файлов: загрузка, скачивание, partial-content и потоки
∙ Планировщик для выполнение задач в определенное время

🖼️ Вчера вышла Node.js 21.1.0 которая стала Current до 1 апреля.
И Node.js 20.9.0 которая стала LTS, теперь 20.x будет LTS ровно год.
А Node.js 18.x перешла в режим maintenance
⚡️ Основная новость, что WebAPI продолжает портироваться в Node.js и к нас приехал Websocket https://github.com/nodejs/node/pull/49830
Но для тех, кто уже радуется, спешу разочаровать, это не серверная реализация, а клиент протокола. Будет ли сервер, пока неизвестно.
Клиент Websocket тоже будет доступен без флага ближе к весне, а ожидать его в LTS можно через год. Ну а так, чтобы клиент был доступен во всех поддерживаемых версиях ноды, то это аж весной 2025.

🖼️ На курсе по Node.js пишем Websocket сервер, прототип тут: https://github.com/HowProgrammingWorks/Websocket/blob/main/NodeJS/server.js

🖼️ Вместо npm пакета в package.json можно указывать github репозиторий или отдельную его ветку. Вот пример:
"dependencies": {
  "metacom": "metarhia/metacom#node21"
...
Тут metarhia - организация или личный аккаунт, metacom - имя репы, node21 - ветка или тег.

🖼 Куда идет Metarhia: В мире Java и C# все решают платформы и большие технологические стеки типа hibernate. Где-то они идут как зависимость, но безальтернативная, а где-то как часть платформы, но основной смысл - в них все продумано, есть решения для всего и программирование переходит на уровень прикладных задач, потому, что все системные уже решены в платформе. В мире node.js такого нет, тут десятки тысяч библиотек, которые не согласованы друг с другом, но их в принципе можно заставить работать вместе. Вот программисты и занимаются 80% времени тем, что их связывают, налаживают, оборачивают и согласовывают. То логгер отпал, то конфиг поскользнулся, то роутинг разлетелся, то валидация отпала. Все это из-за версий, прекращения поддержки библиотек, появления новых, изменения в политике библиотек, их же авторы делают под себя и свои нужды, которые меняются. Собирать заведомо несовпадающие пазлы при помощи ножниц и клея - такая себе затея, в каждый момент времени она решаема, но все рассыпается в руках, поддерживать это очень сложно. Метархия готовит инфраструктуру, в которой вам нужно будет знать минимум и настраивать минимум, даже знаний по ноде нужно будет в десятки раз меньше, чем на чистой ноде писать, не говоря уже про разные зависимости. Все писало стак, чтобы было нужно минимум документации, минимум примеров. Но забудьте про то, что вы сможете решить задачу так, как вы привыкли ее решать, для всего есть готовые решения, их минимум, но все их нужно освоить со старта, и это составляет целостный инструментарий для проектов класса "информационная система", то есть, есть база данных, есть апи и доменная логика. Таких систем самое большое количество, конечно можно делать и игры и колаборативное редактирование и стриминг и чаты и уже даже для публикации контента многое сделано, но есть основное направление платформы и она будет затачиваться под 3-4 типа приложений, их уже сейчас можно делать в 100 раз быстрее, чем на фрейворках типа nest.js, потому, что мы берем идею цельной платформы их Java и C#, но не берем весь кровавый энтерпрайз, а делаем все легковесным, даже DDD и чистая архитектура у нас реализуются максимально компактно и без оверинженеринга. Доку можно прочитать за 30 минут всю https://github.com/metarhia/Docs До конца месяца будет готов пример достаточно сложного приложения и видео-курс с разбором его разработки за один день одним человеком.