Cloudflare Workers hiện có thể viết bằng Python

 (blog.cloudflare.com)
3 điểm bởi GN⁺ 2024-04-03 | 1 bình luận | Chia sẻ qua WhatsApp
  • Cloudflare Workers hỗ trợ viết bằng Python dưới dạng open beta, mở rộng mô hình vốn xoay quanh JavaScript bằng cách tích hợp trực tiếp Pyodide vào workerd, runtime Workers mã nguồn mở
  • Python Workers hỗ trợ ngay từ ngày đầu các binding hiện có như Vectorize, Workers AI, R2, Durable Objects, đồng thời có thể import một số package Python như FastAPI, Langchain, Numpy
  • Nền tảng triển khai dựa trên Pyodide, bản port WebAssembly của CPython; thông qua FFI giữa JavaScript và Python, mã Python có thể xử lý Request, Response, Fetch API và các binding tài nguyên của Cloudflare
  • Cloudflare chạy import tại thời điểm triển khai và tạo snapshot bộ nhớ tuyến tính WebAssembly để giảm chi phí khởi tạo Pyodide và package, qua đó hạ cold start của Python Worker cơ bản xuống dưới 1 giây
  • Phiên bản Python cùng các bản cập nhật Pyodide/package được quản lý bằng Compatibility Dates và Compatibility Flags; Worker còn ở một bản phát hành Python đã hết thời hạn hỗ trợ 5 năm sẽ tự động được chuyển sang bản phát hành Python cũ kế tiếp

Open beta Python Workers

  • Python Workers hiện có thể dùng dưới dạng open beta trên Cloudflare Workers
  • Khác với các hỗ trợ ngôn ngữ ngoài JavaScript trước đây, phần triển khai Python được tích hợp trực tiếp vào runtime workerd
  • Các binding Cloudflare được hỗ trợ ngay từ ngày đầu bao gồm:
  • Python Workers có thể import một số package Python phổ biến như FastAPI, Langchain, Numpy
  • Không cần bước build riêng hay toolchain bên ngoài

Chỉ biên dịch sang WebAssembly là chưa đủ

  • Workers đã hỗ trợ WebAssembly từ năm 2018, và mỗi Worker chạy trong V8 isolate, tức engine JavaScript giống Chrome
  • Về nguyên tắc, nhiều ngôn ngữ, gồm cả Python, có thể chạy trên Workers nếu trước hết được biên dịch sang WebAssembly hoặc JavaScript
  • Ứng dụng thực tế cần nhiều hơn việc chạy “hello world”, và việc hỗ trợ hệ sinh thái package mà lập trình viên quen dùng là rất quan trọng
  • Python Workers là hình thái ban đầu trong nỗ lực hỗ trợ các ngôn ngữ ngoài JavaScript như công dân hạng nhất trên Workers

Luồng thực thi của Python Worker

  • Khi Pyodide được tích hợp vào workerd, Python Worker có thể xử lý request bằng handler on_fetch
  • Trong wrangler.toml, chỉ định file .py làm main và đặt compatibility_flags = ["python_workers"]
  • Khi chạy npx wrangler@latest dev, runtime Workers xử lý các việc sau:
    • Xác định phiên bản Pyodide cần thiết dựa trên compatibility date
    • Tạo isolate cho Worker và tự động inject Pyodide
    • Cung cấp mã Python cho Pyodide
  • Môi trường thực thi Python được xử lý nội bộ và do nền tảng cung cấp, tương tự JavaScript Workers

Vì sao Pyodide phù hợp với Workers

  • Pyodide là bản triển khai port CPython sang WebAssembly, diễn giải mã Python mà không biên dịch trước sang định dạng khác
  • Cung cấp phần lớn thư viện chuẩn Python, đồng thời cung cấp giao diện hàm ngoại lai (FFI) cho phép gọi JavaScript API từ Python
  • Được thiết kế để build interpreter lõi và từng module Python native thành các module WebAssembly riêng biệt, có thể liên kết động ở runtime
  • Nhiều Workers chạy trên cùng một máy có thể chia sẻ code footprint của module, điều này quan trọng với môi trường Cloudflare chạy hàng nghìn Workers trên mỗi máy
  • Phần lớn ngôn ngữ nhắm đến WebAssembly hiện vẫn chưa hỗ trợ liên kết động, nên mỗi ứng dụng thường phải chứa bản sao runtime ngôn ngữ riêng của mình

