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

135 lines
2.9 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.users.sterni.nix)
url
fun
string
;
inherit (depot.web.bubblegum)
pathInfo
scriptName
respond
absolutePath
;
# substituted using substituteAll in default.nix
blogdir = "@blogdir@";
# blogdir = toString ./posts; # for local testing
parseDate = post:
let
matched = builtins.match "/?([0-9]+)-([0-9]+)-([0-9]+)-.+" post;
in
if matched == null
then [ 0 0 0 ]
else builtins.map builtins.fromJSON matched;
parseTitle = post:
let
matched = builtins.match "/?[0-9]+-[0-9]+-[0-9]+-(.+).html" post;
in
if matched == null
then "no title"
else builtins.head matched;
dateAtLeast = a: b:
builtins.all fun.id
(lib.zipListsWith (partA: partB: partA >= partB) a b);
byPostDate = a: b:
dateAtLeast (parseDate a) (parseDate b);
posts = builtins.sort byPostDate
(builtins.attrNames
(lib.filterAttrs (_: v: v == "regular")
(builtins.readDir blogdir)));
generic = { title, inner, ... }: ''
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<title>${title}</title>
<style>a:link, a:visited { color: blue; }</style>
</head>
<body>
${inner}
</body>
</html>
'';
index = posts: ''
<main>
<h1>blog posts</h1>
<ul>
'' + lib.concatMapStrings (post: ''
<li>
<a href="${absolutePath (url.encode {} post)}">${parseTitle post}</a>
</li>
'') posts + ''
</ul>
</main>
'';
formatDate =
let
# Assume we never deal with years < 1000
formatDigit = d: string.fit {
char = "0"; width = 2;
} (toString d);
in lib.concatMapStringsSep "-" formatDigit;
post = title: post: ''
<main>
<h1>${title}</h1>
<div id="content">
${builtins.readFile (blogdir + "/" + post)}
</div>
</main>
<footer>
<p>Posted on ${formatDate (parseDate post)}</p>
<nav><a href="${scriptName}">index</a></nav>
</footer>
'';
validatePathInfo = pathInfo:
let
chars = string.toChars pathInfo;
in builtins.length chars > 1
&& !(builtins.elem "/" (builtins.tail chars));
response =
if pathInfo == "/"
then {
title = "blog";
feat(web/bubblegum): allow passing status as an int The whole pass the name of the status as a string thing was mostly born out of an overeager use of yants. It is still very neat especially for common cases like "OK", so we'll keep it, but also allow passing the integer variant of the status as well which probably feels more natural for a lot of people, especially over getting the casing right for "I'm a teapot". Change-Id: I3f012a291447ef385efdd28132292a8b331998c0 Reviewed-on: https://cl.tvl.fyi/c/depot/+/2850 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2021-04-05 01:58:26 +02:00
status = 200;
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
inner = index posts;
}
else if !(validatePathInfo pathInfo)
then {
title = "Bad Request";
feat(web/bubblegum): allow passing status as an int The whole pass the name of the status as a string thing was mostly born out of an overeager use of yants. It is still very neat especially for common cases like "OK", so we'll keep it, but also allow passing the integer variant of the status as well which probably feels more natural for a lot of people, especially over getting the casing right for "I'm a teapot". Change-Id: I3f012a291447ef385efdd28132292a8b331998c0 Reviewed-on: https://cl.tvl.fyi/c/depot/+/2850 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2021-04-05 01:58:26 +02:00
status = 400;
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
inner = "No slashes in post names 😡";
}
# CGI should already url.decode for us
else if builtins.pathExists (blogdir + "/" + pathInfo)
then rec {
title = parseTitle pathInfo;
feat(web/bubblegum): allow passing status as an int The whole pass the name of the status as a string thing was mostly born out of an overeager use of yants. It is still very neat especially for common cases like "OK", so we'll keep it, but also allow passing the integer variant of the status as well which probably feels more natural for a lot of people, especially over getting the casing right for "I'm a teapot". Change-Id: I3f012a291447ef385efdd28132292a8b331998c0 Reviewed-on: https://cl.tvl.fyi/c/depot/+/2850 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2021-04-05 01:58:26 +02:00
status = 200;
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
inner = post title pathInfo;
} else {
title = "Not Found";
feat(web/bubblegum): allow passing status as an int The whole pass the name of the status as a string thing was mostly born out of an overeager use of yants. It is still very neat especially for common cases like "OK", so we'll keep it, but also allow passing the integer variant of the status as well which probably feels more natural for a lot of people, especially over getting the casing right for "I'm a teapot". Change-Id: I3f012a291447ef385efdd28132292a8b331998c0 Reviewed-on: https://cl.tvl.fyi/c/depot/+/2850 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>
2021-04-05 01:58:26 +02:00
status = 404;
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
inner = "<h1>404 — not found</h1>";
};
in
respond response.status {
"Content-type" = "text/html";
} (generic response)
Reference in a new issue Copy permalink