구성요소 및 Washifill로 웹 어셈블리 갭 메우기

폴리필과 같은 구성요소 어댑터 패턴인 와시필은 빠르게 변화하는 표준 환경과 상호 운용 가능한 구성요소의 미래 사이의 격차를 해소하는 데 도움이 될 수 있습니다.

폴리필과 같은 구성요소 어댑터 패턴이지만 구성요소에 대해서는 와시필 방식을 검토하면 오늘날의 급변하는 표준 환경과 상호 운용 가능한 구성요소의 미래 사이의 격차를 해소하는 데 도움이 될 수 있습니다.

지금은 웹어셈블리 채택 곡선의 최첨단에 있는 놀라운 시기이지만, 위험이 없는 것은 아닙니다.

개발자가 웹어셈블리를 통해 모르도르로 이동하는 과정은 상당히 예측 가능한 패턴을 가지고 있습니다. 먼저, 우리는 와섬이 제국과의 전투에서 강력한 동맹이 될 수 있다는 것을 발견하고 연구를 시작합니다. 먼저 호스트와 게스트 간에 번호를 교환하는 방법을 알아냅니다. WebAssembly에서 호스트와 게스트 간의 관계는 단순합니다. 호스트는 게스트가 호출할 수 있는 기능을 제공하고 게스트는 호스트가 호출할 수 있는 기능을 제공합니다. 이러한 함수는 숫자만 허용하고 반환할 수 있습니다.

호스트-게스트 경계를 넘는 방법을 알게 되면 추가 함수를 작성하고 wasmtime CLI 또는 브라우저의 JavaScript에서 호출할 수 있습니다. 이것은 오랫동안 꺼졌던 뇌의 불을 다시 점화시키고 우리는 더 탐구할 필요가 있다고 결정합니다.

다음으로 전체 구조, 블롭 등과 같은 보다 강력한 데이터를 어떻게 교환할 수 있는지 궁금합니다. 이곳은 우리의 여정이 잘 포장된 길을 떠나는 곳이고 우리는 절망의 늪 어딘가에 있는 우리 자신을 발견합니다. 이것은 출구가 없는 미지의 영역처럼 느껴지지만, 우리는 곧 그것이 미지의 것이 아닌 수백 개의 다른 길들이 있고 어떤 길을 택해야 하는지에 대한 지침이 없다는 것을 발견합니다.

 

 

계약 중심 개발

일부 제품은 WASI를 위해 wasm32-unknown-unknown(이른바 "freestanding" 모듈)을 거래하여 이 문제를 해결합니다. 여기서는 WASI에서 사용할 수 있는 stdio에 대한 액세스 권한을 사용하여 I/O 파이프를 통해 불투명한 데이터 블롭을 교환합니다. 다른 제품 및 프레임워크는 경계를 넘어 데이터를 마샬링하는 자체 방법(ABI 또는 "애플리케이션 이진 인터페이스"라고 할 수 있음)을 고안하고 이러한 인터페이스 위에 전용 라이브러리를 구축합니다. 예를 들어 Open Policy Agent를 사용하면 정책을 WebAssembly로 컴파일할 수 있으며 게스트와 호스트 간의 인터페이스는 OPA와 관련이 있습니다. "Legacy" wasmCloud는 고정된 가져오기 및 내보내기 세트에 의존하는 맞춤형 라이브러리 스타일 인터페이스이기도 합니다.

Wasm 모듈의 가져오기 및 내보내기 조합은 해당 모듈과 해당 호스트 간의 명시적 계약을 나타냅니다. 계약 중심 개발의 큰 이점 중 하나는 계약 설계의 초기 비용을 대가로 얻은 느슨한 결합과 유연성입니다. 그러나 WebAssembly는 게스트/호스트 경계를 넘어 이러한 종류의 느슨한 결합을 위한 준비가 되어 있습니까?

간단한 대답은 '그렇다'입니다. 하지만 현실은 여기 출혈의 가장자리에 예외가 있다는 것입니다. 표준이 변화하고 있으며 웹 어셈블리 엔진에 기능이 이틀에 한 번씩 빠르게 나타나고 있습니다. WebAssembly 구성 요소와 구성 요소 모델이 이 문제의 해결책이지만 구성 요소 모델은 여전히 변동성이 있기 때문에 제품을 제작하는 동안 이러한 변동성으로부터 보호할 수 있는 무언가가 필요합니다. 그 대안은 용암 흐름이 굳을 때까지 단순히 뒤로 물러서서 기다리지만, 그러면 우리는 조기 입양의 모든 이점을 놓치게 됩니다.

이 게시물의 나머지 시간 동안, 저는 채택 곡선을 따라 애플리케이션을 구축하는 동시에 기본 표준인 와시필(wasifill)에 대한 제어를 시행할 수 있는 패턴에 대해 이야기하려고 합니다.

구성 요소를 사용하면 엄격한 결합이 아닌 인터페이스를 통해 통신하는 코드 조각을 스냅으로 결합할 수 있습니다. 구성요소는 다른 구성요소의 실제 구현에 대한 컴파일 시간 의존성이 없으며 계약 경계를 넘어 통신하는 방법만 알고 있습니다. 더 중요한 것은 계약의 반대편에 있는 "물건"이 다른 구성요소이거나 호스트 자체일 수 있다는 점입니다.

