Deprecating DynamoDB and datastore.js support


#1

tldr: We’ll be removing DynamoDB/datastore.js support in a couple of weeks. If you have a project that uses it, you should update your app to use an alternative persistence service. If you need help with this, let us know.

A couple of great alternative options for a database are
mlab, heroku postgres, or redis-cloud.

You can either reply to this post or send us a feedback mail for support from within HyperDev.

If you have no idea what I’m talking about, and/or you’re not using DynamoDB/datastore.js, you can safely ignore this.

What?

In a couple of weeks, we’ll be moving HyperDev projects to a new backend container infrastructure that’ll be faster, more reliable, and unblock on us on delivering hot new features like a properly writeable filesystem, multi-language support and version control.

To do this, we’ll need to remove project DynamoDB support. Over the next couple weeks we’ll be working to update existing projects to use an alternative persistence service (see tldr above).

Why?

First of all, if this change breaks your app we’re really sorry. It’s not a choice we made lightly, and we’ll do everything we can to help make this less terrible.

So with all the cool advantages mentioned above that the new infrastructure brings, moving to a simpler container model also means we’ll lose the association of each project to a DynamoDB instance that datastore.js relied upon.

But that’s merely a technical reason that gives us a convenient break point. The inconvenient truth is that the feature has serious problems:

  1. Community support for DynamoDB isn’t great. There aren’t many usable drivers on Node or on other platforms we plan to support. There’s also no convenient/non-hacky way to view your records.
  2. Getting help on a DynamoDB issue on Stack Overflow is nowhere near as easy as something with broad use like MySQL, Postgres or Mongo. The situation is even worse for issues with our custom datastore.js driver.
  3. It’s proprietary/not portable. It’s a point of pride and principle for us that there’s nothing magical about the code in a HyperDev project - you can download it or export it and things will mostly just work. This isn’t the case with the DynamoDB part of your project.

This doesn’t mean we don’t want HyperDev to have an out-of-the-box DB experience though. We totally do! It’d be awesome to not have to research/sign-up/setup a separate service before saving data.

We want to do persistence right. In a way that’s community-oriented, based on an open standard, flexible and easy to use.

Please excuse the mess in the meantime.


Issue in select-bot example using sequelize findOne()