Here is another attempt at a WebServer for VL:
Available as prerelease nuget:
nuget install vl.io.http.webserver -pre
Please test and report your findings!
I am currently trying to implement a webhook endpoint in vl (which is HTTP post usually), for which I need deep insights into query data, such as headers, mime-types and data streams. I need individual response containers for each query. As modern net libraries are full of await keywords, most of that is in the Observable category. Http is okay for now, but https would be better eventually.
Since my use case cannot afford to drop queries, the ole’ vvvv beta nodes are a good way to do basic checks, but are a bad way to use for a running system. Still, even they seem more versatile than the VL.IO.HTTP.WebServer.
I was hoping this initiative could help me connect vl to a webhook, but it seems this first wip only covers most basic internet media delivery, in a restricted geocities-static-files-only kind of way.
It would be nice to know, what your goals are, for this project. Or what user stories are supposed to be solved with it.
This is my take on it so far. It is not working as expected, so I’d rather not share the code, until you have shared your intent with VL.IO.HTTP.WebServer.
It is based on HttpListener
exactly. step one. simplest case.
but please have a look at the underlying library to see where the journey will go. you can read the code, it is very well written and structured. from what i understand your usecases should be coverable with using what the lib offers via static or dynamic routes.
How would you patch a binding with a custom response like this?
Don’t get me wrong, the possibilities to have super flexible routing of complex queries depending on the path is surely amazing for anything REST. But my use case is much simpler, I only have a single path here, something like http://localhost:8080/myHook/.
Right now I am even more flummoxed about how this Watson lib can help with the basic vl use case, where one wants to asynchronously react to every query depending on what parameters are inside the HttpContext ctx .
wouldn’t that just be something like (if you hack it into the current status of the lib)?!
yes, this looks promising. would it work for multiple messages in a very short timeframe too?
edit: I would need to aggregate some info from each query too, this could be hard with delegates.
Maybe you can push those Infos to some concurrent collection in the delegate?
yeah, had the same thought. and in fact, ConcurrentDictionary is pretty much all that is needed.
Mind you, doing it this way feels kind of dirty. I would much prefer a proper Observable pipeline at this point, as this here definitely goes against the grain of vl data flow.
Patching the Delegate proved to be super awkward, because the handler needs to be removed and re-added everytime it is changed.
.
Note that the cache inputs are actually misleading here - if you change the path or the method, it will simply keep on adding more handlers instead of updating.
So dealing with Watson in vl was not as great an experience as you’d wish. So ❤ for Watson for helping to solve my case, but a personal -1 for being the general lib to solve future http challenges.
@velcrome I wouldn’t be so quick to judge. The routing feature can be nicely exposed, see https://github.com/vvvv/VL.IO.HTTP.WebServer/pull/2 - once that is done, it’s rather trivial to create a static route which for example pushes request data via an observable:
oh, that is nifty! subjects, of course!
that way the actual delegate can be hidden in the vl lib, and doesn’t need to be ever changed by a user, either. just send out the context, if you are at it, because you might want to manage both request and response later in the pipeline
edit: if that is possible, seems like the Result of the delegate is a necessity?!
edit2: my reservations against watson remain, though. vanilla HttpListener should be a better base for a general vl lib
latest nugets now comes with WebServer (Routing) that easily allows you to serve dynamic content as shown in elias screenshot above.
please elaborate on that. can you tell us more about your usecase and how you’d expect to handle it?
also please elaborate on how using HttpListener would be better for your usecase.
my remarks were more geared towards a general lib, and much less towards my current use case, hence the Thank Y❤u.
this is about general usage. If you try to edit the insides of the delegate and test a little, you will soon see what I mean: changes to the delegate will only update with restarting the patch (or manually removing and re-adding the delegate from the manager), which will be troubling for anybody, who picks up the lib for the first time
this is easy: less dependencies is almost always better, and resorting to standard libs is better than rolling your own. frankly, the hoops Watson jumps through just to provide Regex path routing support are quite insane - and maybe it is enough to generally stick with standard wildcard routing (as provided by windows and exposed by .net gac libs).
I also don’t feel well about the random Json.NET dependency watson ships with.
have you experienced this with the latest nuget? because due to another nifty trick (proxy delegate, see implementation of the StaticRoute region) this should not be the case.
as you know, the beauty of nugets is that you can selectively use them or not. so i don’t see the need to argue any further here.
hey joreg, I did some thinking about what you said there, because it seems to again follow a bad pattern I have seen before: a rethoric for feedback, but a take-it-or-leave-it attitude if it doesn’t fit your preconceptions.
you were the only one that felt there was arguing going on here. I simply tried to help your quest for constructive feedback, and detailed your questions by presuming they were in earnest. so a simple “thanks, will consider it” would have been appreciated. there truely never was any antagonism, unless you took offense that I gave my biased, but informed opinion openly.
so I just want to leave this quote for you, pin it on your fridge maybe. its from a guy who collected a couple million dollars on kickstarter.
Just make sure feeback is as wide and varied as possible by encouraging it all the way.
ps: I wish I could mark this post as a spoiler or as irrelevant for the actual topic
i agree: less dependencies is better.
i didn’t mean to be ignorant. with “no need to argue” i meant about the specific dependencies in this case. they are what they are. that would need to be discussed with the underlying library.
did any one try to run server on different ip address then 127.0.0.1?
when i run it in on actual ip of the machine, it’s not listening.
@rayment i thought i had put a link to these infos, regarding this issue:
https://github.com/jchristn/WatsonWebserver#important-notes and https://github.com/jchristn/WatsonWebserver#accessing-from-outside-localhost