Akka HTTP - GET method with more than 22 parameters

I’m using the brand-new guardrail (https://github.com/twilio/guardrail) to generate an Akka HTTP implementation based on a Swagger API definition. One of the GET methods in the specification appears to have more than 22 parameters. Regardless of whether this is a sound design choice (conceptually, it is a search request, so it maps well to GET) I’m trying to see if it would be possible to get this to work.

Akka HTTP’s Directive design is built around tuples, i.e. pretty much everything including parameter extraction is using tuples behind the scenes, which is to say that I can’t use the standard extraction mechanisms here (you can’t concatenate more than 22 parameters via the parameters function).

I suppose it should be possible to build a custom extraction for this rather extreme case, but before going down that road, I was wondering if anyone else has had to do this before?



The thing is that Akka HTTP’s parameters directives work by emitting well-typed tuples, and those remain limited to 22 params nowadays, and likely forever until we get build-in HLists in Scala 3. If you remember Spray, you’ll also know that Spray was using HLists to get around this problem, however sadly it yielded very hard to read compile errors which would scare people away from the routing DSL – so during the rewrite to Akka HTTP, we decided to take the less powerful, but nicer compile errors route – tuples.

Now, this does not mean your task is not solveable; in fact it’s pretty easily solveable: You can nset one parameters directive in another one after all – i.e.

parameters(22 things) { 22 things => 
  parameters(12 things) { 12 things => 
    all 34 parameters are in scope here 

having that said, when using a code gen like guardrail I would expect one could optimize it in other ways rather than using this trick.

Hope this helps; I would really like guardrail to “take off, big time” as it seems like a very promising way to do the right thing™ with regards to swagger integration.

1 Like

Thanks Konrad! Alright, I see it can be nested with that trick, I will give it a go. Guardrail probably could be generating code of the sort (it doesn’t really matter how the generated code looks like, really, so this would do) - although that’s perhaps one of the less important features to focus on at the moment. I agree it would be good to see it “take off”!

Yeah, for that reason I’d probably even rather go the opposite way, generating more optimized lookups than going over the magnets etc – as it would likely yield more performant code – and since routing is executed on each request, it would affect response times a bit. Though likely to only matter in non realistic microbenchmarks – but as we all know, “people” love doing those heh :wink: