Skip to content
This repository has been archived by the owner on Jun 18, 2021. It is now read-only.

Server side Architecture

Jump to bottom
Mikael Couzic edited this page Sep 11, 2013 · 3 revisions

As a whole, the application is organized following a Three-tier architecture :

  • Data tier Neo4j Graph Database hosted on Heroku

  • Logic tier Node.js application hosted on appfog

  • Presentation tier AngularJS single-page application executed in the browser

Communication between Logic and Data layers

Neo4j provides a RESTful API and allows our Logic layer to manipulate the data. Many requests are written using the Cypher language, which a graph-oriented SQL-like language specific to Neo4j. Only our Logic layer is allowed to communicate with the Data layer.

Communication between Presentation and Logic layers

The Logic layer in turn provides a REST API with the services required by the Presentation layer. The goal of this page is to describe how those web services are implemented and organized.

Service Endpoints

The endpoints are implemented using a stack of third-party modules, including :

  • express : HTTP requests handling
  • express-resource : Automatic binding of CRUD-like functions
  • passport : Authentication

In the project, the service endpoints are declared in app.js.

The implementations can be found in the controllers folder. The most important controllers are :

  • resources
  • connections
  • users

####WARNING !!! For historical reasons, obsolete controllers are still present in the source code. During a massive redesign, most controllers were re-written, however there are still some chunks of logic that need to be moved. In a near future, our goal is to completely get rid of the following controllers :

  • concepts (replaced by resources)
  • edges (replaced by connections)
  • knownodes (should be cut down in smaller chunks)

In a controller's folder, you will find two files :

  • index.js

    Defines the functions that will actually be made available to the world. Completely delegates to the other file

  • (Name)Controller._coffee

    Streamlined CoffeeScript implementations. Those components are responsible for getting all the data from the HTTP requests and delegating to DAO or model components.

Controllers and DAOs already implement basic CRUD functions. If you want to make those functions available to the world, all you have to do is define them in the index.js files.

Model

In the model folder, you will find the CoffeeScript classes that represent the business entities.

All model classes extend the NodeWrapper class, which is a

Clone this wiki locally