Roadmap link

[jettdigital]

Hi there, l'm in love with restheart! Can a roadmap be made and linked to off the readme and regular site? It would be useful to see where the project is headed and what contributions would align with the overall goals for the project. Again, great work!

[mkjsix]

Thank you! Actually, we are talking about this right now, as we are aware we need to improve the governance process, so we are selecting and putting in place the necessary tools. We are open to listen to any suggestion on this regard.

Meanwhile we're working on a set of new features based on the feedback so far, some are already in the latest SNAPSHOT but will be released with the next 0.9.8 final, the most notable are:

• GridFS support (see #7 ) -> development in progress
• Eager cursor preallocation for paging through large result sets (see #1 ) -> implemented, now in QA
• Bulk transactional operations (see #6 ) -> to be fully specified yet, it might be part of 0.9.9.

We'd love to hear from you any suggestion in terms of priorities from your side, please feel free to open specific issues so that we can start the discussion and share a roadmap. Of course, our resources are limited, so we are not able to commit into any deadline or even into a specific feature if it's not of very common interest.

We are also in a phase were we are trying to understand how people is actually planning to use this tool, so any hint about this would help us in shaping a better roadmap.

[mkjsix]

We are now experimenting with GitHub milestones as a integrated way to handle the roadmap: https://github.com/SoftInstigate/RESTHeart/milestones At the moment it's still very rough, but we hope to improve it quickly, assigning 'enhancement' and 'bug' labelled issues to the appropriate milestone.

[jettdigital]

I use restheart because I can concentrate on writing my application ( AngularJS hybrid mobile and traditional web app in my case ) without having to get stuck in the tedium of writing an object storage API.

If writing custom authentication/authorization falls out nicely and I can use the application-logic-mounts feature to do some request data validation then I'll probably put restheart in production. Otherwise, I'll use restheart to help me get to MVP status and then replace it with my usual Spring Boot API stack (which always takes a long time to develop).

For me, a top priority would be putting the custom authentication/authorization a little more out front. Maybe a couple examples like a JDBC impl or even OAuth2 integration, API security is always on everyone's mind. I think HAL documentation/examples should be a priority as well, the more APIs fully embracing HAL the better off we'll all be.

Suggestions:

1. A Discourse forum on your site would be a great addition. A place for you to make announcements and ground zero for community based support
2. I know it's restheart but Undertow supports websockets. A websocket api to mongodb would be cool

[mkjsix]

Thank you a lot for your comments, they provide us with extremely important information.

One thing we are aware of: we need to add more documentation, examples, etc. Unfortunately most of our efforts are absorbed by core development (besides, this project is not our full-time occupation). If you are blogging or want to contribute anything on this side, it'd be very welcome, even if in draft form.

Your further two suggestions are both interesting and we took note, in the following days we'll come out with some additional ideas and a plan, plus a viable roadmap to share. The overall idea is exactly to produce a nearly zero development backend for RESTful applications, so I think that a Websocket API would be pretty nice to have, even if there are some technical challenges that need to be elaborated further. But it sounds fun anyway :)

Recently we have been actively talking about a callback mechanism, so that, for example, one could "fire and forget a message" to Restheart and later receive an asynchronous response via a URI in the originating request. More or less a lot like a JMS conversation, but on top of HTTP and RESTful.

[jettdigital]

I'll certainly contribute as I make my through this project I'm working on. One thing I was thinking about was using the Nashorn javascript interpreter in Java 8 to setup a validation system modeled after your application logic handlers. The point being you could write validation functions (usually just a set of regexps) in Javascript instead of Java. The validation functions would be run against an incoming POST/PUT/DELETE and be able to take advantage of JSON to Javascript object deserialization without having to go through the pain of deserializing JSON to a strongly typed language like java. It would be a quick way to do server side enforcement of required document fields for example.

I also want to explore setting up restheart as an OAuth2 protected resource. We'll see though, I'm only working on this project at night and weekends.

On Wed, Jan 14, 2015 at 12:17 PM, Maurizio Turatti <notifications@github.com

wrote:

Reopened #11 https://github.com/SoftInstigate/restheart/issues/11.

— Reply to this email directly or view it on GitHub https://github.com/SoftInstigate/restheart/issues/11#event-218921314.

[ujibang]

Adding support for Nashorn is a brilliant idea! This would allow developers store javascript application logic in mongodb and bind the execution to specific URIs.

For your information, we are going to implement for release 0.9.9 what we call stored queries, i.e. we'll allow to define aggregation and map reduce queries and store them as collection properties.

The "developer" is allowed to define the queries as collection properties via the API (it is a PATCH to the collection) and the "users" are only allowed to invoke the queries.

For example, the following store query makes available the /db/coll/_queries/avgage resource

{
 rels: {...},
 queries: [
  { 
    uri: 'avgage',
    type: 'mapReduce',
    map: 'function() { emit(this.age)',
    reduce: 'function(key, values)
    { return Array.avg(values)}' 
   }
]
...
}

Following your idea, we'll be able not only to define data API but also custom application logic API with a similar approach...

[jettdigital]

Man I didn't even think about storing the javascript in mongodb itself but it makes sense ( I'm new to mongodb ). I'm wondering about the dev workflow, I guess you would edit/unit test your javascript app logic like normal then when you're ready to put it in restheart you would have a script to post it all in and start processing actual requests.

This kind of reminds me of like a cross between NodeJS middleware and a traditional Java app server. I suppose you could think of it as restheart middleware and model it after Node's architecture. Or, if you want to stay in the Java frame of mind model it after Servlet filters ( the interceptor pattern ) which may be an easier conceptual fit. From what I've seen of the restheart source your expertise likely lies with Java.

On Thu, Jan 15, 2015 at 3:42 AM, Andrea Di Cesare notifications@github.com wrote:

Adding support for Nashorn is a brilliant idea! This would allow developers store javascript application logic in mongodb and bind the execution to specific URIs.

For your information, we are going to implement for release 0.9.9 what we call stored queries, i.e. we'll allow to define aggregation and map reduce queries and store them as collection properties.

The "developer" is allowed to define the queries as collection properties via the API (it is a PATCH to the collection) and the "users" are only allowed to invoke the queries.

For example, the following store query makes available the /db/coll/_queries/avgage resource

{ rels: {...}, queries: [ { uri: 'avgage', type: 'mapReduce', map: 'function() { emit(this.age)', reduce: 'function(key, values) { return Array.avg(values)}' } ] ... }

Following your idea, we'll be able not only to define data API but also custom application logic API with a similar approach...

— Reply to this email directly or view it on GitHub https://github.com/SoftInstigate/restheart/issues/11#issuecomment-70061297 .

[mazzarito]

We are currently experimenting using RESTHeart on an ecommerce site to provide our applications access to our large MongoDB product database, which includes quite a few records. We often have to do things like query 300+ records and get an average price, so doing some business logic with Nashorn would be really cool for things like that.

[mkjsix]

Matt, thanks for your feedback, we are sorting out and prioritize all the requests. Unfortunately we are still working on this in our spare time, so we can't commit on a deadline yet, but definitely we're heading on this direction.

[ujibang]

roadmap is now available at https://softinstigate.atlassian.net/issues/?filter=10403