As we mentioned in our portfolio we want to be flexible on how we solve occuring business problems which implies using the right tool for the right job, but when we start from zero for a new project, we have some nice pieces of technology, that do a great job and we love to work with.
In general we approach development challenges with a 3-tier architecture that starts with a flexible Presentation Layer.
I – Presentation Layer
Our favored software stack is web technologiy based. Thus relies on an open software stack, that is cross-platform-compatible and has advanced really fast in the recent years. Web APIs come closer to fulfill the requirements we have for new app projects. We develop stateful webapps that run in modern browsers (so called Single Page Apps) and compile well for the big mobile platforms iOS, Android, Windows Phone and Firefox OS. We make heavy use of famous javascript libs and tools such as webpack, backbone.js, mocha for testing and our own event driven service bus to allow for a loose coupling of our modularized architecture when running. This approach will be covered in more detail in an own blog post in the not so far future. But for now lets stick to the general architecture and therefore decend into the second tier – the service layer.
II – Service Layer
Typical tasks are the aggregation of different data sources, controlling user sessions and authentication. It provides the REST-based data APIs for all the different frontend clients. Because of the strong differences of the possible clientes the service layer has no information about layout, design or any other frontend-specific assets.
node.js (io.js), hapi.js and its ecosystem provide everything you need for these tasks. Amazing performance, very good scaling on concurrency as well as modularization. By that this setup focusses on reusability and is a perfect match if you do look for a flexible and highly adaptable backend runtime.
It also is responsible to validate and prepare data for the next tier, the data model layer.
III – Data Model Layer
If there are no specific requirements for the data model layer we really love the approach of ArangoDB There are three main advantages that drove our decision:
Document-Orientation
Scheme-free document-oriented collections allow for looser data set structures with nested objects and the database takes care of the optimization for itself. This allows us to model the data more object-related which is a better fit for modern web backends and eliminates the need for complex orm frameworks.
Graph-Orientation
We believe that graph-based modelling of relationships feels more natural and is more flexible since the entities remain untouched in the database and the relationships have their collections with own optimization for the links between the entities. This is comparable to m:n join table in relational databases. But since the graph approach is a more general one, graph-oriented databases offer convenient functions to traverse a graph – no matter how deep the relationships are.
Data-Driven API via FOXX
Foxx is built on top of the database and features a nice api running in the amazingly fast V8 Javascript engine. We really like the approach how we can interact with collections as repositories with models. You can work completely object-oriented and it seems strongly inspired by backbone.js’s way to work with data. Since we also use backbone.js as our main frontend lib, we love this approach and we love even more that Foxx uses the Joi validation framework for validating any data structure. By that we can create validation objects which run seamlessly in the frontend, backend and database without modification.
This is not all ArangoDB has to offer. You should take a look for yourself on the other well-thought features.
Conclusion
We are using a full-stack javascript approach and all its outlined advantages. Datahandling between these 3 layers is as easy as calling JSON.stringify. With our strong approach for structuring and dependency management we can easily decouple components and reuse them in several projects. A good versioning system let’s us keep control on which components act well together and gives us a good overview of what our projects actually consist.
In the next posts we will go into more detail on the structure of each tier and its requirements. If you have questions or ideas just let us know.