Our mg_go interface (in common with all our other language bindings) can invoke M functions and Cache/IRIS class methods - the latter being only available for InterSystems platforms of course. SQL statements can be embedded in those functions/methods. So mg_go can work with SQL, albeit indirectly through functions/class methods. Those wanting a purist SQL interface would probably be more comfortable with a JDBC/ODBC solution.
Any server fronting access to a database can be abused and to say one is better/worse than the other with regards security is a specious argument to say the least. For example, Dmitry has been able to easily get third-party access to the IRIS server by using an easily observable, though unpublished, protocol offered by InterSystems own server. Presumably, a malicious developer would be able to do the same. Of course, the same would be true of our server.
As Rob has mentioned, the reason why we don't use the InterSystems superserver is that the protocol is unpublished and, as far as I know, permission for third party products to use it has not been granted. That, in itself, would be enough to ring alarm bells with the customers that we deal with. Also, InterSystems have the right to change their protocol, or restrict access to it downstream - and without notice.
There are 2 connectivity modes to choose from for mg-dbx-napi.
1. API based - in which case you don't need any superserver at all. So, this mode will work "out of the box".
2. TCP based - you do, of course, need a superserver for this. We cannot use the InterSystems superserver listening on port 1972 as that's a proprietary server provided by InterSystems and, as far as I know, there's no public API for third party products to use. If there was, we would use it. But, for now you have to use our superserver - which is not a big deal for most of our users.
Not sure what "additional tools" you're referring to here. At the Node.js end, mg-dbx-napi is invoked directly through the official Node API and at the server end it connects to the official Cache/IRIS API. There're no other components involved.
Bear in mind that a superserver of any sort is only necessary if you configure mg-dbx-napi to connect to IRIS over the network. The best performance is realized by connecting to a local IRIS instance via its API.
That said, the reason why we developed our own superserver is because, as far as I know, the IRIS superserver does not have a public interface. In other words, it only works for InterSystems products. If this situation ever changed, we would of course converge on the superserver embedded in IRIS. This would make our installation process much simpler.
I've come to this party quite late but there is yet another solution to consider ...
https://github.com/chrisemunt/mg_php
This solution provides granular access to Cache/IRIS globals, functions and classes. It is network based and can therefore be used in enterprises where the web server and PHP engine are installed on a separate server to that hosting Cache/IRIS.
An earlier version of this module has been running in the field for quite a long time but it has taken me a while to get around to making it more widely available. In fact, those who have a penchant for a certain line of fast food might have used this code already :)...