API gateway for WebSocket

(TL; DR ... sorry!)
I am working on a project that is very similar to G-WAN. I originally wrote API servlets that worked reasonably well without taking full advantage of the G-WAN capabilities. With some pointers from G-WAN support, I started looking into using handlers; I have ported the API servlets to the URL rewriting routine in the handler (the vast majority of content returned for an API request is static / pre-rendered content). I am now working on a 404 handler routine to catch cases where we have not pre-provisioned the content yet, turning them into on-demand render requests and dynamically generating the response.

From the client side, everything looks completely dynamic. But by rewriting URLs to static paths and allowing the G-WAN to send our requests on demand, it reduces the amount of code we have to write and takes advantage of some highly optimized features in the G-WAN. I mention these details as an example of what Gil called "mold breakdown." Initially, our approach was very similar to how we would do the implementation with nginx (except without the need for a gateway like fcgi). This was pretty good, although we once split into requirements and dropped many assumptions about how web services should be built.

One word of caution if you plan on doing C ++ development. G-WAN communication with external libraries is "C", not "C ++". They did it in terms of performance and memory (good choice), but I didn't think completely when I started writing some C ++ library routines that I was going to reference from my servlets and G-WAN handlers in addition to being to be referenced by various C ++ applications. It's not a showstopper - a lot of "C" libraries that work great with C ++ applications. But it would be cumbersome to link to the dynamic C ++ class library (.so) via the "C" link via the G-WAN from the servlet. (My simple fix was to move my "generic" C ++ code to.h and just include them in my G-WAN handlers and servlets as well as in my C ++ applications. Not clean, but appropriate.)

To your 5 specific points from a G-WAN perspective:

• Depending on your definition of "parsing" and "fancy", this can easily be done in C / C ++ in your protocol handler, or you can use external libraries. There are several ways to make this asynchronous, be it separate processes or perhaps just non-blocking I / O if blocking is an issue.

• Also easily manipulated by the handler.

• Also.

• Yes. :) Depending on the level of support you want. Free if you solely rely on SO and other community support. We opted for a low-cost support subscription and the responses significantly exceeded our expectations.

• Oh yeah! We have confirmed that in the first few days.

Oh, and one last thing: when you've spent an hour or two recording some of the G-WAN servlets, you might find it difficult to go back to other web application and service engines. With servlets, I just save my changes in the editor and refresh the refresh in the browser window to see the new result (try with the fcgi implementation!). I have multiple G-WAN instances running on my server (configured for different IP addresses and port numbers), so on one machine I have multiple steps of basic development codes as well as a production server. For development, I run G-WAN in a terminal session (not as a daemon) and can use printf (...) in my servlets and handler codecs to see what is happening on the backend server and what is happening in my browser window ...

For more information:

• G-WAN protocol handler
• G-WAN User Guide (starting on 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