API gateway for WebSocket
(TL;DR ... sorry!)
I'm working on a project doing something very similar with G-WAN. Initially, I wrote API servlets, which worked quite well didn't take full advantage of G-WAN capabilities. With some pointers from G-WAN support, I started exploring the use of handlers; I ported my API servlets to a URL-rewrite routine in a handler (vast majority of the content returned for an API query is static / pre-rendered content). I'm now working on a 404-handler routine to catch the cases where we don't (yet) have the content pre-rendered, turning them into render-on-demand requests and building the response dynamically.
From the client side, it all looks totally dynamic. But by doing URL-rewrites to static paths and allowing G-WAN to dispatch our on-demand cases, it reduces the amount of code we have to write, AND makes use of some highly-optimized features in G-WAN. I'm mentioning these details as an example of what Gil referred to as "breaking the mould." Initially our approach looked a lot like how we would do an implementation with nginx (except without the need for a gateway like fcgi). It has been quite an improvement though once we stripped down to requirements and threw away many assumptions about how web services should be constructed.
One word of caution, if you plan on doing development in C++. The linkage from G-WAN to external libraries is "C" and not "C++". They did this performance and memory-footprint reasons (good choice), but I hadn't thought that through fully when I started writing some library routines in C++ that I intended to reference from within my G-WAN servlets and handlers in addition to being referenced from various C++ applications. It's not a showstopper - plenty of "C" libraries out there that work just fine with C++ apps. But it would be cumbersome to reference a dynamic C++ class library (.so) via a "C" linkage through G-WAN from a servlet. (My simple fix was to move my "shared" C++ code into .h files and just include them into my G-WAN handlers and servlets, as well as in my C++ apps. Not clean, but expedient.)
To your 5 specific points, from a G-WAN perspective:
Depending on your definition of "analyse" and "unusual" this could easily be done in C/C++ within your protocol handler, or you can make use of external libraries. There are multiple ways to make that asynchronous, either as separate processes or maybe just non-blocking I/O, if blocking is an issue.
Also easily managed from a handler.
Ditto.
Yes. :) Depends on the level of support you want. Free if you rely exclusively on SO and other community support. We opted for an inexpensive support subscription, and the responses have well exceeded our expectations.
Oh yeah! We confirmed that in the first few days.
Oh, and one last thing: Once you have spent an hour or two writing some G-WAN servlets, you may have a hard time going back to other web/app/service mechanisms. With servlets, I just save my changes from the editor and hit refresh on the browser window to see the new result (try that with an fcgi implementation!). I have multiple instances of G-WAN running on my server (configured for different IP addresses and port numbers) so on a single machine, I have multiple stages of development code bases, plus a production server. For development, I run G-WAN in a terminal session (not as a daemon), and can make use of printf(...) in my servlet and handler codes to see what is happening on the back-end vs what happens in my browser window.
For more info:
- G-WAN Protocol Handler
- G-WAN User's Manual (starting around page 34)
- handler states
- calling library functions from servlets, handlers
- and also look at the examples in the handlers folder of the G-WAN installation package.
Good luck!
Ken