Clojurians Log v2
pedestal 2025-02-09
Oh, Pedestal is very wedded to a Servlet API approach, and HttpKit is a very NOT Servlet API approach. The WebSocket side will be tricky to implement because Pedestal doesn't know if it's a web socket connection request until after routing. May need to use an explicit worker pool plus some core-async to get things the way they need to be. Essentially, two different competing visions about when you initiate some asynchronous behavior, and how.
Or, do it the right way, deprecate most of io.pedestal.http, replace it with io.pedestal.service (that does similar things but in a better way).
I like that route (hah, see what I did there?)
It's a lot of new documentation.
Progress continues. Matching the Http-Kit request lifecycle (especially async) to Pedestal's request lifecycle (especial async) has been challenging, especially for the test mode (where the HTTP communication is abstracted out).
I think I'm going to punt on WebSocket support in Http-Kit until a later PR. The PR is already giant.
Very happy with how its coming out. Just beginning to fit the jigsaw puzzle back together.
FWIW as we at Nubank consider moving away from Jetty (and consequently the Servlet API), it would be interesting to explore what moving entirely to the "Servlet-API-less" approach would look like. Does anyone really care that Pedestal is implemented on top of the Servlet API? thinking-face
At work we tried switching out jetty with helidon: https://github.com/xledger/pedestal-helidon What brought us back to jetty was we needed some servlet functionality, e.g., this one: https://mvnrepository.com/artifact/org.eclipse.jgit/org.eclipse.jgit.http.server
There's a meta aspect to this ... how far can we iterate changes to Pedestal without it changing to something else entirely? I haven't looked at Paul deGrandis' Pedestal 2.0, but I can guess that it's a lot less dynamic than Pedestal 0.x, in the name of speed. I've been somewhat cavalier about backwards compatibility at the edges in order to make improvements, and I've been deprecating what I can with improved replacements. io.pedestal.http is central to Pedestal but is kind of a mess; it's like an experiment in "data > code > macros" that doesn't quite stick the landing. What I found working with similar challenges in lacinia-pedstal was to provide a function that would set things up in a default, but limited way (suitable for tutorials or initial experimentation), and the documentation encouraged you to stop using that function in a real application. The majority of the keys in the service map exist just to configure the default interceptors; the ones that really count are the subset that are passed to the container: :port, :host, etc. I would rather have a series of focused functions, that each build and configure an interceptor and add it to the http/interceptors key. I think there should be a distinction between HTTP and Servlets; the core abstractions should treat the servlet API as an optimization or necessary adaption (i.e., for when deployed as a WAR). So in a release with a lot of breaking changes, do we dare make some really in your face breaking changes?
Currently working on a new test layer that doesn't need mock Servlet API objects at all, but is otherwise pretty similar to io.pedestal.test.
So far, this is all additive. I predict a big cleaning of the house in 0.9 because some day I would like to have a 1.0.