Deno: Request: A web server command that serves code and documentation

[KSXGitHub]

Rationale

At first glance, serving deno libraries appear simple: Just put the whole thing on GitHub or GitHub Pages. But when other factors come around (such as semantic versioning, fallback for browser compatibility, caching, CDN, etc.), things appear to be much more complicated.

Suggestion

I wish deno provides a cli command (such as deno serve) and an API (such as Deno.serveCode()) that does all those things in a standard and painless fashion.

The server should have the following features:

• Pre-generate optimized JavaScript files, TypeScript definitions, and documentation.
  
  
  
  • All generated JavaScript files have their import URLs resolved. That is: skip intermediate redirection and re-export modules, change import line to import directly from the module where needed variables were created. This would allow JavaScript runtime does less work and be faster.
  
  
  • All generated JavaScript files should be minified to save bandwidth.
  
  
• Use user agent to detect requesting browsers. Transpile module (once) in order for module to run on the browser. If the browser does not support es6 import, send a bundle. Also transpile WASM modules to asm.js.
• Use HTTP/2 push to send all dependencies when a JavaScript module is requested. Add all JavaScript modules to preload header. HTTP/2 push is sloppy when it comes to caching.
• Use git tags and commit ids to determine versions.
• Redirect version range URLs to a specific version.
• Assign appropriate cache expire limit:
  
  
  
  • A finite number for a version range.
  
  
  • immutable for specific version.
  
  
• Provide a registry API:
  
  
  
  • Tell API consumer how many versions, what is the latest version, etc.
  
  
  • Preferably in GraphQL: A module may have dependencies, which may also depend on other dependencies, using GraphQL would allow API consumer to query what they want without sending requests back and forth, saving time, energy, and bandwidth.
  
  
• And possibly more

[ry]

So basically something like https://github.com/denoland/deno_website2 but written in Deno?

I agree this would great to have. I don't know about all of these features (GraphQL sounds like a bit much) but certainly we should have a program in std that can serve up a directory of code that deno can link to.

I'd file this one under long term goals.

[crabmusket]

I wouldn't imagine Deno should have a built-in production-ready server (e.g. with HTTP2 push). But it should absolutely have something like go docs which serves cached dependencies. Super useful for devving on a train with a spotty connection.

That said, I'd love the Deno module server (which currently runs https://deno.land/x) to be written in Deno and have more awesome features.

EDIT: random note, where did the idea of transpiling Wasm to asm.js come from? :thinking:

[KSXGitHub]

@ry

I don't know about all of these features

I listed all these features because I think Deno was to be a swiss army knife for JavaScript developers (since it has so many features already).

Another reason is that it is better that Deno sets up a standard (with clear specs) about how Deno libraries should be served for everything else.

GraphQL sounds like a bit much

It may be a bit more complex than simple REST API, but I think it fits a module registry. For example: I sometimes want to list all contributors from all direct/indirect dependencies, doing so with npm registry would require me to send request back and forth, wasting precious time and bandwidth, a query language like GraphQL would allow me to do so in one request.

Of course, we cannot implement all these features immediately in day 1, so a clear roadmap and specs is necessary.

[KSXGitHub]

@crabmusket

random note, where did the idea of transpiling Wasm to asm.js come from?

It came from my desire to rewrite the Internet in Rust /jk

But actually, I think it would be nice if library server can provide compatible fallbacks for older browsers, that of course must include WASM too.

[kitsonk]

Still sounds a bit over ambitious to me even for std, sounds like a community things, where there are already quite a few static web servers built on Deno. Having deno_website2 as a serverless process based on Deno using Deno code of course would be nice. But that sounds like deno_website3 to me.

[bartlomieju]

Outside of scope for Deno CLI. I agree with @kitsonk that it seems better suited to be a community project.