Core architecture for a Node app

[Andrew Eddie]

So I'm trying to wrap my head around how to structure a set of basic Node modules to deal with the basic CRUD mechanics (because after that is solved, most other things should just fall into place). The problem with most Node "ORM's" is that they exist inside the boundary interface and couple your app tightly to the way Mongoose, Waterline et al want to do things. 

Here's a rough first guess for the interfaces:

https://gist.github.com/eddieajau/0b0d5d264eecced8a9fb

With them are the use-cases I think the interfaces must have, plus a few questions about what they might also be able to do.

For my own purposes, I need a set of patterns that would be able to support my specific requirement:

* I have quite a few types of entities

* Some entities are related to others, and that could be a formal parent-child[ren] type of relationship

* Some entities could have variations (for example, a shirt with a range of sizes and colours)

* Entities should be able to handle some complex objects like dates as a native JavaScript object

* I want to be able to swap out my persistence layer in the future if I need to (for example, migrate from MySQL to Mongo, or visa versa if the need to case arises).

* I need to be able to use encrypted storages (for things like system passwords) so I can imagine composing a storage with something akin to an input filter (to encrypt a password for example) and an output filter (to decrypt)

Obviously there are a number of other requirements but that's the basics and it's more or less what every Node app developer has to deal with on a daily basis.

In summary I have three parts:

An Entity

- knows about it's properties, and perhaps it's relationships with other entities (which might be collections?).

- exists inside the boundary interface

A Collection - Probably a service or model used by an Interactor

- knows about CRUD-ing Entities

- will have a Storage interface but is agnostic to what the storage layer is

- implementation exist inside the boundary interface

- perhaps is the point of truth for Entity schema?

A Storage - I think this is akin to Uncle Bob's "Entity Gateway"

- knows how to CRUD data from a storage medium (memory, flat file, RDBMS, et al)

- concrete implementations are likely tightly coupled to a traditional ORM-like module like Mongoose, or Waterline

- implementations would exist outside the boundary interface

Am I on the right track?

Thanks in advance (and please don't reply on the gist - I wish Github would fix gist comment notifications!).

Regards,

Andrew Eddie