Alexei Zenkov

NSG Connect — это не API конкретных библиотек и не обертка над одним SDK. Идея в том, чтобы дать приложению стабильный контракт к инфраструктурным возможностям: авторизация, доставка событий, уведомления, платежи, файлы, чаты, внешние API. А конкретные VK ID, Telegram, APNS/FCM, SMS, YooKassa, S3, MinIO и т.д. становятся заменяемыми коннекторами.

По монетизации видим несколько уровней: облачная платформа, выделенное размещение, on-premise/self-hosted, поддержка, SLA, сопровождение коннекторов и usage-based модель по событиям/запросам/сообщениям. В перспективе возможна и модель единого счета за разных провайдеров, как у агрегаторов, но это, скорее, следующий уровень.

По RPS и нагрузке — да, это отдельная часть платформы. Коннекторы должны уметь работать не только в production-режиме, но и в test/mock-режиме: с заданной задержкой, error rate, rate limit и сценариями деградации. Тогда можно отдельно тестировать саму платформу, маршрутизацию, очереди, retry/fallback, и отдельно — поведение конкретных провайдеров.

Про зависимость от NSG Connect — это, наверное, главный вопрос. Зависимость от платформенного слоя появляется. Но цель как раз в том, чтобы она была управляемой и переносимой, а не скрытой и болезненной. Для этого важны открытые контракты, экспорт конфигурации, self-hosted/on-premise варианты, SDK-only режим, понятная модель владения данными и возможность миграции.

По надежности NSG Connect не должен быть “одной прокладкой, через которую всё падает”. Для критичных сценариев архитектура должна строиться вокруг очередей, retry, idempotency, fallback-маршрутов, circuit breaker, health checks коннекторов, мониторинга и SLA-профилей. То есть приложение публикует событие, а платформа отвечает за доставку с учетом критичности, страны, канала, доступности пользователя и состояния провайдеров.

Панель управления тоже предполагается: проекты, окружения, коннекторы, маршруты доставки, ключи, логи, ошибки, статусы доставки, расходы и счета. На раннем этапе часть этого может быть через config/admin API, но без UI платформа действительно будет восприниматься скорее как техническая прослойка.

Если нужного провайдера нет в списке, есть три варианта: использовать совместимый стандартный коннектор, добавить коннектор силами NSG или подключить его через Connector SDK/Contract. Важный принцип — новый провайдер не должен требовать изменений в приложении.

И полностью согласен про декларативный подход. Логика маршрутизации не должна превращаться в процедурный if/else-код внутри приложения. Приложение должно сказать: “доставить событие”, а правила — страна, тип события, критичность, fallback, retry, провайдеры, SLA — должны жить в конфигурации платформы.

Ссылка на первый лендинг NSG Connect: https://connect.nsgsoft.ru

Интересно проверить на реальном опыте: у кого смена авторизации, платежного провайдера, пушей, чата, облака, хранилища или внешнего API превращалась в отдельный проект разработки? Что оказалось самым болезненным — код, миграция, тестирование, релизы, риски для пользователей или зависимость от конкретного SDK?