Support async programming

[remmeier]

The topic has come up a number of times. Feel free to place your ideas here. The Java 9 Flow API and Completable futures would be two ideas. When designing async repository interfaces, one has to keep in mind that we not only deliver a stream of resources, but also meta and links information.

[corrspt]

I haven't migrated from Katharsis (2.8) to Crnk yet, but being on the Play Framework this is something that I would like to have available when I find the time to upgrade to Crnk.

Play uses CompletetableFuture as part of its async nature, I don't think Flow (from Java9) is supported in Play, something to have in mind while designing this functionality.

I don't have much experience with Async programming though. Just wanted to express the situation on the Play Framework.

Thanks for all the work in Crnk.

[remmeier]

if you are on Katharsis 2.8 and still make use of QueryParams, you may want to move first to Katharsis 3.0 and/or QuerySpec. After that the Crnk upgrade should be fairly easy. Altough there should also not be much in the way of directly moving to Crnk. It gained some robustness and simplicity over the last year.

I'm also leaning towards something like CompletetableFuture or related rather flows/Observables due to the nature of JSONAPI with meta data and links and the lack of streaming. An intermediate step towards async support is maybe to make the IncludeLookupSetter multi-threaded, so that multiple threads can process a single request (perform inclusions in parallel). That is something both sync and async repositories would benefit from.

The one thing I would not do is to promote async over sync programming. I think the later is still simpler/more robust if the last bit of performance is not the most crucial element.

[corrspt]

Thanks @remmeier for replying. Yes, I have lots of things depending on QueryParams as such migration is kind of pain :) but I'll have to find out the time for that.

IncludeLookupSetter multi-threaded seems a great step. I have some Entities which are huge (surprise!) and probably being able to load inclusions in other threads would be a benefit.

I agree that promoting async of sync is probably not what we want with a library such as crnk (but having the option for those extra performance points would be interesting).

In any case, I just wanted to share my opinion on the subject so that the issue is not "forgotten". I don't think it should be a priority either, but also not forgotten.

Thanks for all the work in Crnk. I've been following the repository (just not using it yet).

[remmeier]

initial set of interfaces based on https://projectreactor.io/ are available. Feedback welcomed. There are various smaller changes over the existing non-reactive interfaces:

• ResourceField instead of String usage for field names
• Split of relationship repository into a single-valued and a multi-valued one
• ID must not implement Serializable
• list of ids are collections intead of iterables
• find methods in relationship repositories directly provide the bulk contract instead of having a dedicated bulk relationship repository.

The filter specific interfaces are still in early work in progress and will change.

Potentially the same changes will be done at some point with the regular non-reactive interfaces (ResourceRepositoryV3, etc.).

[weaselmetal]

I understand that an RP-style server Request handling is planned for crnk, comparable to this https://spring.io/blog/2016/07/28/reactive-programming-with-spring-5-0-m1

Question: are there any client JS frameworks that are compatible with RP-style request handling?

[remmeier]

i make use of angular/rxjs/ngrx/ngrx-json-api, just like in the main crnk-example

[remmeier]

first iteration is now available on the master branch with a new project crnk-reactive and module ReactiveModule. In crnk-documentation there is a new chapter about it (not yet online). Everything based on https://projectreactor.io/. All the basics are in place. Next step would be to setup the integration (crnk-integration-vertx and crnk-integration-ratpack). Similarly new example application can be setup in crnk-examples. Any contributions welcomed. Once those in place, we could look at some advanced topics (e.g. JDBC/JPA causes a bit of issues since it does not support async porgramming).

[remmeier]

https://github.com/crnk-project/crnk-framework/blob/master/crnk-documentation/src/docs/asciidoc/reactive.adoc

[weaselmetal]

I'm not really experienced with all the reactive stuff, but I thought you may find this interesting @remmeier https://www.thoughts-on-java.org/get-query-results-stream-hibernate-5/ as a hibernate stream allows to iterate (scroll) through the result set.

[remmeier]

reactors goes quite a few steps beyond the Java stream api. It has further operators like map and merge. And schedulers can parallelize the workflow. But not for JDBC/JPA has it is single-threaded and non-async. Potentially it could be integrated by allowing Crnk to parallize GET requests but keep POST/PATCH/DELETE single-threaded. The former could then make use of multiple transactions while the later all operations run within a single transaction.

[remmeier]

implemented in the meantime

[weaselmetal]

@remmeier sorry to comment on this closed issue, but I couldn't find any information in the docs if concurrent retrieval of include is also implemented via this commit. And if so, can it be used without adopting the reactive programming pattern? Thanks.

[remmeier]

no, not implemented so far or maybe rather no example so far. what would need to be done is switch to the reactive implementation and use of the workers to access the tradition sync repository. so slight setup change with the benefit of concurrent inclusion. that is done. but some more work would be needed. for example the jpa transaction handling must be done at another place closer to the repository.