File access in Foxx

ArangoDB is primarily a database. In most cases the best place to store data is therefore inside the database, not on the file system.

The most flexible way to serve files in your Foxx service is to simply pass them through in your router using the context object’s method and the :

While allowing for greater control of how the file should be sent to the client and who should be able to access it, doing this for all your static assets can get tedious.

Alternatively you can specify file assets that should be served by your Foxx service directly in the service manifest using the attribute:

Writing files

• The service folder itself is considered an implementation artefact and may be discarded and replaced without warning. ArangoDB maintains a canonical copy of each service internally to detect missing or damaged services and restore them automatically.

• Writing to files outside the service folder introduces external state. In a cluster this will result in Coordinators no longer being interchangeable.

However in some cases it may be feasible to store smaller files directly in ArangoDB documents by using a separate collection.

Due to the way ArangoDB stores documents internally, you should not store file contents alongside other attributes that might be updated independently. Additionally, large file sizes will impact performance for operations involving the document and may affect overall database performance.

In production, you should avoid storing any files in ArangoDB or handling file uploads in Foxx. The following example will work for moderate amounts of small files but is not recommended for large files or frequent uploads or modifications.

To store files in a document you can simply convert the file contents as a to a base64-encoded string: