Different data models?

[jackmaney]

First of all, let me say that I love what has been done with Poet. Before I bumped into it, I did some brainstorming on what I'd want from a relatively simple blog engine that I could attach to my homepage (the back-end of which is run in node), and Poet is almost a superset of the features I want. I'm in the process of tinkering with Poet and adding it to my website.

While using the local file system for posts is nice for its simplicity, it can be a bit of a pain for apps using Poet that are a) kept on GitHub, and b) deployed elsewhere (eg Heroku), since the deployment cycle is essentially

create blog post -> commit to GitHub -> deploy to Heroku (or wherever)

and that's a rather annoying process. If posts can instead be added to a database/No SQL key-value store/etc, then no such deployment is necessary.

I propose adding different data models to Poet, allowing the storage of posts in databases, as follows:

• Other than the default (and currently existing) model, all other models (eg, poet-model-mongo, poet-model-mysql, etc) should be their own node modules.
• There would be a model specification in options which would default to the current choice of using the app's local file system.
• In the options, there is an optional object with a key of modelOptions that includes, eg, access credentials, the host name of the database to connect to, etc.
• The model would provide helpers such as getPost, getPosts, getPostsWithTag, etc. This would mean that createHelpers would just call the relevant data helper methods from the given data model.

Would this kind of thing be welcome?

[nilgradisnik]

+1 I love the idea. I've been thinking about doing this myself.
Especially if you're running multiple instances it would make sense to have the blog data in one place(database).

[jsantell]

The goal of poet is to remain simple -- hence the parsing a directory for posts without needing a database. Although, if having a database makes it simple, then it's something to explore. Although, I'd like to keep the posts stored in memory, as if the posts were fetched from the DB on call, it would require a much different infrastructure than what's in place currently. To fetch posts initially from a database, and then at that point, everything else is the same as with directory posts, then that could be doable.

👍 on it being a separate module in the above scenario -- will look into what would need to be changed to allow this extensibility. Currently, the ./lib/methods.js/#init function is called which is coupled with populating from a directory, but that could be pulled out to allow different modules providing a way to add posts.

Is that what you had in mind? A DB way to populate posts, and from that point forward, business as usual?

[jackmaney]

Yes, that's exactly what I had in mind: abstracting the data model to a separate module that fills the in-memory cache with posts, and then carry on as usual. We could have a model value (defaulting to the data model that grabs posts from the local file system) passed into the options object. The model module itself would abstract the API for getPosts, getTags, etc. The helpers can then call on this API for filling the cache, and then the rest of Poet would work as normal.

The first proof of concept would be to abstract away the current, default data model into its own module (which may as well be kept included in the repo).

Also, the existing options that are really only useful for the current data model (ie posts and metaFormat) can be passed on to options in the model object.

[ChrisMcKenzie]

What if we used something like https://github.com/balderdashy/waterline which already has a "dirty" RAM backing along with many other drivers.

[jsantell]

waterline could be a great module to use for this.. will look into that, and into decoupling poet so the 'load posts' is separated from everything else

[ChrisMcKenzie]

I would really like to help with this. Any thoughts as to how we might want to decouple the "Load posts" implementation?

[mfrobben]

I have a start on an implementation with mongodb at https://github.com/mfrobben/poet-mongo. It's rough and hacked in, but you get the idea. Also have a working admin panel hacked onto that at https://github.com/mfrobben/poet-mongo-admin. Agree with @jackmaney there should be better abstractions than (options.useDb ? foo() : bar()), but you get the point.

:)

[ChrisMcKenzie]

I like your implementation @mfrobben very clean and well documented! this would definitely make a good starting point! 👍