This library was initially developed during the 2023 Spawnfest hackathon last month. I have since made updates, wrote extensive unit tests, and got it prepared for public usage.
nine is a library to enable composing routes and middleware for elli webservers in a declarative way. If you use elli webservers this will provide a nice quality of life improvement. There were several influences on this library. Most importantly, if you are familiar with Plug.Router then you should feel right at home. I created this library because I wanted to precisely compose middleware at any level I wished. elli’s middleware features were not fine grained enough for me. While there may be some sharp edges, I have found it is already useful for basic applications.
The way it works is it takes a route configuration (just an Erlang map) and compiles it into an elli callback module. You can see this example module for how it looks to use nine in practice. For now, this only supports elli, but in theory it could be decoupled to support other web servers.
My future plans are to implement route config validations, as well as property based testing.
Oh, thanks to the recent comment I saw this post on here.
It is great to see!
I was curious why so many binaries? No reason not to use atoms and looks a lot cleaner?
[#{path => ...,
method => ...,
pre => ...,
post => ...,
handle => ...}]
Also, since erlang:decode_packet and by extension Elli return an atom or charlist for method you probably want to use an atom there too to not deal with conversions?
Hi there! Now that nine supports cowboy as well elli I’ve broken it out into 3 libraries, and made some API changes. I’ve been meaning to make a more public announcement after testing it a bit more. At minimum I should link the new libraries though in the README. I thought no one used this library so I figured had some more time
nine_elli - I’ve moved the example to the example directory in this repo. Feel free to ask questions if you run into any issues.
I agree the atom’s are a lot cleaner, and something I might try. No reason I couldn’t support atoms and binaries. Over the years I’ve gotten it in my head to stay away from atoms, because of the issue of overusing them dynamically. However, that isn’t relevant in this case since the compile function is called once.
Once Debian supports OTP-27 I will go all in. As a heavy Debian user I personally hate having to download the latest version of whatever language to use a certain library, so I try to not instill that on others with my libraries.
Ah, as long as the usage doesn’t require a list_to_atom anywhere you are safe. Usage for a route’s keys would be safe.
Interesting you are using debian packages, I find those to be poorly suited for development (and they aren’t really meant for it but for running programs) – I’m on Fedora, so the same case here – so have relied on stuff like kerl (with tools like asdf/mise) for development – well, really I use (plug) beamup which I’ll hopefully soon have binary Erlang installs instead of just source in the near future for both debian and fedora – and eventually more, if not generic cross-distro builds.
Yes, thank you for beamup I’ve been meaning to try it. I don’t have great reasons for my thinking (mostly laziness), but I appreciate the nudges in a better direction.
