How might this project differentiate itself from Bun as it grows? Because Bun aims to be compact and fast (fast being the priority in their case).
xkcd-sucks 2 hours ago [-]
Unfortunate name collision with FASTA the bioinformatic sequence file format
mrmagoo17 10 hours ago [-]
That's a really cool implementation! I hope I'll have some time soon to have a peek at the code. I am honestly a bit surprised to see that none of the major cloud providers are even thinking to leverage WASM and WASI for serverless...
I have been playing with it, it's very cool to be able to run anywhere. Do you have plans to implement wasi-http? One of my concerns is the free tier only offers Compute as a trial, and $50 is pretty steep for a hobby project, are there plans to add Compute usage to the free tier?
alexboehm 9 hours ago [-]
After delving into this, it seems Wasmer tried, but as they weren't standards compliant, adoption/ecosystem support never followed.
The Bytecode alliance is taking their time stabilizing wasi. wasip2 which is needed for the wasi-http realm this relies on has only really existed for a few months as a stable Rust target, and still misses a lot of the really cool features that will come with wasip3 like full async support.
I suspect Cloud providers will adopt wasi after 1.0, but that is likely years away. I don't think wasi-http will change much before then so now is the time to start building with it.
syrusakbary 8 hours ago [-]
> After delving into this, it seems Wasmer tried, but as they weren't standards compliant, adoption/ecosystem support never followed.
You may be surprised by how much WASIX is being adopted by the ecosystem! Aiming it to be full POSIX compliant has proven incredibly powerful, as there's no need for waiting for other entities to reinvent what already works in the POSIX (macOS, Linux, ...) :)
alexboehm 8 hours ago [-]
I'm not discounting WASIX or what you guys are doing I'd love to just use wasm today for everything instead of waiting, I started this project by trying to use WASIX, I just found it quite difficult to actually develop for as many of the essential rust crates, seemed reluctant to merge your changes, and having to use dependency versions from a year ago with patches is very frustrating.
syrusakbary 3 hours ago [-]
Fair! We have already plans to solve the patching issue you commented... stay tuned!
sshine 8 hours ago [-]
So happy to see wasi-http become stable.
singularity2001 5 hours ago [-]
You could link to faasta.xyz in github about and add EXAMPLES there.
The lambdas should be able to be accessible via http(s) e.g.
Thanks for the feedback, I've added the URL to about,
I originally supported path prefix and subdomains, but I found it slightly more confusing to communicate to users. I'm definitely planning on more example.
foresterre 5 hours ago [-]
Since there is no LICENSE in the repo, I assume this will not be an open source project? Will it have an open core or similar license?
alexboehm 5 hours ago [-]
The plan is for it to be an opensource project, currently the cli and interface crates are MIT, I have been considering a copyleft license for the server, or a dual licensing strategy.
badmonster 9 hours ago [-]
Do you plan to support custom domains and SSL certificates for self-hosted Faasta deployments, or will that be handled externally via reverse proxies?
alexboehm 9 hours ago [-]
For self hosted, if you use porkbun for DNS it will automatically pull a wildcard SSL cert using the API at startup.
I plan to also support multiple custom domain certs on a multi tenanted instance like faasta.xyz. For now I'd recommend a reverse proxy though.
badmonster 9 hours ago [-]
gotcha
lettersdigitsda 3 hours ago [-]
[flagged]
alexboehm 3 hours ago [-]
A more descriptive word would been self-hostable function as a service, that's why faas is in the name!
The point of serverless is you don't have to think about hosting, and ideally it's cheaper.
The problem is if the hosting provider goes away you're screwed.
In the case of Faasta, it's a single static binary with minimal configuration so if that happens, you can host it your self or move to another provider.
remram 2 hours ago [-]
How can you "not have to think about hosting" while self-hosting?
tormeh 1 hours ago [-]
I get the feeling it's basically an old-fashioned application server like Wildfly or Tomcat. So the developer doesn't worry about system-d config or whatever, but just adds their application files to a folder. Of course someone needs to maintain the application server, however it's deployed, but it detangles things a bit. I personally think this makes no sense unless someone else hosts the application server. Maybe in an enterprise context of some sort. Otherwise this feels like a tried-and-failed idea.
alexboehm 1 hours ago [-]
The difference is Wasm provides the security boundary so it can be multi tenanted. The real magic is that wasi will be hostable anywhere much like Docker containers are today, but it's much more efficient than docker containers because there are less overheads and startup latency.
alexboehm 2 hours ago [-]
Well at that point you'll obviously start having to think about it. The point is you can easily move to self-hosting without rewriting everything.
Rendered at 14:45:23 GMT+0000 (Coordinated Universal Time) with Vercel.
How might this project differentiate itself from Bun as it grows? Because Bun aims to be compact and fast (fast being the priority in their case).
https://www.fastly.com/documentation/guides/compute/
(I work there)
The Bytecode alliance is taking their time stabilizing wasi. wasip2 which is needed for the wasi-http realm this relies on has only really existed for a few months as a stable Rust target, and still misses a lot of the really cool features that will come with wasip3 like full async support.
I suspect Cloud providers will adopt wasi after 1.0, but that is likely years away. I don't think wasi-http will change much before then so now is the time to start building with it.
You may be surprised by how much WASIX is being adopted by the ecosystem! Aiming it to be full POSIX compliant has proven incredibly powerful, as there's no need for waiting for other entities to reinvent what already works in the POSIX (macOS, Linux, ...) :)
The lambdas should be able to be accessible via http(s) e.g.
https://square.faasta.xyz/3 => 9
https://faasta.xyz/square/3 => 9
Great idea if done right!
I plan to also support multiple custom domain certs on a multi tenanted instance like faasta.xyz. For now I'd recommend a reverse proxy though.
The point of serverless is you don't have to think about hosting, and ideally it's cheaper.
The problem is if the hosting provider goes away you're screwed. In the case of Faasta, it's a single static binary with minimal configuration so if that happens, you can host it your self or move to another provider.