В последнее время многие блокчейн-платформы для исполнения смарт-контрактов переключились на WASM — WebAssembly. Мы не стали исключением, и в последнем обновлении тоже добавили WebAssembly как альтернативу привычному Docker. В этом посте мы расскажем, для каких задач нам потребовался именно WASM, что мы достигли с ним на сегодня и как WASM отражается на производительности блокчейна.
В начале года на YouTube-канале DevOps Toolkit вышло видео с разбором WebAssembly. Автором ролика является Виктор Фарчич (Viktor Farcic) — developer advocate в Upbound, член CNCF Ambassadors, Google Developer Experts, CDF Ambassadors и GitHub Stars.
Мы перевели видео про WebAssembly в текстовый формат и адаптировали для лучшего понимания. В нём автор разбирает, что такое WebAssembly, стоит ли использовать его в браузерах и кластерах Kubernetes или вообще заменить Kubernetes и прочее.
Автор статьи Жерар Галлан известен как автор книги “WebAssembly in Action”, выпущенной Manning в 2018 году. Существует перевод его книги на русский “WebAssembly в действии” (Питер, 2022). Предыдущий обзор Состояние WebAssembly в 2022-23 годах опубликован автором в январе 2023 года. — Прим. переводчика.
Добро пожаловать в 2024 год и в нашу статью о текущем состоянии WebAssembly (Wasm)! В этой статье я займусь тем, что посмотрю, что произошло в 2023 году. Затем я выскажу свои мысли о том, что может произойти в текущем году.
В жизни каждого инженера-фронтендера наступает момент, когда осознаёшь: далее не обойтись без кэширования данных из API. Всё может начаться с самых невинных вещей: сохраняем предыдущую страницу с данными, чтобы кнопка «Назад» срабатывала мгновенно; реализуем простенькую логику отмены действия или обеспечиваем слияние нескольких состояний от различных запросов к API. Но все мы знаем, чем такое кончается. Один за другим возникают запросы на новые фичи, и вскоре мы уже не покладая рук реализуем кэши данных, индексы для работы вручную, оптимистические мутации и рекурсивную инвалидацию кэша.
Эти фичи явственно смахивают на внутренние механизмы баз данных. Действительно, в любом достаточно сложном клиентском приложении программисту непременно придётся реализовывать такое множество фич для управления данными, что эта работа будет напоминать построение предметно-ориентированной базы данных. Такая дополнительная сложность удваивается в каждом проекте, над которым мы работаем, поэтому приходится тратить время на решение бизнес-проблем, а радовать пользователя – уже как успеем.
Поэтому сегодня предлагаю вам составить мне компанию – и мы вместе рассмотрим распространённые паттерны работы с данными приложений, а также разберёмся, как они соотносятся с фичами баз данных. Далее мы рассмотрим решения, которые могли бы стать альтернативами этим паттернам – например, как сделать в клиентской части оптимизированный стек базы данных, который позволил бы нам сосредоточиться на разработке приложения, а не на мелкой возне с данными.
Hello world!
На днях я баловался с WebAssembly и получил довольно неожиданные результаты, которыми и хочу с вами поделиться в этой небольшой заметке.
Хорошо, если вы знаете JS/Node.js и хотя бы слышали о WASM и Rust.
В последнее время фронтенд все больше и больше обрастает новыми технологиями, одна из них — WebAssembly. На ней можно написать полноценное web‑приложение и почти все на что способна ваша фантазия. В статье мы рассмотрим, что такое WebAssembly, как работает и с чем её едят. И конечно же я хотел поделиться рецептом приложения. Возьмем наш любимый React и добавим Yew, приправим всё это webpack-ом и добавим щепоточку module‑federation. Статья будет интересна всем, кто хочет познакомиться с WebAssembly и добавить разнообразия в список используемых фреймворков и библиотек для написания пользовательских компонентов.
Статья показывает опыт использования .NET из JavaScript (React) с помощью компиляции .NET кода в WebAssembly с помощью новых возможностей .NET 7. Включает инструкцию по созданию проекта для .NET для использования из Javascript, и интеграции его в веб-приложение, написанного с использованием React. Рассматривается также сборка такого проекта с помощью GitHub Actions (CI) и хостинг его на GitHub Pages. Содержатся ссылки репозитории на GitHub тестового и реального проекта, использующие данный подход.
Как разработчик TeaVM, компилятора байт-кода JVM в JavaScript и WebAssembly, я часто рекомендую пользователям, почему-то жаждущим сгенерировать WebAssembly, начать с JavaScript. Если честно, бэкэнд WebAssembly я очень давно не развиваю, не реализую в нём недостающих фич и не фикшу баги. Меня спрашивают: а почему так? Обычно, я просто игнорирую подобные вопросы, потому что в двух предложениях ответить на них невозможно, а для того, чтобы писать больше предложений, у меня нет времени. Обычно если я встречаю чьи‑то попытки объяснить, чем WebAssembly плох для реализации JVM (а так же, CLR, JavaScript и прочих динамических сред), то они сводятся к следующему: «Java (.NET, JavaScript, ваш вариант) — это управляемый язык со сборкой мусора и исключениями, так что приходится тащить с собой гигантский рантайм». Что же, на самом деле, ситуация несколько сложнее, а размер рантайма вовсе не такой страшный и не является основным источником бед.
Общая тенденция развития технологий характеризуется рывками и спадами. Рассмотрим, например, массовое перемещение человеческих тел. Изначально применялись лошади и повозки, которые постепенно стали сложными, и эта технология превратилась в отдельную индустрию. Затем внезапно появились поезда. Про лошадей быстро забыли, и фокус сместился на новое направление. Пар стал объектом исследований и превратился в сложную науку. Параллельно развивались дизель и электричество. В определенный момент паровые двигатели ушли в прошлое, и все перешли на дизель и электричество. Аналогично сейчас происходит переход на электромашины, требующие значительно меньшего количества жидкостей.
Технологии эволюционируют и функционируют, а новые технологии их полностью заменяют. Считаю, что сейчас наступает эпоха, когда технологии фреймворков и Электрона могут быть вытеснены генеративными AI. Рассмотрим несколько примеров.
python.wasm, который можно использовать для выполнения скриптов на Python при помощи WebAssembly, чтобы обеспечить повышенную защиту и портируемость.python.wasm.
Привет, коллеги.
На самом деле ещё несколько месяцев назад я ненавидел Rust и задавался лишь одним вопросом: какого чёрта я вообще с ним связался? Но сегодня - сегодня всё иначе. И про это я хочу предложить немного доводов разобрать с ним.
Он быстрый. Конечно не в смысле разработки и отладки (особенно поначалу), а в плане работы. Код, написанный на нём, в некоторых вопросах существенно быстрее аналогичного кода, написанного на других языках программирования. Нисколько не хочу обидеть адептов других религий языковых предпочтений (уверен, вы с лёгкостью докажете, что это не так). Однако предложенные мне тесты показали, что он немного, но шустрее.
Он безопасный. Это, правда, не совсем так, но если взять условного новичка, который напишет программу на C и условного новичка, который напишет программу на Rust - шанс, что вторая выйдет более безопасной окажется существенно выше. По крайней мере, атака через переполнение буфера, почти гарантировано, провалится (не станем отрицать наличие дарований, которые даже там, где это почти невозможно, смогут заложить уязвимость).
Он необычный. Уверен, вы сталкивались со странными языками программирования. Такими, которые ломают привычную парадигму и заставляют мыслить иначе. Например, люди, всю жизнь работающие с объектно-ориентированным подходом, нередко, теряются, когда сталкиваются с функциональным программированием, т.к. там иной подход. Да даже далеко ходить не надо; столкновение с попыткой воспользоваться OpenGL из привычного C++, в какой-то момент, рвёт все шаблоны и в воздухе повисает лишь два вопроса: "какого..." и "зачем вы так со мной". Это, разумеется, проходит, но не сразу.
«Если бы WASM+WASI существовали в 2008 году, нам бы не пришлось создавать Docker. WebAssembly на сервере — будущее компьютерных технологий», — считает Соломон Хайкс, соучредитель корпорации Docker и автор Docker Open Source Initiative.
Сравнительно недавно Docker объявил о поддержке WebAssembly на базе WasmEdge. А мы перевели фундаментальный, но практичный материал о том, как пользоваться этой технологией в экосистеме Docker и чем Wasm-контейнер отличается от классического.
Здравствуйте, товарищи! Хочу написать a good story про то, как портировал нейросеть в браузер.
Задача пришла ко мне от моих институтских друзей из ИВМ РАН. Есть некий фронтенд, на который доктор загружает КТ снимок. Доктору предлагается при помощи веб интерфейса выделить сектор с сердцем, который будет передан на сервер, где алгоритмически отсегментируется граф аорты для последующего анализа.
Меня попросили сделать нейросеть для выделения 3d сектора с сердцем, а затрачиваемое время не должно превышать 2-3 секунд.
Гонять весь КТ снимок на сервер только за координатами накладно, т.к. КТ снимок обычно состоит из 600-800 кадров размера 512 * 512 пикселей, поэтому мое предложение о браузерном варианте пришлось кстати.
Всем здравствуйте. Ниже будет приведен пример написания PWA приложения готового для использования как в браузере, так и на компьютере с ОС Windows. Используется язык программирования Rust и фреймворк eframe (egui). В результате получим исполняемый файл для ОС Windows, и файл Webassembly. В процессе работы будет использоваться GitHub Action для отслеживания корректности написания нашего кода и сборки исполняемых файлов программы, а также для развертывания (версию программы с использованием Webassembly) как страницы в интернете (GitHub Pages).
В этой небольшой заметке предлагается рассмотреть несколько способов компиляции модуля для WebAssembly, используя три разных подхода. Мы реализуем решение одной и той же задачки на трёх языках и скомпилируем полученный код в модуль WebAssembly. Будем использовать:
Emscripten для компиляции кода, написанного на С++
AssemblyScript для компиляции кода, написанного на, собственно, AssemblyScript
wasm-pack для компиляции кода, написанного на Rust
План такой:
Во введении мы обсудим постановку задачи и немножко поговорим о технологии WebAssembly
В программной части мы реализуем функциональность модуля на трёх языках: c++, AssemblyScript и Rust. Поговорим о том, какие при этом возникают сложности и как их можно обойти
Подведём небольшой итог. Станет видно, какая технология хорошая, а какая не очень
В конце планируется два бонуса. Первый бонус - это пример простого web-приложения, использующего один из скомпилированных нами модулей. Второй бонус - демонстрация того, как этот модуль можно использовать в программе на Python.
