WASI 0.3 опубліковано 11 червня 2026 року. Реліз переносить асинхронність у Canonical ABI WebAssembly Component Model через async func, stream<T> і future<T>, завдяки чому компоненти можуть передавати очікування та потоки через свої межі.
Async став частиною контракту
У WASI 0.2 асинхронність часто реалізовував host або окремий runtime adapter. Версія 0.3 дозволяє прямо описати асинхронну функцію у WIT і згенерувати природний async API для цільової мови.
Streams не потребують спільної пам’яті
stream<T> передає послідовність значень через компонентну межу. Це корисно для HTTP body, stdin і stdout, але backpressure та скасування все одно мають бути частиною проєктування застосунку.
Future представляє відкладений результат
future<T> дозволяє компоненту повернути результат пізніше без власного протоколу polling. Головна перевага — готовність може поширюватися через ланцюжок скомпонованих модулів.
wasi:io більше не окремий пакет
Функції колишнього wasi:io перенесено до примітивів Component Model. Через це змінюються WIT imports і generated bindings; просте підвищення номера залежності без перегенерації коду не спрацює.
Міграція може бути поступовою
Hosts здатні підтримувати компоненти 0.2 і 0.3 одночасно, а 0.2 можна адаптувати на межі. Переходити варто тоді, коли потрібна компонована async-модель, а toolchain цільової мови вже стабільний.
Чекліст міграції
- зафіксуйте WIT packages;
- оновіть runtime і bindgen разом;
- перегенеруйте bindings;
- перевірте wasi:http;
- протестуйте backpressure;
- залиште сумісність із 0.2;
- виміряйте latency та пам’ять.
Component Model важливіший за окремий runtime
Огляд TechPulse WebAssembly 3.0 пояснює можливості core specification, а матеріал про serverless-інференс показує, де портативні компоненти можуть спростити cloud workloads.
Перехід на async починається з меж компонента
Позначте всі операції, що можуть чекати: мережу, файли, таймери, черги й виклики host. Для кожної визначте, чи потрібен stream, future або звичайне завершення. Не перетворюйте весь інтерфейс на асинхронний автоматично: це збільшує кількість станів і ускладнює обробку помилок. Контракт має пояснювати, хто створює ресурс, хто його закриває та як скасовується незавершена операція.
WIT-контракти потрібно версіонувати окремо від реалізації
Збережіть поточні world та interfaces як fixture, згенеруйте bindings для всіх підтримуваних мов і перевірте їх компіляцію. Зміна типу, ownership або помилки може бути несумісною навіть тоді, коли назва функції залишилася. Новий контракт запускайте поруч зі старим через чітку версію package. Для ширшої серверної архітектури корисно зіставити межі з матеріалом про WebAssembly поза браузером.
Скасування й backpressure мають бути частиною тестів
Відтворіть повільного споживача, переповнену чергу, розрив з’єднання та скасування користувачем. Producer не повинен безмежно накопичувати дані, а закритий stream — залишати ресурс у host. Перевірте, як помилка передається через кілька компонентів і чи не губиться її контекст. Метрики повинні показувати активні операції, час очікування, скасування й обсяг буферизованих даних.
Runtime і toolchain перевіряють як одну матрицю
Зафіксуйте component tooling, runtime, language SDK, target та preview-рівень. Зберіть однаковий компонент кількома підтримуваними мовами й виконайте contract tests. Не покладайтеся на те, що feature flag із тією самою назвою має однакову семантику в різних реалізаціях. Якщо потрібен fallback, він повинен бути окремим артефактом, а не прихованим downgrade під час запуску.
Міграцію завершує вимірювання корисного ефекту
Порівняйте throughput, p95, пам’ять, startup і кількість одночасних операцій зі старою моделлю. Додайте production shadow run на копії запитів без побічних дій. Розгортайте один сервіс або plugin, спостерігайте за витоками ресурсів і лише потім поширюйте підхід. Збережіть сумісний rollback і дату видалення старого контракту, щоб дві моделі не стали постійною спадщиною.
Чекліст async-компонента WASI
Перевірте success, timeout, cancellation, slow consumer, partial stream, host error і повторний виклик після закриття. Рахуйте відкриті resources до й після тесту. Контракт повинен мати стабільний тип помилки, а runtime — не завершувати весь процес через некоректний компонент. Окремо протестуйте межі buffer і backpressure під тривалим потоком.
Після canary порівняйте latency, throughput, memory і resource leaks зі старою реалізацією. Збережіть WIT, toolchain і runtime versions в артефакті. Якщо користь не підтверджена або ecosystem несумісна, відкладіть перехід без підтримки двох складних моделей назавжди. Дата видалення fallback має бути частиною плану ще до production.
Коли native async ще зарано переносити в production
Блокерами є нестабільний WIT-контракт, різна семантика runtimes, витік resources або відсутність cancellation. Не ховайте проблему за глобальним timeout. Спочатку зробіть мінімальний компонент і доведіть його поведінку негативними тестами.
Go-рішення потребує виміряної переваги та підтримуваного toolchain. Якщо sync-реалізація виконує SLA й простіша в експлуатації, міграцію доречно відкласти до зрілості ecosystem, не створюючи власний несумісний abstraction layer.
Першоджерело: офіційний посібник з переходу на WASI 0.3.
Коментарі
Щоб залишити коментар, увійдіть через Google.