Distributing Nuxeo content accross the globe through angular apps ?


In my company, we'll use Nuxeo next year for DAM/DMS purposes. We have ~60 subsidiaries accross the world and thus we'll need to replicate our central storage to local one (or reginal one).

Thinking about it, I could indeed deploy Nuxeo Box around the world or deploy some smart reverse proxy but I was thinking about something lighter and nicer :

  • Building a AngularJS based app, using the Nuxeo AngularJS directives. This would be deployed on local sites. App would be in charge to provide a basic “client” for the central storage. Content will be browsed by requesting the API centrally.
  • For authentication and permissions checkings, AngularJS app would connect to central server to validate user & rights
  • If user is granted access to a given content, he can download it. Thus, file is fetched either from central repository or from local server if synchronised

We could also assume the whole CRUD actions are made through the angular app + API + Asynchronous sync for assets.

Is the angularJS/Nuxeo + Rest API mature enough to manage this use cases, starting from a 5.8 basis or not yet ?

Thanks, Nicolas

0 votes

1 answers



I do the exact same thing using GWT + REST API for multiple applications, so I know the Nuxeo/API side is capable enough. I

Hi Bruce,

Thanks for your feedback and confirming my idea is not that crazy as it could seems ;-)

How far are your GWT apps remote (ie up to several thousands km far from your Nuxeo repository with from low to good connections) ?


Hi Nicolas,

Data centre is in the US midwest and people accessing content across Canada and the US, so yes, thousands of KMs. API design, minimizing data traffic, and caching (where practical) all come into play to make the SPA approach workable.


Hi Bruce,

Thanks for the precisions and the confirmation.



Developing an Angular app that browses the content repository is quite straightforward.

But what is exactly you problem ? From what I understand, your fear is about the network latency. Using a Single page application should help about that since, the templates for instance would be downloaded only once. After that, the only call will be about retrieving data that is much better than retrieving a full html page.

Beside that, when you talk about synchronisation, it implies some inconsistencies at some time : file present on a server but not replicated on another one. So my question is much about : are you sure the network is a real bottleneck for you app ? And if so, perhaps just a caching proxy on you local sites may suits your needs.

1 votes

Hello Damien,

I have two points to consider :

  • CRUD capacity + authentication + permission throught the API ; this part looks OK for what I had in mind and what you just confirmed
  • The long distance part ; for which the single page app seems a good alternative to provide a nice ui for end users and a local entry point to Nuxeo. As you said, using the API will consume less bandwith than full HTML pages.

I could indeed expect/deploy only a caching proxy, which either has all nuxeo content in cache via some sync mechanism, or have a "progressive" cache based on user consumption (first user get the file from central and put it in the cache ; 2nd and beyond will get it from the cache). But in this case, it make people go to the central place for the UI and fetch from central or local cache (if files is already there).

I was more thinking about Cache (full or on demand) + Angular Apps to have a "full" remote and local servers with both UI & content and communicating centrally only though the API. Of course there are some sync issues to manage.

It's more a on going thought for my coming projects (does it make sense to build such an app / it is feasible ? or is a just a dream to become a nightmare ?) ; use cases needs to be precised later.

Regarding network side, some of our subsidiaries have small internect connection and the VPN to the group is on the same link. So for the smallest / farrest one, yes, it is an issue for which we need at least caching.