Roadmap to RESTHeart v4.0

[mkjsix]

We are planning a new major release of RESTHeart in Q1 2019.

https://restheart.org/learn/roadmap/

We are gathering ideas, please comment the roadmap here and let us know what you think.

Is there something that should / shouldn't be in the roadmap?

[lenalebt]

Hi together, one quick question regarding the representation format: Does the new format mean that the old formats will be unavailable? Asking since that would mean we'd need to migrate older services to the new formats. If the old formats are still available, do you plan to keep them available for some time?

Cheers, Lena

[ujibang]

Hi Lena,

Good news. As usual the representation format can be selected using the rep qparam and the default format to use can also be set in the configuration file.

All the usual formats will still be available.

[christiangroth]

Hi,

another question concerns the metrics, specifically in prometheus format. The metrics can be queried per database and collection. However, this is possible only with different endpoints, e.g. / _metrics, / db / _metrics, etc. For the use of prometheus, however, it makes much more sense to have all metrics under one endpoint and to realize the distribution of the metrics by database and collection with Prometheus labels.

We would like to offer a pull request so we can discuss about technical details, but we are just asking for the timeline. Could this feature still be in the next release? Of course, this is potentially a breaking change as the structure of the metrics is being changed.

Christian

[mkjsix]

@christiangroth do you think it would be feasible to add the new structure instead of altering the existing one? In terms of timings, we still don't have a final deadline, so It's not an issue right now.

[christiangroth]

@mkjsix I just started to implement the first things and it's possible to not change anything regarding the JSON metrics format, so this won't break at all. I want to change the prometheus format as little as possible and I already have an idea how to achieve this. Hopefully I can come up with a pull request within the next week, so we have something to discuss about.

[christiangroth]

There it is, love to get your feedback! https://github.com/SoftInstigate/restheart/pull/340

[mkjsix]

@christiangroth release 3.9 is out https://github.com/SoftInstigate/restheart/releases/tag/3.9.0 https://cloud.docker.com/u/softinstigate/repository/docker/softinstigate/restheart/tags

[ml27299]

Hi, so I'm the CTO of Liaison ventures Inc, we just started using restheart (not even in production mode yet) but I can tell you what we will be using restheart for.

We are taking apart our monolithic application and started going more serverless using lambda functions. We intend to have a lot of parallel lambda executions, we cant connect to the mongodb directly because it will create too many connections. The plan is to have a cluster managed by kubernetes that runs restheart containers, then the lambda functions will just make http calls to it.

One issue (not really an issue with restheart itself, just a nice to have) was that I use nodejs on my lambda functions and wanted a nicer way to do things with restheart that was more readable. I use mongoose on my monolithic application and really liked the way it allowed me to execute queries, I couldnt find any existing solutions on the npm registry, so I built a mongoose like restheart client (its not on the npm registry yet, but it will within the next month).

It allows queries to be executed like so

const { client } = await RestheartClient({ token: someAuthToken, database: "somedatabase" })
const User = client.model("user") //user is a collection in the db

await User.find({ type : 1 }).select("field1 field2")
await User.findOne({ _id : somobjectid_or_objectidstring })
await User.create(array_or_object)
await User.update({ _id: somobjectid_or_objectidstring }, { field1: changed_value }) // $set and other update methods work too

it also makes adding/deleting schemas, checkers, transformers easier with methods like .createSchema .createSchemaModifier .deleteSchema etc.

It can do created_at/updated_at injections so that the developer doesnt have to explicitly set them, and it converts the response to a readable javascript object (i.e no "$oid", "$date", etc). I did see that restheart already comes with ways of getting rid of $oid on responses by using a transformer, so there's an option to shut this off in my restheart npm client

Anyway, I think the more clients there are for different languages that implement restheart the more adoptability it can have. Dont get me wrong, your rest api is great to use via http calls, but a lot of ppl dont like having to deal with request retries, handling the error codes, debugging, etc.

[mkjsix]

Thank you @ml27299 We have some very similar use cases: we moved to AWS Lambda for stateless services, with RESTHeart + MongoDB for the central stateful part. We use ECS + ALB instead, but in case of Kubernetes you might find useful the section about Metrics On Requests as other developers uses that for automatic scaling and health-checks when running in K8s.

I think your suggestion about more client SDKs is very interesting and we'll put it in the roadmap. We aim to make it easier for developers to use the tool.

[mkjsix]

Released: https://github.com/SoftInstigate/restheart/releases/tag/4.0.0