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.