arangodb 3.1 foxx docs?

Question

I think that arangodb is presently the best nosql db and that foxx microservices are a great resource. Alas, the related docs that comes with the 3.xxx version can help build only a minimalistic service. Also, many apps you can find as examples in the arangodb store have been developed with deprecated tools (eg. controllers, repositories). And while the wizard available in the web interface easily allows to create a new service, I don't understand why a new collection, prefixed with the mount point, has to be created. So a complete REST API is generated with a great documentation, but it is absolutely useless unless I change the name of an already existing collection. Why is that ???

Answer 1

The generator is meant as a quick boilerplate generator to allow you to build prototypes more easily. In practice it's not a great starting point for real-world projects (especially if you already have created collections manually) but if you just quickly need a REST API you can expand with your own logic it can come in handy.

As you've read the docs I'm sure you've followed this Getting Started guide: https://docs.arangodb.com/3.11/develop/foxx-microservices/getting-started/

In it, the reasoning for prefixed vs non-prefixed collection names is given as such:

Because we have hardcoded the collection name, multiple copies of the service installed alongside each other in the same database will share the same collection. Because this may not always be what you want, the Foxx context also provides the collectionName method which applies a mount point specific prefix to any given collection name to make it unique to the service. It also provides the collection method, which behaves almost exactly like db._collection except it also applies the prefix before looking the collection up.

On the technical side the documentation for the Context#collection method further specifies what the method does:

Passes the given name to collectionName, then looks up the collection with the prefixed name.

The documentation for Context#collectionName:

Prefixes the given name with the collectionPrefix for this service.

And finally Context#collectionPrefix:

The prefix that will be used by collection and collectionName to derive the names of service-specific collections. This is derived from the service's mount point, e.g. /my-foxx becomes my_foxx.

So, yes, if you just want to use a collection shared by all your services the unprefixed version (using the db object directly) is the way to go. But this often encourages tight coupling between different services, defeating the purpose of having them as separate services in the first place and becomes problematic when you need multiple instances of the same service but don't want them to share data, so most examples encourage you to use the module.context.collection method instead.