-
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.
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.).