Test Driven Development

I have been one of the lucky attendants of scotland.js in Edinburgh recently.
It was a really nice & informative conference, thanks to all people that made it possible.
I did really like to see that TDD is reaching the front-end developers finally.
A lot of useful tools for this have been presented by James Shore, Bernard Kobos and Sebastian Golasch.
In ArangoDB, TDD is in action all day and I am looking forward to improving our front-end testing even further using these awesome tools.


Front-end Development meets NoSQL

Furthermore several talks focussing on front-end development have been given, e.g. by Gregor Martynus presenting Hoodie.js.
These front-end talks and my discussions with other attendees gave me the impression that front-end developers spend a lot of time deciding which database they should use.
However many databases focus on one special task and have been optimised for it. If the developers follow the vision of polyglot-persistence which is quite common in the NoSQL world, several different databases have to be installed in order to use the best tool for each job. However maintaining such a crowd of databases is quite an effort and it is much harder to decide which data should be persisted in which database.

In practice many front-end developers could benefit from a more general solution that supports several use-cases. People on the conference expressed their need for a more general NoSQL database, giving the benefits of document-stores, graph-databases and key-value stores, which can serve a broad range of use cases. Additionally, using just one database can make it easier for developers to wrap their head around as they only have to learn one technology.

That said, I am getting more and more convinced that we are going in the right direction with our developments of ArangoDB, which is more general and serves as a document-store as well as a graph-database while only having one interface and one query language for both.


Rapid API Development

Another interesting talk has been held about deployd – a web-based framework to create REST-APIs for MongoDB.

It is especially targeted for those applications where most of the program logic is in the front-end and the backend only has the task to persist data.
It offers many convenience functions to define access rights on REST-calls as well as on documents and even document attributes.
Furthermore it is shipped with an easy to use content management system.
The general idea of deployd reminded me of the FOXX-framework that has just been released for ArangoDB and I have been asked about the differences between FOXX and deployd.
For the curious ones I made a short list of main differences:

CollectionsBound to databaseBound to app
RoutesHTTP methods on collection namesUser defined routes
HostingCloud or own serverOwn server (cloud in progress)
App sharingNot built-inCentral repository