Pyodide và liên kết động WebAssembly

  • Vì WebAssembly là môi trường sandbox tách khỏi host runtime, các tác vụ ngoài tính toán thuần túy như đọc file phải do môi trường runtime cung cấp và module phải import
  • Target WebAssembly của LLVM được chia thành ba loại:
    • wasm32-unknown-unknown: không cung cấp thư viện chuẩn C hay giao diện system call
    • wasm32-wasi: sử dụng giao diện hệ thống chuẩn do runtime WASI triển khai
    • wasm32-unknown-emscripten: định nghĩa các import cần thiết và xuất kèm thư viện JavaScript triển khai chúng
  • Pyodide dùng Emscripten để cung cấp interpreter CPython, FFI Python-JavaScript và các package Python bên thứ ba được biên dịch sang WebAssembly
  • Trong các target này, hiện chỉ Emscripten hỗ trợ liên kết động
  • WASI chưa hỗ trợ trừu tượng liên kết động dlopen/dlsym mà CPython sử dụng

FFI nối Python và JavaScript

  • Ví dụ Python Worker lấy Response của JavaScript bằng from js import Response
  • FFI của Pyodide cho phép Python truy cập mọi tính năng JavaScript, giúp giảm vấn đề Python Workers thua kém JavaScript Workers về mặt tính năng
  • Các kiểu bất biến như chuỗi và số được chuyển đổi trong suốt giữa hai ngôn ngữ, còn object có thể thay đổi được bọc bằng proxy phù hợp
  • Khi một object JavaScript được truyền sang Python, Pyodide kiểm tra các protocol JavaScript mà object đó hỗ trợ và cấu thành động một class triển khai protocol Python tương ứng
    • Nếu hỗ trợ protocol lặp của JavaScript thì cũng hỗ trợ protocol lặp của Python
    • Nếu là Promise hoặc thenable thì trong Python trở thành object awaitable
  • Trong luồng xử lý request, object JavaScript Request đi vào cũng được bọc thành JsProxy mà mã Python có thể truy cập, còn giá trị trả về của handler Python được chuyển đổi thành object JavaScript Response

Liên kết động và package Python

  • Nhiều package Python nạp thư viện native thông qua C FFI, và để hoạt động trong runtime Workers thì các thư viện này phải được biên dịch sang WebAssembly
  • Pyodide được build bằng Emscripten để override C FFI của Python; khi package cố tải thư viện native, runtime Workers sẽ tải module WebAssembly do nó cung cấp
  • Liên kết động cho phép Pyodide hỗ trợ nhiều package Python có phụ thuộc thư viện native
  • Liên kết tĩnh phải tải toàn bộ mã cần thiết trước khi chạy binary, còn liên kết động là cách chỉ trả chi phí khi cần
  • Workers tạo cho mỗi Worker một filesystem trông giống bản phân phối Python ở runtime, nhưng các file nền tảng được chia sẻ giữa các Workers
  • Hiện tại, file được chia sẻ giữa các Workers nhưng vẫn được sao chép cho mỗi isolate mới; trong tương lai, họ cho rằng có thể chia sẻ nhiều underlying resource hơn bằng kỹ thuật copy-on-write

Hỗ trợ thư viện HTTP client và server

  • Python có nhiều thư viện HTTP client như httpx, urllib3, requests, nhưng chúng không hoạt động mặc định trong Pyodide
  • Các thư viện này dùng socket thô, trong khi mô hình bảo mật của trình duyệt và CORS không cho phép điều đó, nên trong runtime Workers cần một cách khác

  • Client bất đồng bộ

    • Các thư viện có thể gửi request bất đồng bộ như aiohttp và httpx có thể dùng Fetch API của Workers
    • Cloudflare patch các thư viện bằng Pyodide FFI để chúng dùng Fetch API của JavaScript
    • Bản patch httpx gồm chưa đến 100 dòng code

  • Client đồng bộ và giới hạn

    • Nhiều Python API là đồng bộ, và trong trường hợp này không thể trực tiếp dùng Fetch API bất đồng bộ
    • urllib3 đã nhận đóng góp để hỗ trợ trình duyệt Pyodide, sử dụng Atomics.wait() và fetch worker thread, hoặc XMLHttpRequest đồng bộ
    • Cloudflare Workers hiện không hỗ trợ worker threads và XMLHttpRequest đồng bộ, nên hai cách tiếp cận này không hoạt động trong Python Workers
    • Hiện tại chưa hỗ trợ request đồng bộ

  • WebAssembly Stack Switching

    • WebAssembly có một đề xuất stage 3 bổ sung khả năng chuyển đổi stack, và V8 đã có triển khai
    • Các contributor của Pyodide đã bổ sung hỗ trợ stack switching từ tháng 9/2022 và tính năng này gần như đã sẵn sàng
    • Khi hỗ trợ này được đưa vào, run_sync của Pyodide có thể block để chờ awaitable hoàn tất, mở ra hướng hỗ trợ request đồng bộ

