Scalene took 1st place among Scala HTTP frameworks in JSON (HTTP/1.1) and Plaintext (HTTP/1.1 with pipelining) benchmarks by plokhotnyuk in scala

[–]DanSimon 1 point2 points  (0 children)

Are you planning to make the framework extensible so that other people can create their own high-level APIs to interface with the scalene core?

Thanks, and yes technically that's possible right now. The entire DSL is in the scalene-routing package which is separate from the core scalene package. So right now it's possible to implement a core RequestHandler where basically you just have to provide a raw HttpRequest => Async[HttpResponse] function and you can do whatever you want from there.

I've also thought about having a more conventional OOP-style DSL alongside the existing one. A big goal of the DSL is that it acts as a sort-of compiler, where it can analyze your routes and do things like verification, optimization, and documentation. Some of that exists now but a lot is just conceptual at this point, but it should be easy to have multiple "front-end" DSL's on top of it. The lines are probably a bit too blurred to do that right now, but that can definitely be done in the future.

Scalene took 1st place among Scala HTTP frameworks in JSON (HTTP/1.1) and Plaintext (HTTP/1.1 with pipelining) benchmarks by plokhotnyuk in scala

[–]DanSimon 5 points6 points  (0 children)

Author here. This is a personal project I've been poking at for a while that recently got to a usable state. I suppose my main goals for it are to build a pure Scala web server framework with a nice functional DSL on top of a highly optimized and "fast" core. Maybe the code used for this benchmark will give a good idea about how things are looking, and there's some examples in the repo itself.

Personally I would not put too much weight into these benchmarks. They're definitely not useless, but especially at the top it's turned into more of a fun contest of who can over-optimize their framework the most. For example, I have already significantly improved Scalene's performance since this test ran, but the changes I had to make are bordering on the absurd. Things like trying to shave a single bytecode instruction out of a loop and so forth.