shell.duckdb.org versus duckdb REST-server?

[mskyttner]

There is a duckdb rest server with a web front end that is I guess a little bit locked in to the TPCH demo database schema. Do you think the rest server component will be sunsetted going forward (also the server part) rather than further developed? I guess the duckdb-wasm will be the new frontend?

What extensions (if any) are planned to be included in the shell.duckdb.org?

I tried loading 'httpfs' at shell.duckdb.org, but got these messages:

duckdb> install 'httpfs';
INTERNAL Error: Can't find the home directory at /home/web_user

duckdb> load 'httpfs';
IO Error: File "/home/web_user/.duckdb/extensions/662041e2b/linux_i686_gcc4/httpfs.duckdb_extension" not found

[ankoh]

There are no plans to sunset the rest server component (code) itself, since both solve slightly different problems.
DuckDB-Wasm runs entirely in the browser and is therefore subject to browser limitations and the clients performance.
Both work best in tandem where you use the client-side DuckDB-Wasm instance to spare yourself roundtrips over the internet and the server-side DuckDB (e.g. via REST) for the heavy hitters.

That having said, we might replace the online Demo entirely with DuckDB-Wasm at some point since this offers a severless way to play around with DuckDB.

Regarding the httpfs:
DuckDB-Wasm does not need a http filesystem since we're integrating with the browser APIs.
You can scan remote files via HTTP in DuckDB-Wasm without loading an extension.
Additionally, DuckDB-Wasm ships with the Parquet and FTS extensions.
Dynamic extension loading is something we're looking at.