ArangoDB FOXX 节点扩展

Question

I'm trying to move an application from sails to FOXX. I was expecting that I could use node.js modules in FOXX but I ran into a problem. I need to create a "working" directory on the server to perform operations to SCM repositories. I installed the "remove" and "mkdirp" modules. The mkdirp module calls fs.lstatSync which is reported missing under FOXX. Installing a local node copy of fs doesn't solve the issues.

If this is a problem then some of my other tasks, like spawning an external command line programs might not be possible. In this case I may need to rethink moving all tasks to FOXX but that would mean replicating a lot of functionality in both sails and FOXX which could be a deployment nightmare.

Answer 1

While Foxx is very flexible, it's "just" running in ArangoDB's JavaScript environment. This environment isn't fully compatible with Node (and hence some modules on NPM), especially when it comes to async code or file system and network I/O.

Specifically the fs module differs Node's built-in fs module.

Luckily the two functionality the remove and mkdirp modules provide is already built-in in ArangoDB's fs module:

• fs.makeDirectoryRecursive is equivalent to mkdirp
• fs.removeDirectoryRecursive is equivalent to remove

It is possible to spawn external processes from within ArangoDB but the relevant functionality is part of the internal API and not intended to be used in Foxx services (among other limitations there is currently no way to get at the output, just the exit status).

Depending on what you want to achieve and what your performance requirements look like, it may indeed be a better idea to separate I/O-heavy code out into an external Node microservice. Foxx is best-suited as an application logic wrapper around the underlying database and all Foxx code effectively runs alongside other ArangoDB JavaScript code so long-running requests can impact the ability of ArangoDB to handle other requests that need to touch the JavaScript layer.

In your particular case (you mention interacting with SCM software) I would recommend creating a small standalone Node service to deal with the SCM related logic and communicating from sails with both as necessary (or even between the two services directly). While this means some added overhead initially it will also be far more scalable than spending CPU cycles in ArangoDB on non-database related tasks.