How to design the various part of an API in node.js

We are designing an API that ideally should scale to all the world. Our idea is to have three different node.js App.

The first one is the public API app which is what we expose to the public and which would be deployed in the various zones of the world to reduce response time. This app would get the request from the user and forward the call to the middleware wich would be the second up. The middleware would get the call and then it would call the third app which would ba a storage abstraction layer which would then perform the requested read/write/update/delete operation and return the result to the middleware (the second app) which would then return the response to the public API.

Is it too complicated?Where should i put the business logic part?In the middleware (the second app)?If you think that there is a better approach i'm more than happy to change the design.

Design is driven by requirements and contraints so, it is difficult to say if that is correct or not. However, a chain of calls, has some problem IMHO:

  1. Cost. Every time you have to add a new operation or return a new piece of data you have to modify three places.
  2. Performance. A chain has to be slower than a single call.
  3. Deployment and versioning. Given one of the applications will be deployed in several servers around the world, the deployment and versioning could be a little challenging.

That´s my opinion.