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>
Forgot to add this when moving it out of my //users directory.
Change-Id: If6d30a2a58a6bd73e160706cb706e3b2e100e909
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2754
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
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>
