mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
tvl-depot/web/bubblegum/examples/hello.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

93 lines
1.7 KiB
Nix
Raw Normal View History

feat(web/bubblegum): nix CGI programming framework So here is what has been keeping me up at night: At some point I realized that nix actually made a somewhat passable language for CGI programming: * That `builtins.getEnv` exists as one of the impurities of Nix is perfect as environment variables are the main way of communication from the web server to the CGI application. * We can actually read from the filesystem via builtins.readDir and builtins.readFile with bearable overhead if we avoid importing the used paths into the nix store. * Templating and routing are convenient to implement via indented strings and attribute sets respectively. Of course there are obvious limitation: * The overhead of derivations is probably much to great for them to be useful via IfD. * Even without derivations, nix evaluation is very slow to the point were a trivial application takes between 100ms and 400ms to produce a response. * We can't really cause effects other than producing a response which makes it not viable for a lot of applications. There are some ways around this: * With a custom interpreter we could have streaming and multiplexed I/O (using lazy lists emulated via attrsets) to cause such effects, but it would probably perform terribly. * We can use builtins.fetchurl to call other HTTP-based microservices, but only in very limited constraints, i. e. only GET, no headers, and only if the tarball ttl is set to 0 in the global nix.conf. * Terrible error handling capabilities because builtins.tryEval actually doesn't catch a lot of errors. To prove that it actually works, there are some demo applications, which I invite you to run and potentially break horribly: nix-build -A web.bubblegum.examples && ./result # navigate to http://localhost:9000 The setup uses thttpd and executes the nix CGI scripts using users.sterni.nint which automatically passed `depot`, so they can import the cgi library. Change-Id: I3a22a749612211627e5f8301c31ec2e7a872812c Reviewed-on: https://cl.tvl.fyi/c/depot/+/2746 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in>
2021-02-21 12:57:40 +01:00
{ depot, ... }:
let
fix(bubblegum): import lib from the new correct place Since cl/2910 depot has no lib attribute anymore. Import it from the depot fix point via depot.third_party.nixpkgs.lib to avoid passing another argument and enlargening the shebang further. Change-Id: I3c719eba38a5ceb36689ebf0409bd19d4f46a609 Reviewed-on: https://cl.tvl.fyi/c/depot/+/3050 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2021-04-20 10:27:40 +02:00
inherit (depot.third_party.nixpkgs)
feat(web/bubblegum): nix CGI programming framework So here is what has been keeping me up at night: At some point I realized that nix actually made a somewhat passable language for CGI programming: * That `builtins.getEnv` exists as one of the impurities of Nix is perfect as environment variables are the main way of communication from the web server to the CGI application. * We can actually read from the filesystem via builtins.readDir and builtins.readFile with bearable overhead if we avoid importing the used paths into the nix store. * Templating and routing are convenient to implement via indented strings and attribute sets respectively. Of course there are obvious limitation: * The overhead of derivations is probably much to great for them to be useful via IfD. * Even without derivations, nix evaluation is very slow to the point were a trivial application takes between 100ms and 400ms to produce a response. * We can't really cause effects other than producing a response which makes it not viable for a lot of applications. There are some ways around this: * With a custom interpreter we could have streaming and multiplexed I/O (using lazy lists emulated via attrsets) to cause such effects, but it would probably perform terribly. * We can use builtins.fetchurl to call other HTTP-based microservices, but only in very limited constraints, i. e. only GET, no headers, and only if the tarball ttl is set to 0 in the global nix.conf. * Terrible error handling capabilities because builtins.tryEval actually doesn't catch a lot of errors. To prove that it actually works, there are some demo applications, which I invite you to run and potentially break horribly: nix-build -A web.bubblegum.examples && ./result # navigate to http://localhost:9000 The setup uses thttpd and executes the nix CGI scripts using users.sterni.nint which automatically passed `depot`, so they can import the cgi library. Change-Id: I3a22a749612211627e5f8301c31ec2e7a872812c Reviewed-on: https://cl.tvl.fyi/c/depot/+/2746 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in>
2021-02-21 12:57:40 +01:00
lib
;
inherit (depot.web.bubblegum)
pathInfo
respond
absolutePath
;
routes = {
"/" = {
status = "OK";
title = "index";
content = ''
Hello World!
'';
};
"/clock" = {
status = "OK";
title = "clock";
content = ''
It is ${toString builtins.currentTime}s since 1970-01-01 00:00 UTC.
'';
};
"/coffee" = {
status = "I'm a teapot";
title = "coffee";
content = ''
No coffee, I'm afraid
'';
};
feat(web/bubblegum): report some errors to the user via HTTP We can actually catch some errors that may be generated in bubblegum applications where we can report them to the user in a way that doesn't require curl -vv: * Type errors in the status argument: By removing yants completely we not only (presumably) gain some performance, but also the ability to return an internal server error on an unexpected type instead of throwing. * User generated evaluation errors: by using builtins.tryEval we can catch throws and asserts the user inserted when generating the body and report to the user that something went wrong. To do: also support for the headers. Change-Id: I8363b9825c6c730e624eb8016a5482d63cbc1890 Reviewed-on: https://cl.tvl.fyi/c/depot/+/2849 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2021-04-05 01:53:21 +02:00
"/type-error" = {
status = 666;
title = "bad usage";
content = ''
Never gonna see this.
'';
};
"/eval-error" = {
status = "OK";
title = "evaluation error";
content = builtins.throw "lol";
};
feat(web/bubblegum): nix CGI programming framework So here is what has been keeping me up at night: At some point I realized that nix actually made a somewhat passable language for CGI programming: * That `builtins.getEnv` exists as one of the impurities of Nix is perfect as environment variables are the main way of communication from the web server to the CGI application. * We can actually read from the filesystem via builtins.readDir and builtins.readFile with bearable overhead if we avoid importing the used paths into the nix store. * Templating and routing are convenient to implement via indented strings and attribute sets respectively. Of course there are obvious limitation: * The overhead of derivations is probably much to great for them to be useful via IfD. * Even without derivations, nix evaluation is very slow to the point were a trivial application takes between 100ms and 400ms to produce a response. * We can't really cause effects other than producing a response which makes it not viable for a lot of applications. There are some ways around this: * With a custom interpreter we could have streaming and multiplexed I/O (using lazy lists emulated via attrsets) to cause such effects, but it would probably perform terribly. * We can use builtins.fetchurl to call other HTTP-based microservices, but only in very limited constraints, i. e. only GET, no headers, and only if the tarball ttl is set to 0 in the global nix.conf. * Terrible error handling capabilities because builtins.tryEval actually doesn't catch a lot of errors. To prove that it actually works, there are some demo applications, which I invite you to run and potentially break horribly: nix-build -A web.bubblegum.examples && ./result # navigate to http://localhost:9000 The setup uses thttpd and executes the nix CGI scripts using users.sterni.nint which automatically passed `depot`, so they can import the cgi library. Change-Id: I3a22a749612211627e5f8301c31ec2e7a872812c Reviewed-on: https://cl.tvl.fyi/c/depot/+/2746 Tested-by: BuildkiteCI Reviewed-by: tazjin <mail@tazj.in>
2021-02-21 12:57:40 +01:00
};
notFound = {
status = "Not Found";
title = "404";
content = ''
This page doesn't exist.
'';
};
navigation =
lib.concatStrings (lib.mapAttrsToList
(p: v: "<li><a href=\"${absolutePath p}\">${v.title}</a></li>")
routes);
template = { title, content, ... }: ''
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>${title}</title>
<style>a:link, a:visited { color: blue; }</style>
</head>
<body>
<hgroup>
<h1><code>//web/bubblegum</code></h1>
<h2>example app</h2>
</hgroup>
<header>
<nav>
<ul>${navigation}</ul>
</nav>
</header>
<main>
<p>${content}</p>
</main>
</body>
'';
response = routes."${pathInfo}" or notFound;
in
respond response.status {
"Content-type" = "text/html";
} (template response)
Reference in a new issue Copy permalink