FastAPI và ASGI

  • FastAPI là thư viện được dùng nhiều để định nghĩa server Python, và sử dụng giao thức ASGI
  • Ứng dụng FastAPI không trực tiếp đọc hoặc ghi socket; thông thường một ASGI server như uvicorn sẽ đảm nhiệm việc xử lý socket thô
  • Nhờ cấu trúc này, FastAPI có thể chạy trên Cloudflare Workers mà không cần patch hoặc thay thế chính FastAPI
  • Chỉ cần thay uvicorn bằng một ASGI server có thể chạy bên trong Workers
  • Bản triển khai ban đầu nằm trong asgi.py của workerd, và được đưa vào fork Pyodide do Cloudflare duy trì
  • Cloudflare dự định bổ sung thêm tính năng và test coverage rồi upstream lên Pyodide

Import gói Python

  • Python Workers hỗ trợ một số gói Python do Pyodide cung cấp trực tiếp
  • Các gói được hỗ trợ gồm numpy, httpx, FastAPI, Langchain và các gói khác
  • Để import gói, hãy thêm tên gói vào requirements.txt mà không kèm số phiên bản
  • Phiên bản cụ thể của gói do Pyodide trực tiếp cung cấp
  • Hiện tại có thể dùng gói trong quá trình phát triển local, và trong vài tuần tới sẽ có thể deploy Workers với các dependency được định nghĩa trong requirements.txt
  • Cloudflare cho biết sẽ duy trì fork Pyodide riêng để cung cấp các patch dành riêng cho runtime Workers, đồng thời đưa các thay đổi lên upstream Pyodide

Cold start và memory snapshot

  • Bản thân Pyodide có kích thước 6.4MB, và các gói Python cũng có thể khá lớn
  • Nếu đưa nguyên Pyodide vào Worker rồi upload lên Cloudflare, chi phí load isolate mới sẽ lớn, khiến cold start chậm
  • Trên máy tính nhanh và mạng tốt, Pyodide mất khoảng 2 giây để khởi tạo trong trình duyệt, gồm 1 giây cho mạng và 1 giây cho CPU
  • Khi chạy npx wrangler@latest deploy, quá trình deploy hoạt động như sau
    • Wrangler upload code Python và requirements.txt lên Workers API
    • Runtime Workers xác thực code Python và các dependency
    • Tạo isolate mới và tự động inject Pyodide cùng các gói được chỉ định
    • Quét và thực thi các câu lệnh import trong code Worker, rồi tạo snapshot bộ nhớ tuyến tính WebAssembly của Worker
    • Deploy snapshot này cùng code Python lên mạng lưới Cloudflare
    • Thực thi top-level scope giống như JavaScript Worker
  • Khi có request đến, snapshot này được load để bootstrap Worker trong isolate, nhờ đó tránh được chi phí khởi tạo đắt đỏ
  • Cold start của Python Worker cơ bản giảm xuống dưới 1 giây

  • Tái sử dụng snapshot

    • Hiện tại snapshot bộ nhớ được tạo khi upload Python Worker là riêng cho Worker đó, và không thể chia sẻ với các Python Workers khác dù phần lớn nội dung giống nhau
    • Cloudflare cho rằng có thể tạo sẵn một snapshot dùng chung duy nhất và nạp trước vào pool pre-warmed isolate nơi runtime Pyodide đã được load
    • Với cách này, Python Worker cũng tiến gần hơn tới mô hình runtime được cung cấp on-demand như JavaScript Worker
    • Cloudflare xem việc tái sử dụng snapshot là biện pháp lớn nhất để tiếp tục giảm cold start trong phần còn lại của năm 2024

