Unfortunate name collision with FASTA the bioinformatic sequence file format

Bun likely has a larger footprint than this but it&#x27;s also gaining lots of traction: <a href="https:&#x2F;&#x2F;bun.sh&#x2F;docs&#x2F;runtime&#x2F;loaders" rel="nofollow">https:&#x2F;&#x2F;bun.sh&#x2F;docs&#x2F;runtime&#x2F;loaders</a>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).

Check out Fastly’s WASM-powered Compute platform:<a href="https:&#x2F;&#x2F;www.fastly.com&#x2F;documentation&#x2F;guides&#x2F;compute&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.fastly.com&#x2F;documentation&#x2F;guides&#x2F;compute&#x2F;</a>(I work there)

&gt; After delving into this, it seems Wasmer tried, but as they weren&#x27;t standards compliant, adoption&#x2F;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&#x27;s no need for waiting for other entities to reinvent what already works in the POSIX (macOS, Linux, ...) :)

So happy to see wasi-http become stable.

After delving into this, it seems Wasmer tried, but as they weren&#x27;t standards compliant, adoption&#x2F;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&#x27;t think wasi-http will change much before then so now is the time to start building with it.

That&#x27;s a really cool implementation! I hope I&#x27;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...

Thanks for the feedback, I&#x27;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&#x27;m definitely planning on more example.

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.<a href="https:&#x2F;&#x2F;square.faasta.xyz&#x2F;3" rel="nofollow">https:&#x2F;&#x2F;square.faasta.xyz&#x2F;3</a> =&gt; 9<a href="https:&#x2F;&#x2F;faasta.xyz&#x2F;square&#x2F;3" rel="nofollow">https:&#x2F;&#x2F;faasta.xyz&#x2F;square&#x2F;3</a> =&gt; 9Great idea if done right!

How can you &quot;not have to think about hosting&quot; while self-hosting?

A more descriptive word would been self-hostable function as a service, that&#x27;s why faas is in the name!The point of serverless is you don&#x27;t have to think about hosting, and ideally it&#x27;s cheaper.The problem is if the hosting provider goes away you&#x27;re screwed. 
In the case of Faasta, it&#x27;s a single static binary with minimal configuration so if that happens, you can host it your self or move to another provider.

| self-hosted ServerlessMake up your mind

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.

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?

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&#x27;d recommend a reverse proxy though.

Do you plan to support custom domains and SSL certificates for self-hosted Faasta deployments, or will that be handled externally via reverse proxies?

Show HN: Faasta – A self-hosted Serverless platform for WASM-wasi-HTTP in Rust