Replace http-server with fastify

[Borewit]

Replace http-server with fastify.

Rational

While http-server is excellent for quickly serving static files to a browser, it is not intended to function as a backend API for web applications. It responds with HTML directory listings and lacks support for structured responses like JSON, which are essential when building RESTful services or programmatic file access. If your application needs to interact with the server via JavaScript (e.g., fetch or AJAX) and expects machine-readable data (e.g., JSON), a more suitable approach is to use a lightweight Node.js server (e.g., with Express or Fastify) that can explicitly serve both static files and JSON-based endpoints.

Other

Switch server side / module type from CommonJS to ECMAScript.

New options

• Having a backend you implement anything you like also offers possibilities, like HTTP range requests which avoid the entire file needs to be streamed to fetch its metadata. music-metadata does support that using @tokenizer/range.
• Alternatively, do the metadata extraction server side

[hvianna]

I used to have my own custom server implementation using express, but being able to access the user's file system kinda deprecated the need for a backend server.

Nowadays I keep web server support mostly for my own use at home (cheap NAS running lighttpd), but I think it also benefits those who want to self-host the app in any standard web server. If I need to move to a custom server, there's no point in keeping it.

Having a backend you implement anything you like also offers possibilities, like HTTP range requests which avoid the entire file needs to be streamed to fetch its metadata. music-metadata does support that using @tokenizer/range.

But I believe range requests are enabled by default in most web servers, no? It seems to be, on my NAS server..

> Host: 192.168.0.32:8000
> Range: bytes=100000-200000
> User-Agent: curl/8.13.0
> Accept: */*
>
< HTTP/1.1 206 Partial Content
< Content-Language: en
< P3P: CP='CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR'
< Content-Type: audio/flac
< Accept-Ranges: bytes
< ETag: "2058288725"
< Last-Modified: Sun, 19 May 2024 21:06:21 GMT
< Content-Range: bytes 100000-200000/51322105
< Content-Length: 100001
< Date: Sat, 19 Jul 2025 14:05:06 GMT
< Server: lighttpd/1.4.28
<
{ [100001 bytes data]
* Connection #0 to host 192.168.0.32 left intact

[Borewit]

but I think it also benefits those who want to self-host the app in any standard web server.

Scraping files from HTML is inherently brittle, any changes to the DOM or structure will break the logic. If you want true support for multiple server configurations, it's better to use a protocol designed for that purpose, like WebDAV, which offers standardized, structured access over HTTP.

[Borewit]

What you may want to consider, if you cannot live without your static webserver, is to create a proxy, scraping and converting the HTML pages to REST/JSON.

[hvianna]

I’m definitely interested in supporting other data sources/protocols like WebDAV in the future, but I don't want to abruptly break compatibility.

I truly appreciate your help, enthusiasm and patience - it means a lot. But for now, I need to focus on documenting this new version for release. My availability for this project is limited at the moment, so I’ll have to put these ideas on hold for maybe a couple of weeks. I hope you understand.

[Borewit]

Thanks for the heads up @hvianna , understood, first things first.