The generated API documentation in ArangoDB 2.6 has been updated to Swagger 2. To see the API documentation for any of your Foxx apps, open the web admin frontend and select your app from the Applications tab. For information on how to describe your own APIs in the generated documentation, see the ArangoDB documentation.

But wait, there’s more! In addition to being shown in the web admin frontend, ArangoDB 2.6 allows you to mount your app’s documentation inside the app itself. Using the new controller method apiDocumentation you can define a mount point for the app’s own documentation and apply the same access controls you already use for other routes. Depending on your needs, you can even mount the documentation of other apps in your own Foxx app, use different assets or even your own Swagger API description files. In fact, the new API documentation viewer of the web admin frontend itself is using it.

For more information on the apiDocumentation method, see the documentation. If you want to give the feature a try yourself, check out ArangoDB 3.0 or compile the latest development version from the GitHub repository.

Previously on the ArangoDB blog we saw how we can use the configuration field in manifest.json to make Foxx apps configurable and more re-usable. This is all well and good if we just want to pass in simple values to a Foxx app but sometimes you want to pass in entire Foxx apps. This is where dependencies come in to save the day.

Let’s say you want to use the session storage provided by the ArangoDB sessions app available on the Foxx app store using Foxx exports and imports. Because you hadn’t yet heard of configurations, you simply hard-coded the mount path of your copy of the sessions app in your code: (more…)

While the optional configuration field in Foxx manifests had experimental support all the way back to ArangoDB 2.1, the feature was previously undocumented and not well understood. The upcoming ArangoDB 2.6 release officially introduces Foxx configurations, allowing you to make your existing Foxx apps more re-usable and to make better use of third-party apps.

Let’s say your Foxx app needs an API key to make a request to a third-party service using the request module introduced in ArangoDB 2.5. (more…)

Aside from the more noticeable features, ArangoDB 2.5 also added the console object to the scope of all Foxx app modules. Unlike the object already available by importing the console module, the Foxx console logs all messages directly to the database.

In addition to allowing you to specify per-application log levels to make sure your debug messages don’t end up cluttering your production database, the API also provides useful extras like optionally logging a full stack trace for every message that is stored as a structured list of objects, making them easy to query using AQL. There’s also a number of convenience methods for querying your application’s log entries from within your Foxx code if you prefer keeping it simple.

console.time('do something');
// ... more code ...
console.time('do more stuff');
// ... even more code ...
console.timeEnd('do more stuff'); // => "do more stuff: 23ms"
// ... a little bit more ....
console.timeEnd('do something'); // => "do something: 52ms"

For more information see the chapter on the Foxx console API in the official ArangoDB documentation.

We are working hard to improve usability and simplify the usage of Foxx which will be shipped with version 2.5. of ArangoDB.

We have learned from the past and collected a lot of feedback, thanks to all people using Foxx already. It helped us to identify the following three important areas of Foxx that should be improved:

1. Debugging of Foxx apps
2. Getting started with Foxx
3. Development Mode
   (more…)