Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Future and other asynchronous execution modes #18

Closed
kdavisk6 opened this issue May 16, 2019 · 0 comments · Fixed by #41
Closed

Support Future and other asynchronous execution modes #18

kdavisk6 opened this issue May 16, 2019 · 0 comments · Fixed by #41
Assignees
Labels
enhancement New feature or request

Comments

@kdavisk6
Copy link
Member

One of the shortcomings of Feign is that support asynchronous execution modes is limited to those using Hystrix and their Observable support. Others have looked into supporting this, but have come the same conclusion, adding support for async modes requires a reconsideration of how Feign manages request execution.

Given that this project is "green-field", I would like to propose that we consider supporting, at a minimum, Future and CompletableFuture return types in the core library.

Methods that specify these return types should be executed on an executor pool, either of the user's choosing or a reasonable default one, with their results returned directly, ideally after decoding the response. Here is an example:

public interface Blog {
   @Request(value = "/posts", method = HttpMethod.GET)
   CompletableFuture<Posts> getPosts();
}

public class BlogPostRepository {
   private BlogService blog;

  public Collection<Post> getPosts() {
     CompleteableFuture<Collection<Post> posts = this.blog.getPosts()
         .thenAccept(posts -> posts.stream().collect(Collectors.toList());
     return posts.get();
  }
}

This, in my mind, would be an ideal place to start.

@kdavisk6 kdavisk6 added the enhancement New feature or request label May 16, 2019
@kdavisk6 kdavisk6 changed the title Support Future and other asynchronous execution modes Support Future and other asynchronous execution modes May 16, 2019
@kdavisk6 kdavisk6 self-assigned this May 17, 2019
@kdavisk6 kdavisk6 added this to To do in 1.0.0.RELEASE via automation May 17, 2019
@kdavisk6 kdavisk6 moved this from To do to In progress in 1.0.0.RELEASE May 17, 2019
kdavisk6 added a commit that referenced this issue May 17, 2019
Fixes #18

Adding a new TargetMethodHandler that wraps the Future being executed
on the Executor in a CompleteableFuture.  This method handler will be
used when the target interface defines a method that returns either a
Future or CompleteableFuture.

Decoding of Future objects is not as straight forward as it is with
regular types, since the Future is a container for a result.  The
TypeDefinitions have been updated to identify when one of these
'container' types are desired and will decode the contained type instead.

Additional Changes include:
* Adding Test Cases
kdavisk6 added a commit that referenced this issue May 17, 2019
Fixes #18

Adding a new TargetMethodHandler that wraps the Future being executed
on the Executor in a CompleteableFuture.  This method handler will be
used when the target interface defines a method that returns either a
Future or CompleteableFuture.

Decoding of Future objects is not as straight forward as it is with
regular types, since the Future is a container for a result.  The
TypeDefinitions have been updated to identify when one of these
'container' types are desired and will decode the contained type instead.

Additional Changes include:
* Adding Test Cases
1.0.0.RELEASE automation moved this from In progress to Done May 17, 2019
kdavisk6 added a commit that referenced this issue May 17, 2019
* Adding AsyncTargetMethodHandler

Fixes #18

Adding a new TargetMethodHandler that wraps the Future being executed
on the Executor in a CompleteableFuture.  This method handler will be
used when the target interface defines a method that returns either a
Future or CompleteableFuture.

Decoding of Future objects is not as straight forward as it is with
regular types, since the Future is a container for a result.  The
TypeDefinitions have been updated to identify when one of these
'container' types are desired and will decode the contained type instead.

Additional Changes include:
* Adding Test Cases

* Removed Check for Container and Collection in Parameterized Types

This check is not necessary as all parameterized types will be a
container or collection.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
1.0.0.RELEASE
  
Done
Development

Successfully merging a pull request may close this issue.

1 participant