Thread:Talk:Requests for comment/Caching Overhaul - Frontend Proxy/Node.js backend vs Varnish plugin

Node Considerations
 * + Failure of the banner code does not take down the rest of cluster
 * That's a strong statement which may not be true for either case. :)


 * + Faster development with fewer bugs
 * + Faster deployment in case of bugs/changes
 * - Requires a wrapper to be written around Maxmind's GeoIP libraries and it's another place to update that data
 * That data is already automatically updated on all servers by Puppet, so that doesn't matter.


 * - Requires additional servers to be provisioned and maintained in all our data centres (for optimal latency)
 * Not necessarily, because we could choose to run them on the same servers as Varnish. With a Varnish plugin, we don't really have a choice.


 * ? Node's efficiency
 * ? Portability -- we will be locked to this technology
 * ? Though not addressed in this RFC, with node we can run dynamic JS locally on the server that is served with a banner from the backend that can determine if it wants to display or not -- saving bandwidth. Potentially we could do the same thing in a VMOD with Lua.
 * Bandwidth is hardly a problem between these servers.

Varnish VMOD Considerations
 * + Can be developed as a standalone library with VMOD/Nginx/PHP bindings for portability without changing core code
 * + Can use GeoIP code already written
 * Existing GeoIP code is just a few lines calling into libgeoip, so that hardly makes a difference.


 * + Can eventually reside on the frontend proxy obviating the need for additional servers once proven
 * Actually needs to reside on the Varnish frontend proxies, as opposed to a backend which can reside anywhere.


 * - Bigger, more rapidly changing, list of servers that will need to be tracked by CentralNotice for purging purposes (possibly can use built in MediaWiki purge mechanism with some changes)
 * - Slower to develop / deploy
 * ? Likely to be faster / more memory efficient than node once optimized
 * Yes. Of course, it's also possible to use C/C++ for a backend implementation, which is an independent question. But I think Node.js is reasonable for now.

In general, writing it as a (Node.js) backend means less coupling and more flexibility. I don't see any strong drawbacks to that approach in the above.