Quản lý phiên bản Python bằng Compatibility Dates

  • Cloudflare Workers có mô hình kỳ vọng rằng một Worker đã deploy một lần sẽ tiếp tục chạy mà không cần cập nhật
  • Tính ổn định này được cung cấp thông qua Compatibility Dates và Compatibility Flags
  • Trong Python, Pyodide và CPython mỗi bên đều có phiên bản, và phiên bản mới có thể bao gồm breaking change
  • Phiên bản Python mới được phát hành vào tháng 8 hằng năm, còn phiên bản Pyodide mới được phát hành sau đó 6 tháng
  • Khi được thêm vào Workers, phiên bản Pyodide mới sẽ được đặt sau Compatibility Flag và chỉ được kích hoạt sau Compatibility Date được chỉ định
  • Các bản phát hành Python có thời gian hỗ trợ 5 năm, và những phiên bản Python đã hết thời gian hỗ trợ sẽ không còn được áp dụng bản vá bảo mật
  • Python Worker vẫn ở lại một bản phát hành Python cũ sau 5 năm sẽ tự động được chuyển sang bản phát hành Python cũ kế tiếp
  • Cloudflare kỳ vọng trong hầu hết trường hợp Python Worker sẽ tiếp tục chạy mà không gặp vấn đề, nhưng khuyến nghị cập nhật compatibility date định kỳ để luôn nằm trong thời gian hỗ trợ
  • Giữa các bản phát hành Python, các gói cũng sẽ được cập nhật và bổ sung theo cùng cơ chế opt-in; ví dụ flag có dạng python_3.17_packages_2025_03_01

Binding của Python Workers

  • Nhờ Pyodide FFI, có thể truy cập trực tiếp các đối tượng, phương thức và hàm JavaScript từ Python
  • Với cấu trúc này, toàn bộ binding API cho tài nguyên Cloudflare được hỗ trợ trong Python Workers ngay từ ngày đầu
  • Đối tượng env của Python handler là một đối tượng JavaScript, và Pyodide cung cấp API proxy xử lý việc chuyển đổi kiểu giữa các ngôn ngữ
  • Với KV namespace, có thể await env.FOO.put() và env.FOO.get() trong Python để ghi và đọc giá trị
  • Web API cũng có thể được sử dụng theo cách tương tự, và các JavaScript global như Response có thể được import từ module js

Kế hoạch cho API đậm chất Python hơn

  • Cloudflare nhận thấy các dạng như from js import Response không thật sự mang phong cách Python, và có kế hoạch cung cấp API idiomatic hơn cho Python Workers
  • workers-rs, ra mắt năm 2021, đã cung cấp các binding mang phong cách Rust cho từng JavaScript API của Workers
  • Với Python Workers, Cloudflare cũng lên kế hoạch theo hướng tương tự, trước tiên bắt đầu từ các binding Workers AI và Vectorize
  • workers-rs của Rust phải sử dụng và cập nhật các dependency bên ngoài, nhưng API của Python Workers dự kiến sẽ được tích hợp trực tiếp vào Workers runtime
  • Khi cập nhật compatibility date, có thể sử dụng các API mới nhất mang phong cách Python
  • Cũng có khả năng cung cấp một phần raw socket API của thư viện chuẩn Python dựa trên JavaScript API connect() của Workers
  • Cloudflare kỳ vọng bắt đầu nỗ lực xây dựng một serverless API được chuẩn hóa, dễ dùng cho lập trình viên Python trong khi vẫn cung cấp các chức năng tương đương JavaScript

