There’s also https://github.com/andyfriesen/buffer-builder-aeson – how do they compare?
I’ve updated the benchmarks to include “buffer-builder”. It’s not very different from “aeson”.
jsonifier/1kB mean 2.087 μs ( +- 260.0 ns )
jsonifier/6kB mean 12.33 μs ( +- 222.2 ns )
jsonifier/60kB mean 118.3 μs ( +- 1.991 μs )
jsonifier/600kB mean 1.270 ms ( +- 38.92 μs )
jsonifier/6MB mean 20.53 ms ( +- 1.042 ms )
jsonifier/60MB mean 194.9 ms ( +- 15.04 ms )
aeson/1kB mean 6.542 μs ( +- 199.2 ns )
aeson/6kB mean 31.25 μs ( +- 494.5 ns )
aeson/60kB mean 261.7 μs ( +- 8.044 μs )
aeson/600kB mean 3.395 ms ( +- 114.6 μs )
aeson/6MB mean 30.71 ms ( +- 701.0 μs )
aeson/60MB mean 277.1 ms ( +- 4.776 ms )
lazy-aeson/1kB mean 6.423 μs ( +- 83.69 ns )
lazy-aeson/6kB mean 30.74 μs ( +- 607.0 ns )
lazy-aeson/60kB mean 259.1 μs ( +- 4.890 μs )
lazy-aeson/600kB mean 2.511 ms ( +- 18.71 μs )
lazy-aeson/6MB mean 24.92 ms ( +- 95.36 μs )
lazy-aeson/60MB mean 248.6 ms ( +- 736.6 μs )
buffer-builder/1kB mean 5.512 μs ( +- 77.39 ns )
buffer-builder/6kB mean 30.29 μs ( +- 459.9 ns )
buffer-builder/60kB mean 307.0 μs ( +- 3.640 μs )
buffer-builder/600kB mean 3.001 ms ( +- 75.72 μs )
buffer-builder/6MB mean 33.05 ms ( +- 336.3 μs )
buffer-builder/60MB mean 308.5 ms ( +- 3.489 ms )
Looks pretty neat! Though I do wonder whether creating two new entirely separate libraries ptr-poker and jsonifier is really necessary. There already is the store-core package which seems to do about the same as ptr-poker, and it might be possible to optimize aeson using jsonifier’s approach.
I don’t see anything bad in having more packages. It lets the authors of different solutions continue research in different directions. It drives competition raising the overall quality of the ecosystem. It provides separation of concerns, better focus on the problem and provides more space for the author to experiment without having to approve any decision. It makes the author responsible for maintenance of his code, instead of maintainers of the package which he would have PR’ed to. Finally it lets the author collect the reputational benefits in the community for his work.
Concerning “store-core”, as you may notice in the type definitions, the abstractions are not the same and they don’t exactly fit the requirements of the presented approach.
Concerning “aeson”. It can be updated to utilise the benefits of “jsonifier” by depending on it and replacing its Encoding abstraction with it. No need to bundle “jsonifier” as part of “aeson” for that. Also not everyone agrees with the design of “aeson” with its typeclass centrism, myself including. I believe that “aeson” lacks in flexibility and its typeclass layer introduces a redundant complication to the otherwise straightforward problem of composing with functions. E.g., here’s a take on that problem from the author of the Elm language. So “jsonifier” approaches that problem as well, serving the needs of people sharing that vision. In fact, the design of “jsonifier” is quite similar to that of Elm’s JSON encoding lib.
I’m wondering what this has that http://hackage.haskell.org/package/fn doesn’t (disclosure, I’m one of the primary authors).
 Actually, looks like strelka might actually be doing less, as you aren’t able to write handlers that take typed arguments, as far as I can tell. So this really just looks like the type of routing that Snap and Happstack have had for years and years…
Compared to Fn,
Strelka provides higher-level abstractions with simpler signatures, e.g.:
method :: StdMethod -> Req -> IO (Maybe (Req, a -> a))
getMethod :: Monad m => RequestParser m ByteString
No custom type-classes or operators. Instead the standard interfaces like Alternative and Monad are used
Streaming of both the request and the response bodies, instead of aggregating them in memory
API is isolated, providing for clarity and nudging the users towards separation of concerns
API is also isolated on the package-level, having all the features that the end-user won’t need located in a separate package (“strelka-core”).
Since it’s only the first official release, some features are yet to be implemented. E.g., the parameters' and URL-encoded body parsers are already slated. But overall, since you’re asking, IMO, Strelka is much simpler and more intuitive than any of the mentioned libraries, yet it aims to let the user solve the tasks of any complexity.