Lapis is the framework that itch.io uses. [1] It also uses MoonScript [2] as the programming language which was also written by the creator of itch.io/Lapis.
Look under skip_render here: https://leafo.net/lapis/reference/actions.html#render-option...
I have often read on HN that not accepting a PR for a feature that is not tangential to the core business of the project is valid and understandable when the maintainer believes it will require too much resources (bug triage, fixes, documentation, short or long term support in the forums, etc.) from him.
How exactly is this complaining? I am merely making an observation, not even in the earshot of their devs. I had evaluated Lapis years ago, but quickly moved on when it didn't seem adequate. I didn't complain about that in their issue tracker then, and I am not going out of my way to bring this up now because I am holding a grudge like you are implying. Whether or not they add websocket today wouldn't matter to me in the least, I am simply indifferent to it.
> it is logical that the main developer who used it to build itch.io is not going to put in the effort to do something they don't care about
There are plenty of frameworks that add features well beyond what the devs need for their own products. All I am saying is it might be more logical for other people here to use those instead. Of course people can come to this conclusion on their own, but highlighting what I believe to be a key information may save that time.
It is useful information for potential users to know how the project works and if it might not fit them well. There's no contract or agreement between the maintainer and users. Users are free to talk about the project. As long as they don't demand anything I don't see the issue at all.
Last I investigated, the ergonomics of the websockets API in OpenResty didn't really seem like a good candidate for building websocket based applications. As an example, there's no trivial way to keep track of all connected clients and broadcast a message to them without overly complicated solutions. It's not trivial to listen to events from different asynchronous sources at the same time. (probably other things too but I don't remember right now) OpenResty/Nginx is not a general purpose event loop. The fact that it's primarily an HTTP webserver is evident in the design of the interfaces that are made available.
That said, there's nothing stopping you from and utilizing the `ngx` APIs directly, there are just a few considerations to be made with database connection pooling, but generally you can `require` any Lapis module and use it anywhere in Lua code. For websockets in OpenResty look here: https://github.com/openresty/lua-resty-websocket
The reason the issue is still open is not because I'm not interested in adding it, but because I didn't feel Lapis could provide a useful abstraction at this time.
In any case, I sympathise with being constrained by design/interface of underlying technology. One one hand, I suspect like most people I lack the knowledge of Nginx internals or its Lua API. But on the other hand, it's cool that one has an escape hatch in terms of being able to leverage other solutions from the underlying platform.
My last two cents on this matter (not a criticism or demand), since the docs are beginner friendly, perhaps a likewise friendly guide on dropping down to `ngx` API for the rare case when such escape hatches are needed (e.g. cookbook for this websocket scenario) could be beneficial for end user, even if the primary focus of Lapis is to enable one to not have to do that.