привет всем, меня зовут 132, и сегодня я приношу вам очень интересную вещь
Причина в том, что команда stackblitz поделилась статьей о вводе-выводе Chrome, который может запускать узел в браузере.
blog.stack blitz.com/posts/intro…
Тогда я поражаюсь четырем, и люди дома и за границей размышляют о возможной внутренней реализации... Потому что они не с открытым исходным кодом, так что...
После нескольких дней исследований я, наконец, понял, о(╥﹏╥)о
Сначала укажите адрес github, каждый может упомянуть pr, нажать звездочку, всех.
Затем я кратко объясню основной принцип этого
Основной принцип реализации
code => service worker(js runtime) => go wasm API
Одним словом, в server worker реализовать js runtime с wasm
Например:
const a = readFileSync('a.js')
Первое, что должно быть уверена, что это JS работает на сервисном работнике, а обслуживающий рабочий играет роль V8
new Function('global', `with(global){
const a = readFileSync('a.js')
}`)
Здесь мы подскажем отсутствие исполненияreadFileSyncAPI, остальная работа, мы должны использовать wasm для реализации этого API, а затем внедрить его в глобальный
wasm действует как ржавчина в deno
js.Global().Set("readFileSync", js.FuncOf(func(this js.Value, args []js.Value) interface{} {
readFile(args[0].String())
return nil
}))
Готово! Основной принцип заключается в том, что просто
Файловая система
Согласно демонстрации stackblitz, они могут читать файловую систему.
const a = readFileSync('./a.js')
На самом деле, если у нас нет файловой системы, доступ./a.jsЯ не могу получить содержимое, так что вот в чем дело
Нам нужно хранить все файлы в памяти при загрузке в первый раз, то есть нужно построить граф зависимостей
Если у вас есть опыт написания инструментов для упаковки, вы обязательно будете знакомы с графом зависимостей, я также ранее имел технический шеринг и подробно рассказывал о нем.
Упрощение такое:
new Map([
['./a.js', buffer],
['./b.go', buffer]
])
При инициализации мы хотим сгенерировать такой граф, который является ключом к нашей реализации файловой системы.
http client
Помимо файловой системы, еще одним важным моментом является http
Хорошая новостьnet/httpПакет имеет хороший уровень поддержки WASI, но есть много вещей, которые до сих пор недоступны
func Download(url string) interface{} {
res, _ := http.Get(url)
buffer, _ := ioutil.ReadAll(res.Body)
body := js.Global().Get("Uint8Array").New(len(b))
js.CopyBytesToJS(body, b)
return body
}
Я продолжаю сообщать об ошибках, я злюсь, поэтому, чтобы сгладить это, мы можем только повторно реализовать http-клиент
Основной принцип заключается в использовании других пакетов сети, неподдерживаемых пакетов полифилла.
Напримерnet/httpМетод http.Get() не поддерживается, мы просто используемnet/http/httputilпакетное моделирование
Здесь много контента, подождите, пока у меня будет время
Сцена веб-контейнера
- webIDE
На этот раз демонстрация stackblitz представляет собой webIDE, потому что вы можете запустить среду выполнения js прямо в браузере и напрямую запустить сервер, поэтому ссылка на сервер сохраняется.
Аналогичные сценарии, такие как предварительный просмотр компонентной реализации, предварительный просмотр lowcode, предварительный просмотр рынка материалов и т. д.
- better worker
На самом деле, веб-контейнер также можно понимать как воркер, расширенный возможностями wasm, вы можете использовать его для выполнения многих вещей, которые нельзя было сделать в предыдущих воркерах.
Например, я отвечаю за базовую архитектуру апплета в компании.Симулятор апплета должен запускать сервер, а затем перезапускать сервер каждый раз, когда он перекомпилируется.Теперь, когда у меня есть труд, я могу завершить работу в браузере. , можно сказать, идеально
- Двойной рабочий изоморфизм
Некоторое время назад была обновлена форма CloudFlare Worker, и я подумал, что бессерверная форма этой формы действительно потрясающая.
Но cloudflare — это среда выполнения js на стороне сервера, и в ней всегда отсутствовал локальный терминал отладки.
Труд может сделать это, мы разрабатываем локально через труд и запускаем онлайн через cloudflare, два рабочих API абсолютно одинаковы и, наконец, достигаем изоморфизма.
Можно сказать, что это самая красивая форма бессерверного
- ssr/esr
esr относительно популярен в последнее время, то есть делать ssr под бессерверной платформой, что то же самое, что и приведенный выше изоморфизм двойных рабочих, представьте, как круто было бы использовать work ssr в среде разработки
Преимущества веб-контейнеров
- Больше не требует от разработчиков внимания к серверу
Особенно для сцены ссср, очень-очень хорошо
- Отлаживать лучше
Chrome devtools — лучшие инструменты отладки
- Экономить деньги
кашель кашель кашель. . .
Ограничения веб-контейнеров
Поскольку рабочая среда реализует среду выполнения js в браузере, основное ограничение исходит от браузера.
- http не может открыть порт
то есть идтиListenAndServeНе работает
- не могу получить доступ к локальным файлам
Web.Dev/файловая система…Этот API выглядит ненадежным
- плохая производительность wasm
Фактически, wasm-версия go в среднем в 30 раз медленнее, чем нативная версия go, и в 10 раз медленнее, чем js.
В основном это вызвано GC go, поэтому в сообществе есть несколько альтернатив, таких как tinygo, который может откатить игру.
Суммировать
Многие люди в сообществе плохо отзываются о веб-контейнерах, например, о том, что они слишком навороченные, например, о низкой производительности и множестве ограничений.
Но я спрашиваю, был ли двухпоточный интерфейсный фреймворк тоже прибамбасами?
Но в итоге получился такой непобедимый продукт, как маленькая программа.
То же самое и с веб-контейнерами, в конце концов, должны быть красивые продукты.
не так много, чтобы сказать
Приходите и лайкните, я поделюсь им снова, когда у меня будет возможность.