Định hướng sắp tới

  • Để hỗ trợ đúng nghĩa một ngôn ngữ lập trình mới, cần đầu tư lớn hơn nhiều so với “hello world”
  • Theo khảo sát Stack Overflow 2023, Python là ngôn ngữ được sử dụng nhiều thứ hai sau JavaScript
  • Cloudflare cho biết sẽ tiếp tục cải thiện hiệu năng của Python Workers và mở rộng phạm vi hỗ trợ các package Python
  • Kênh phản hồi là kênh Python Workers trên Cloudflare Developers Discord và workerd GitHub discussion

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-03
Ý kiến trên Hacker News

  • Thật đáng mừng khi Cloudflare chú ý hơn đến việc chạy Python bằng WebAssembly ở Edge
    Từ góc nhìn của người từng xử lý việc chạy Python dựa trên WebAssembly ở Edge tại Wasmer, có thể tóm tắt rằng Cloudflare Workers kích hoạt Python ở Edge bằng Pyodide, tức Python được biên dịch sang WebAssembly bằng Emscripten
    Kiến trúc là gắn Pyodide vào Workerd và giảm thời gian khởi động bằng snapshot của V8; trong trường hợp tốt nhất, cold start của Python khoảng 1 giây
    Tuy nhiên, cách hiện tại bị ràng buộc vào phiên bản Python/Pyodide tích hợp trong Workerd, và việc phân giải package cũng gắn chặt với Workerd, nên rất có thể ở runtime chỉ cho phép các package native đã được biên dịch sẵn. Ví dụ, việc dùng một phiên bản numpy cụ thể có thể khá rắc rối
    Về mặt kiến trúc, nó bị buộc vào thế giới JS/V8, nên với kiến trúc hiện tại có vẻ khó đạt được thời gian khởi động dưới 100ms
    Dù vậy, tôi hoan nghênh bản phát hành này và mong mọi người sẽ tạo ra những ứng dụng tuyệt vời
    https://pyodide.org/
    https://github.com/cloudflare/workerd/blob/main/docs/pyodide...
    https://github.com/cloudflare/workerd/pull/1875
    Sửa: Đã sửa “bằng chứng khái niệm” thành “bản phát hành” theo giải thích của đội Cloudflare

    • Có vẻ phần tóm tắt về cách quản lý phiên bản đang có hiểu lầm. Pyodide/phiên bản package được kiểm soát bằng ngày tương thích, và có thể hỗ trợ đồng thời nhiều phiên bản trong production
      Chúng tôi dự định cập nhật khá thường xuyên các package như langchain hoặc numpy được nhắc đến
      Sẽ tốt hơn nếu bạn giải thích thêm vì sao cho rằng V8 là yếu tố giới hạn. V8 là một runtime WebAssembly mạnh mẽ, và phần lớn các tối ưu hóa đang được lên kế hoạch không phụ thuộc nhiều vào engine bên dưới
      Ngoài ra, đây không phải bằng chứng khái niệm mà là một bản beta sẽ tiếp tục được cải thiện cho tới GA
    • Nhân tiện, Wasmer cung cấp một sản phẩm Edge không có các nhược điểm được nhắc tới khi chạy Python trên Cloudflare Workers, đồng thời có cold start rất nhanh
      https://wasmer.io/templates?language=python
    • Bạn nói “với kiến trúc hiện tại, thời gian khởi động dưới 100ms sẽ khó”, nhưng tôi tò mò ai đang chạy workload Python cần độ trễ dưới 100ms
    • Tôi tò mò liệu kiến trúc này có hỗ trợ uvloop không

  • Cloudflare có nhiều thứ tốt ở mảng hosting và cơ sở dữ liệu, nhưng có vẻ họ không làm marketing tốt với tư cách một nền tảng dành cho lập trình viên, nên Vercel hoặc Netlify đã chiếm được khá nhiều mức độ nhận biết
    Ngoài ra, tôi tò mò liệu Cloudflare có cung cấp dịch vụ hosting container không phụ thuộc ngôn ngữ như Google Cloud Run hay không

    • Tôi đồng ý rằng có vấn đề gì đó ở khâu marketing. Ban đầu tôi bị Vercel và Netlify thu hút, nhưng sau khi dùng lâu thì cả hai đều không khiến tôi hài lòng, nên thử Cloudflare và cuối cùng lại thích
      Giá cả và sản phẩm đều tuyệt vời
    • Không chỉ là vấn đề marketing. Ban đầu tôi lạc quan về bộ sản phẩm của Cloudflare, nhưng đã gặp vấn đề lớn về khả năng tương thích với các trình tạo website như Next.js và Astro
      Một số tính năng hoàn toàn không hoạt động, một số khác chỉ được hỗ trợ một phần
      Nếu phải dành thời gian phát triển quý giá để xử lý các vấn đề như vậy, thì những nền tảng thay thế như Vercel, Netlify, Deno Deploy mượt mà hơn với nhu cầu của đội, và giúp dễ tập trung vào phát triển hơn là vấn đề hạ tầng
    • Vercel và Netlify có vẻ không thật sự nhắm tới lập trình viên. Nếu là lập trình viên, dùng Vercel và Netlify gần như đồng nghĩa với việc bị chém giá
      Chi phí băng thông của Vercel và Netlify đắt hơn hầu hết nhà cung cấp cloud khoảng 40–50 lần, còn ở Cloudflare thì băng thông gần như không thành chi phí
      Lượt gọi Edge function ở Vercel và Netlify cũng đắt gấp 6 lần Cloudflare. Con số này chưa tính chi phí thời gian compute vốn miễn phí ở Cloudflare
      Gần như lý do duy nhất khiến Vercel phổ biến là vì đó là nơi tốt nhất để host NextJS, và có lẽ vì vậy mà họ khiến việc triển khai NextJS ở nơi khác trở nên khó khăn
    • Theo tôi biết, cho đến gần đây gói miễn phí của CloudFlare khá hạn chế. D1, bản triển khai SQLite, mới GA hôm qua, và read replica cũng đã được công bố
    • Không có thứ giống Google Cloud Run, nhưng nếu có thì thật sự rất tuyệt
      Tôi đã dùng Workers trong production khoảng 4 năm và thích nó, nhưng phần lớn ứng dụng vẫn đang chạy trong container

  • Tôi đã dùng JS Workers trên một site đặt phía sau Cloudflare, thấy dễ dùng và rất nhanh. Tôi muốn chuyển toàn bộ ứng dụng Django phía sau site sang dùng cả cơ sở dữ liệu D1

    • Tôi cũng tương tự. Tôi có vài ứng dụng di động dùng Cloudflare Workers và KV/D1, trải nghiệm rất tốt
      Do lưu lượng thấp nên vẫn ở gói miễn phí, nhưng vì việc xây dựng quá dễ nên tôi cũng sẵn lòng trả tiền
    • Đồng ý, trông thật sự rất hay. Hiện chưa có hỗ trợ Django/DRF, nhưng họ nói sẽ tăng số lượng package trong tương lai
    • Chuyển toàn bộ ứng dụng Django phía sau site sang dùng cả D1 có khôn ngoan không? Chỉ cần một lần tấn công DDoS là ngân sách có thể vỡ

  • Sẽ hữu ích nếu có so sánh hiệu năng với JS Worker. Thú vị thật, nhưng vì có nhiều tầng đan xen nên có vẻ tiềm ẩn khả năng chậm hơn
    Tôi không kỳ vọng hiệu năng ngang nhau, nhưng sẽ tốt hơn nếu biết được đại khái các đánh đổi

    • Hiệu năng có ba khía cạnh: hiệu năng cold start, hiệu năng sau cold start, chi phí bridge giữa JS và WebAssembly, và tốc độ của trình thông dịch Python chạy trong WebAssembly
      Hiện tại cold start của Python chậm hơn JavaScript Worker cùng kích thước. Worker “Hello World” cơ bản viết bằng JavaScript có thời gian cold start gần như bằng 0, còn Python Worker thì dưới 1 giây
      Lý do là khi có request đến, phải nạp Pyodide vào Worker theo kiểu on-demand; bài blog mô tả công việc nhằm làm cho Pyodide sẵn sàng trước để giảm điều này
      Tuy nhiên, sau khi Python Worker kết thúc cold start, khác biệt trở nên gần như ở phần rìa, và tùy vào những gì xảy ra trong request, có thể chỉ là vài mili giây
      Khi băng qua “bridge” giữa JavaScript và WebAssembly, chẳng hạn lúc thực hiện I/O hoặc tác vụ bất đồng bộ, sẽ có một chút chi phí. Nhưng nên nghĩ ở mức micro giây chứ không phải mili giây, và nói chung là rất nhỏ
      Những người dùng Worker nhạy cảm về hiệu năng hiện cũng đã viết bằng Rust: https://github.com/cloudflare/workers-rs cái này cũng dựa vào bridge giữa JavaScript và WebAssembly
      Trình thông dịch Python dựa trên WebAssembly mà Pyodide cung cấp không nhanh bằng các tối ưu hóa đã được tích lũy suốt nhiều năm để làm JavaScript chạy nhanh trong V8. Dù vậy, Pyodide vẫn còn ở giai đoạn đầu so với engine JS của V8, và có những phần có vẻ còn nhiều dư địa cải thiện hiệu năng. Chúng tôi muốn đưa các cải tiến hiệu năng lên upstream, và cũng có một số đề xuất WebAssembly hữu ích
    • Theo cảm nhận thì trông rất nhanh

  • Tôi tò mò không biết việc chọn lzma để thể hiện tính cách ly là có chủ ý, hay chỉ tình cờ vì tin công nghệ tuần trước
    https://news.ycombinator.com/item?id=39865810

    • Chỉ là vì nó có trong thư viện chuẩn nên đưa vào thôi. Thời điểm hoàn toàn là tình cờ, nhưng việc dùng Wasm mang lại bảo đảm cách ly là điều tốt :-)

  • Có vẻ sẽ là một thay đổi rất lớn cho việc chạy các tác vụ liên quan đến AI trên Cloudflare. Tôi đã chờ khá lâu rồi

  • Hôm nay tôi đã thử dùng, thấy tốt và có thể đưa vào chạy rất nhanh
    Tuy nhiên, tôi thắc mắc phải làm sao để môi trường phát triển local hiểu các thư viện được tích hợp trong phần triển khai Python của CFW
    Ví dụ có thư viện asgi, và tôi muốn linter không đánh dấu nó là không thể nhận diện. Nhưng thư viện này chỉ tồn tại trong runtime của handler on_fetch, chứ thực tế không có trên máy phát triển local, nên tôi chưa tìm ra cách xử lý

  • Tôi đã có kết quả tốt khi dùng CF Pages cho site tĩnh, và các sản phẩm Cloudflare cung cấp LLM mã nguồn mở như một dịch vụ cũng rất thú vị
    Lý do chính ngăn tôi xây dựng nhiều hơn trên Cloudflare là thiếu hỗ trợ Python, nên tôi rất mong được thử tính năng này

    • Tôi cũng đang dùng CF Pages và vài hàm Worker, và hệ sinh thái Cloudflare thật sự rất tốt
      Dễ nhanh chóng đưa một thứ gì đó vào chạy, và không phải bận tâm quá nhiều về hạ tầng
      Việc bổ sung Python rất đáng mừng, và sẽ tuyệt nếu Go cũng được hỗ trợ hạng nhất

  • Tôi tò mò giới hạn chỉ được dùng các gói Pyodide sẽ hoạt động ra sao với các build không hề đơn giản
    Có nhiều mã không phải Python thuần, nên để hỗ trợ các ứng dụng production thực tế có lẽ sẽ có nhiều thứ phải build lại thủ công
    Việc Cloudflare tham gia có thể giúp kéo thêm nhiều gói vào, và nếu quy luật 80/20 đúng trong trường hợp này thì có thể vẫn đủ ổn

    • Tôi nghĩ ở đây chắc chắn có quy luật 80/20. Phần lớn các package không quá khó để port, còn những thứ khó build thường dùng các tính năng không có đối ứng rõ ràng trong runtime WebAssembly, như thread và multiprocessing, card đồ họa, raw socket, green thread
      Như bài blog cũng đã nhắc, vấn đề lớn nhất là hỗ trợ các package liên quan đến server và request. Chúng rõ ràng hữu ích trên Cloudflare Workers, nhưng lại khó port vì thường dùng raw socket và một dạng concurrency nào đó

  • Tôi mong CloudFlare triển khai Workers xem WASM là target hạng nhất, cùng với một API đa dụng không bị ràng buộc vào JS Workers
    Hiện tại cũng có thể triển khai mã WASM, nên về cơ bản dùng được bất kỳ ngôn ngữ nào, nhưng nó không phải native mà chạy trong context JS
    Có một chút overhead và sự gượng gạo trong triển khai
    Tôi nghĩ cuối cùng mọi dịch vụ sẽ được triển khai trực tiếp lên runtime WASM được bảo mật hóa, thay vì container. Tương tự như dòng dịch chuyển từ image sang container
    Hiện tại lợi ích của việc dùng những thứ như Rust trên Cloudflare Edge không lớn. Một phần đáng kể lợi ích về hiệu năng bị triệt tiêu bởi overhead và thời gian khởi động
    Ví dụ: https://github.com/WasmEdge/WasmEdge