-
Notifications
You must be signed in to change notification settings - Fork 2
Design notes
The intention behind this page is to document my thought process as the design of the framework evolves over time. This is not meant to be organized, nor is it meant to be formal documentation. It's just meant to be a running record of what I was thinking as each change is decided. The point is to avoid a situation where someone does something that seems like a good idea at the time, and during future maintenance, it looks horrible, but nobody wants to touch it because they have no idea what it was intended to achieve.
There are very good arguments for having a consistent ORM designed for the framework. When I originally envisioned Turnpike, I had a very specific ORM with a business-readable DSL for defining a schema. As I've started building a few different projects on top of this framework, I'm starting to find that other packages on NPM do a good enough job. Namely, I'm looking at Mongoose, and Knex. Mostly I find myself writing thin wrappers around these, and I'm starting to think it might make more sense to have a lightweight generator that can stub out these wrappers and make no assumptions about the underlying storage implementation at all. Should I go this route, then Turnpike's "model" segment would basically consist of only these wrappers, and out of the box, there'd be no support for persistent storage at all, moreover, basic CRUD functions would need to be implemented from scratch on every model. On the other hand, application developers would not find themselves in a position where it feels overly clunky when trying to connect to a database engine I didn't consider during development (Think Couch, Cassandra, Riak, etc.).
The biggest difference between Turnpike and most other MVC frameworks seems to be in how the models are assumed to be structured. In Turnpike, "model" refers to a singleton object representing the whole of your data storage. Turnpike models expose an Item constructor. Items are the objects that represent whatever bundles of data your model store and retrieves.