Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
windmill
Open-source developer platform to turn scripts into workflows and UIs. Fastest workflow engine (5x vs Airflow). Open-source alternative to Airplane and Retool.
-
extism
The framework for building with WebAssembly (wasm). Easily load wasm modules, move data, call functions, and build extensible apps.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
edge-runtime
A server based on Deno runtime, capable of running JavaScript, TypeScript, and WASM services.
-
-
One of the biggest annoyances with Deno deploy/functions is that there is no way to store any data. This would be very useful to e.g. cache an auth token, store a key/value pair, etc. See also: https://github.com/denoland/deploy_feedback/issues/110
Is any work being done to fix this? Or is this out of scope currently?
I think this is great, but a growing question in my mind from these is what is the long tail plan for maintenance of this constellation of stuff? Especially because you guys are building on technologies that you can’t really just casually find developers for eg Elixir and Haskell. I keep seeing missing critical features in Realtime and Postgrest, and I know these are armies of 1-2, but it does kind of worry me when I think about investing time and effort into the Supabase ecosystem as a whole seeing more and more launches while there isn’t much action on existing issues.
Example: https://github.com/PostgREST/postgrest/issues/915#issue-comm...
hey hn, supabase ceo here
This is a webserver for Deno. It is MIT licensed, written in Rust, and based on the latest Deno Runtime (1.32+). It can serve TypeScript, JavaScript, and WASM functions.
This one is important for local development and self-hosting. For local development, it ensures there is parity between development and production. For self-hosting, it means you can deploy and manage your Deno Functions on your own hardware. We have provided a Demo repository for deploying to Fly.io [1].
In the medium-term, this will reduce our tech-stack by 1 service. We'll remove Kong (a reverse proxy) and replace it with the Deno runtime. I'm excited about some other possibilities that this provides for self-hosting - one that we talked about was the ability to bundle a SQLite file with your functions, for a fully-contained and globally deployed webserver.
The team will be around if you have any questions
[1] Deploy on Fly: https://github.com/supabase/self-hosted-edge-functions-demo
Thank you for open-sourcing especially under MIT license. I am digging through the codebase and finding a lot of interesting things.
I am building another open-source project that is also a self-hosted deno runtime, Windmill [1], where we enable to build all of your internal tool and infra (endpoints, workflows, apps) based on scripts (deno, but also python, go, bash). Instead of running one http server continuously for your function, we run it on demand which has its own set of challenged.
We are doing something pretty naive right now which to create a fork and call deno run [2]. It's decently efficient (25ms for a naive script e2e). We are familiar with deno_core and use it in other places to run javascript directly, but for typescript, deno didn't expose directly the root entrypoint as a lib so we had to fork it [3] and are now gonna be able to do the transpiling to js AOT and save the fork for sub 5ms script execution.
We also want to make some functions togglable as high-performance endpoints and for those we would want them to be spawned as http servers to save the cold start. I'm gonna investigate thoroughly the codebase, and thank you very much for having shared it.
[1]: https://github.com/windmill-labs/windmill
if curious of specifics, this is my work in progress proof of concept, exploring using pathnames for channels, to get anyone on the same url path connected across regions through sockets and broadcast channel: https://github.com/tylerchilds/kickstart/blob/869506c9dae1e1...
Would love to know what you're interested in doing.. we make Extism[0] which allows you to more or less ignore the lack of a "standard library" for something like V8 wasm environments.. Spin definitely makes it easier to compile high-level source code & have done great work on their SDKs to provide these "standard lib" elements. maybe Extism is useful, but if not please feel free to drop in our Discord[1] and chat w/ the team.
[0]: https://github.com/extism/extism
[Supabase engineer & author of the blog post]
You can already use WASM modules within Edge Functions. We have an example on using WASM modules to generate OpenGraph images - https://github.com/supabase/supabase/tree/master/examples/ed...
We are also exploring ways to create functions in WASM-supported languages and run them directly on Edge Runtime. We expect this would be easier WasmGC[0] is shipped and Deno's WASI support improves.
[0] https://chromestatus.com/feature/6062715726462976
[Supabase engineer & Author of the blog post]
Hi Mark, hosted Supabase Edge Functions would still run on Deno Deploy, so those limitations would still exist. However, we plan to introduce file system access via integration with Supabase Storage. This is still a rough idea stage, maybe we'll have a solid answer in a couple of months :)
For dynamic imports, we haven't looked into it since Supabase users haven't requested it. If you can open an issue on Edge Runtime repo [0] and explain how you intend to use them, we can probably work on a solution.
[0] https://github.com/supabase/edge-runtime/issues
Thanks Lakshan!
I don't think my use-case is necessarily a good fit for edge functions. I am trying to achieve what Supabase realtime/multiplayer accomplishes, but generically. I participate informally with the https://braid.org IETF working group, which to over-simplify is CRDTs over HTTP with subscriptions.
I'm interested in web standards and that's what's drawn me to deno, so I'm super excited the more and more I see it being adopted. BroadcastChannel piques my interest because it is perfectly in that gray area of standardization-- it makes total sense on the client and we're on the cusp of discovering what that could look like for servers.
In deno deploy, all the instances of my service are able to be linked together by BroadcastChannel, which I'm viewing as a p2p-style architecture. Ultimately, I'm curious about how this works under the hood and if it would be possible to interoperate a BroadcastChannel between Deno Deploy, Supabase, and say a Raspberry Pi in my house.
I've gone on a bit of a tangent, but I think maybe I should get involved with the WinterCG, since now that I'm putting my thoughts to words-- seems like it fits their charter.
Yes, this is something we are exploring for Edge Runtime. One cool development is AsyncLocalStorage now works on Deno via a polyfill [0]. We may enable a single node store on Edge Runtime using this. Also, there are some interesting development in Supabase platform to enable Edge Databases, which could also be an answer to this.
[0] https://github.com/denoland/deno/issues/7010#issuecomment-14...