예를 들어, 다음 다이어그램에는 와시키 가치 계약의 현재 버전을 사용하는 구성 요소가 있습니다:

구성요소 및 Washifill로 웹 어셈블리 갭 메우기 1

 

이것은 훌륭하지만, 현재 wasi-key value 계약을 기본적으로 지원하는 호스트의 수를 현재 0개를 신뢰할 수 있습니다. 호스트가 구성 요소 언어를 사용할 수 없는 경우 구성 요소로 구성 요소를 구축하려면 어떻게 해야 합니까? 마지막으로, 우리는 와시필에 대해 이야기하게 됩니다. 폴리필이라는 용어를 들어본 적이 있다면 이전 브라우저에서 최신 기능을 제공하는 데 사용되는 코드라는 것을 알 수 있습니다. 본질적으로, 폴리필에는 두 가지 측면이 있습니다: 하나는 현대적이고 하나는 유산입니다. 폴리필 코드는 구세계와 신세계 사이를 변환합니다.

폴리필 및 폴리필 유사 코드의 다른 이름은 프록시, 어댑터 또는 미들웨어일 수 있습니다. 와시필은 레거시 인터페이스를 지원하면서 구성요소 개발자에게 최첨단 구성요소 기능을 제공합니다. 호스트가 wasi-keyvalue를 말하는 방법을 모르지만 키 값 저장소를 요청하는 데 사용할 수 있는 레거시 계약을 지원한다고 가정해 보겠습니다. 다음 다이어그램에서는 구성 요소 코드가 호스트가 무엇을 지원하는지 또는 지원하지 않는지 완전히 알지 못하는 방식으로 와시필을 삽입하는 방법을 볼 수 있습니다. 호스트가 진화함에 따라 구성 요소 코드를 다시 작성할 필요 없이 와시파도 진화할 수 있습니다.

구성요소 및 Washifill로 웹 어셈블리 갭 메우기 2

 

오래된 세계와 새로운 세계 사이에서 번역하는 것 이상으로 와시필의 용도가 있습니다. 우리는 부품에서 모든 전력을 추출하는 데 사용할 수 있습니다. Open AI API와 통신하는 구성 요소를 구축했다고 가정해 보겠습니다. 이를 위해 HTTP를 사용하는 경우 HTTP 클라이언트를 사용해야 한다는 것을 알고 있습니다(계속 변화하는 표준에서 토끼 구멍을 방지하기 위해 i-exp-http라고 부릅니다). 다음 다이어그램은 구성 요소 코드가 wasi-exp-http wasif를 통해 호스트에 도달하는 것을 보여줍니다. 우리의 코드는 또한 Open AI의 일부가 아닌 다른 HTTP 요청을 해야 할 수도 있습니다.

구성요소 및 Washifill로 웹 어셈블리 갭 메우기 3

 

이것은 아마도 지역 테스트에는 괜찮지만, 생산은 완전히 다른 것입니다. 오픈 AI API를 사용하는 것은 일단 몇 가지 실험을 넘어서면 무료가 아닙니다. 우리는 다른 통화를 금지하지 않고 이 API의 사용을 제한하고 싶습니다. 우리가 그것을 하는 동안, 우리는 그것이 Open AI와 대화하는지 여부에 관계없이 구성 요소 네트워크 사용을 추적하고 싶을 수도 있습니다. 다음 다이어그램에서는 와시필을 사용하여 실제 코드와 호스트 사이에 두 가지 새로운 구성 요소를 볼트로 고정했습니다. 즉, Open AI에 대한 액세스를 제어할 수 있는 속도 제한 장치와 모든 아웃바운드 HTTP 호출을 모니터링하여 "이전" 호스트에서 이 코드를 실행할 수 있도록 체인을 와시필로 종료합니다.

구성요소 및 Washifill로 웹 어셈블리 갭 메우기 4

 

코드는 해당 코드와 호스트 사이에 얼마나 많은 개입 구성 요소(Wasiff 또는 기타 구성 요소)가 있는지 알지 못합니다. 로컬 및 테스트 환경에서 코드를 변경하지 않고 실행한 다음 "현대" 호스트에서 미들웨어 및 와시필 없이 실행할 수 있으며, 프로덕션 환경에서 미들웨어 및 와시필로 실행할 수 있습니다. 이 모든 것이 코드를 변경하지 않고 가능합니다.

 

 

마무리

이 게시물을 통해 오늘 Wasm 구성 요소에 대한 작업을 시작할 수 있습니다. 마찰력이 높을 수도 있지만, 와시필을 사용하여 휘발성 표준과 아래의 런타임 변경으로부터 우리를 절연시킴으로써 가능합니다. Wasm 생태계가 "모든 것이 위트를 말해준다"는 궁극적인 목표를 향해 나아감에 따라, 우리는 궁극적으로 우리의 구성 요소와 우리의 목표 런타임이 주입하고자 하는 미들웨어가 될 때까지 점점 더 많은 폐기물을 제거할 수 있습니다.

올해 남은 기간 동안 웹어셈블리의 세계는 놀라울 정도로 흥미로울 것입니다. 애플리케이션을 구축할 때 WebAssembly를 언급하는 사람이 아무도 없는 세상에 빠르게 다가가고 있습니다. 즉, 필요한 것을 쓰기만 하면 Wasm은 툴링과 표준을 통해 중요하지 않게 된 구현 세부 사항에 대해 스스로를 포기합니다.