WebSocket的API网关

（TL; DR …对不起！）
我正在做一个与G-WAN非常类似的项目。 最初，我写了API servlet，工作得很好，没有充分利用G-WAN功能。 从G-WAN支持的一些指针，我开始探索使用处理程序; 我将API servlet移植到处理程序中的URL重写例程中（绝大多数API查询返回的内容都是静态/预先呈现的内容）。 我现在正在处理一个404处理程序，以捕捉那些我们还没有预渲染内容的情况，将它们转化为按需渲染请求并动态构建响应。

从客户端来看，这一切看起来完全动态。 但通过对静态路径进行URL重写，并允许G-WAN派遣我们的按需案例，它减少了我们必须编写的代码量，并利用了G-WAN中一些高度优化的功能。 我把这些细节作为吉尔所说的“打破模具”的例子来提及。 最初我们的方法看起来很像我们将如何使用nginx来实现（除了不需要像fcgi这样的网关）。 尽管我们一旦剥离了需求 ，就抛弃了许多有关如何构建Web服务的假设，这已经有了很大的改进。

谨慎的一句话，如果你打算在C ++中进行开发。 从G-WAN到外部库的链接是“C”而不是“C ++”。 他们做了这样的性能和内存占用的理由（很好的选择），但我没有想到，当我开始编写一些C ++的库例程时，我打算从我的G-WAN servlet和处理程序中引用，除了从各种C ++应用程序引用。 这不是一个显示器 – 大量的“C”库在C ++应用程序中工作得很好。 但是从servlet通过G-WAN通过“C”链接引用动态C ++类库（.so）会很麻烦。 （我简单的解决方法是将我的“共享”C ++代码移动到.h文件中，并将它们包含到我的G-WAN处理程序和servlet以及我的C ++应用程序中，不干净但方便。

从G-WAN的角度来看，从你的5个特定的角度来看：

1. 根据“分析”和“非常规”的定义，这可以很容易地在你的协议处理程序中用C / C ++完成，或者你可以使用外部库。 有多种方法可以实现异步，或者作为单独的进程，或者可能只是非阻塞的I / O，如果阻塞是一个问题。

2. 也很容易从处理程序管理。

3. 同上。

4. 是。 :)取决于你想要的支持水平。 如果您完全依赖SO和其他社区支持，则免费。 我们选择了一个低廉的支持订阅，并且回应已经超出了我们的预期。

5. 哦耶！ 我们在头几天证实了这一点。

哦，还有最后一件事：一旦你花了一两个小时写了一些G-WAN servlet，你可能很难回到其他的web / app / service机制。 使用servlet，我只需保存编辑器中的更改，然后在浏览器窗口中刷新以查看新结果（使用fcgi实现尝试！）。 我在我的服务器上运行了多个G-WAN实例（针对不同的IP地址和端口号进行配置），所以在一台机器上，我有多个开发代码库阶段，还有一个生产服务器。 对于开发，我在一个终端会话（而不是一个守护进程）中运行G-WAN，并且可以在我的servlet和处理程序代码中使用printf（…）来查看后端发生的事情。我的浏览器窗口。

欲了解更多信息：

• G-WAN协议处理程序
• G-WAN用户手册 （从第34页开始）
• 处理器状态
• 从servlet，处理程序调用库函数
• 并查看G-WAN安装包的处理程序文件夹中的示例。

祝你好运！
肯

一个G-WAN protocol handler可以让你实现这样一个代理来通过一个单独的连接（或者每个工作者线程的连接来获得更多的可伸缩性）来复用请求。

这就是G-WAN变得容易：打破模具创建定制解决方案。