10

I'm learning more about ArangoDB and it's Foxx framework. But it's not clear to me what I gain by using that framework over building my own stand alone nodejs app for API/access control, logic, etc.

What does Foxx offer that a regular nodejs app wouldn't?

Yehosef
  • 16,151
  • 4
  • 31
  • 53
  • 2
    For the moderator(s) marking this to close as being opinion based - it's not. I'm not asking "which is better" - I'm asking "what's the difference". – Yehosef Feb 10 '16 at 11:09
  • The question should rather be, what kind of logic to put into the nodejs application, and what into a FOXX-service. More in the full reply soon. – dothebart Feb 10 '16 at 12:00
  • 1
    No - I'm asking if there is any benefit to having a foxx application instead of a stand-alone nodejs app. Your version of the question seems to assume there is some advantage to a Foxx app and you should obviously have one - just what logic might you want to put outside. I am questioning that assumption - what benefit does writing the Foxx app give me? – Yehosef Feb 10 '16 at 13:24
  • I agree with @Yehosef. This is a valid enough question as it is. However he chooses to express his question is his/her business and it is very much in line with what StackOverflow is about. – Glstunna Feb 23 '16 at 06:09

1 Answers1

12

Full disclosure: I'm an ArangoDB core maintainer and part of the Foxx team.

I would recommend taking a look at the webinar I gave last year for a detailed overview of the differences between Foxx and Node and the advantages of using Foxx when you are using ArangoDB. I'll try to give a quick summary here.

If you apply ideas like the Single Responsibility Principle to your architecture, your server-side code has two responsibilities:

  1. Backend: persist and query data using the backend data storage (i.e. ArangoDB or other databases).

  2. Frontend: transform the query results into a format acceptable for the client (e.g. HTML, JSON, XML, CSV, etc).

In most conventional applications, these two responsibilities are fulfilled by the same monolithic application code base running in the same process.

However the task of interacting with the data storage usually requires writing a lot of code that is specific to the database technology. You need to write queries (e.g. using SQL, AQL, ReQL or any other technology-specific language) or use database-specific drivers.

Additionally in many non-trivial applications you need to interact with things like stored procedures which are also part of the "backend code" but live in the database. So in addition to having the application server do two different tasks (storage and rendering), half the code for one of the tasks ends up living somewhere else, often using an entirely different language.

Foxx lets you solve this problem by allowing you to move the logic we identified as the "backend" of your server-side code into ArangoDB. Not only can you hide all the nitty gritty of query languages, edges and collections behind a more application-specific API, you also eliminate the network overhead often necessary to handle requests that would cause more than a single roundtrip to the database.

For trivial applications this may mean that you can eliminate the Node server completely and access your Foxx API directly from the client. For more complicated scenarios you may want to use Node to build external micro services your Foxx service can tap into (e.g. to interface with external non-HTTP APIs). Or you just put your conventional Node app in front of ArangoDB and use Foxx to create an HTTP API that better represents your application's problem domain than the database's raw HTTP API.

It's also worth keeping in mind that structurally Foxx services aren't entirely dissimilar from Node applications. You can use NPM dependencies and split your code up into modules and it can all live in version control and be deployed from zip bundles. If you're not convinced I'd suggest giving it a try by implementing a few of your most frequent queries as Foxx endpoints and then deciding whether you want to move more of your logic over or not.

Alan Plum
  • 10,627
  • 4
  • 37
  • 53
  • Thanks for the detailed response. I am trying a sample application and I as I started I had this question. The main real advantage I see so far is that it reduces the round-trip from the app to the server or If I want to include a bundled app with the database for prototype work. Where I started to feel the wrinkles are when I thought about implementing caching, metrics, or job queueing based on object creation. I wouldn't think I would want that inside my database and normally I would have something outside of the database to handle that layer. ... – Yehosef Feb 10 '16 at 15:35
  • once I need to have something outside - I was less clear why all the logic shouldn't live there.. But I hear your points and can see the value. I'll give it a try and see how it goes. BTW - thanks for your work - it's a really impressive DB. – Yehosef Feb 10 '16 at 15:37
  • @Yehosef Foxx has your back in both situations. It's up to you how much logic you move into your Foxx services. You can just use Foxx as the equivalent of stored procedures or you can build your entire app in Foxx. As for job queues etc -- it basically comes down to your performance needs. I consider dedicated (external) job queues etc an optimisation -- and in some cases those optimisations may not be worth the development/maintenance overhead. – Alan Plum Feb 10 '16 at 17:05