@Path("/quotes")
public class QuotesResource {
@Channel("quotes")
Multi<Quote> quotes;
@GET
@Produces(MediaType.SERVER_SENT_EVENTS)
public Multi<Quote> stream() {
return quotes;
}
}
Although this is simple, it feels a little too ceremonious and can likely be improved. @Path("/quotes")
public class QuotesResource {
@GET
@Produces(MediaType.SERVER_SENT_EVENTS)
public native Multi<Quote> stream();
}
@Path("/quotes")
public class QuotesResource {
@Produces(MediaType.SERVER_SENT_EVENT)
@Channel("quotes")
Multi<Quote> quotes
}
@Path("/quotes")
public abstract class QuotesResource {
@GET
@Produces(MediaType.SERVER_SENT_EVENTS)
@Channel("quotes")
public abstract Multi<Quote> stream();
}
Maybe we can have an API for this purpose
Note that the opposite can also be improved, it's usually written as@Path("/quotes") public class QuotesResource { @GET @Produces(MediaType.SERVER_SENT_EVENTS) public Multi<Quote> stream() { return Channel.of("quotes", Quote.class); } }
@Channel("quotes") Emitter<Quote> emitter;
@POST @Consumes(MediaType.APPLICATION_JSON) public void receive(Quote quote){
emitter.send(quote); }
--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-mQ7-e-d-vRXU%2BhmMOQWcLiZoD_%3DZJrfBdvi4Q2AjRBbg%40mail.gmail.com.
I would not use native as it have a strong meaning of platform dependent code (and usually C/C++), see its definition https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.3.4
On your example on native, you miss the @Channel annotation right ?
We can use an abstract method instead, but this would need the classes will be an abstract one, not sure it's a better design as develop would be a little surprised by it
@Path("/quotes") public abstract class QuotesResource { @GET @Produces(MediaType.SERVER_SENT_EVENTS) @Channel("quotes") public abstract Multi<Quote> stream(); }
Maybe we can have an API for this purpose@Path("/quotes") public class QuotesResource { @GET @Produces(MediaType.SERVER_SENT_EVENTS) public Multi<Quote> stream() { return Channel.of("quotes", Quote.class); } }
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-mdppQmjiY1qPsEuLs%2BYWkG5j%2BAZhZ6%2Bcb1HTcTaos3hw%40mail.gmail.com.
Can the QuotesResource class be an interface (similar to the CRUD endpoints) and then we auto-generate the boring boiling code?
Can the QuotesResource class be an interface (similar to the CRUD endpoints) and then we auto-generate the boring boiling code?
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-n5JsS%3DQdyOoPcd1gv-TY7M4CYtVTQHDyUvsPFwZFPJyg%40mail.gmail.com.
Hi folks,A few of us have been thinking about how to improve the integration of RESTEasy Reactive with Reactive Messaging.Currently when we a Channel needs to be streamed, our documentation proposes this:Although this is simple, it feels a little too ceremonious@Path("/quotes") public class QuotesResource { @Channel("quotes") Multi<Quote> quotes; @GET @Produces(MediaType.SERVER_SENT_EVENTS) public Multi<Quote> stream() { return quotes; } }
and can likely be improved.One thought is allowing something like this:@Path("/quotes") public class QuotesResource { @GET @Produces(MediaType.SERVER_SENT_EVENTS) public native Multi<Quote> stream(); }
Note the use of native here, which is the only modifier that allows us to not have to supply an implementation of the method without requiring the class to be abstract.Also note that the following solution would be nice but does not work:@Path("/quotes") public class QuotesResource {
@Produces(MediaType.SERVER_SENT_EVENT) @Channel("quotes") Multi<Quote> quotes
}The reason is that JAX-RS 's @Produces cannot be used on a field.What do you think of the proposed solution? Any other options that come to mind?
Dne út 13. 7. 2021 17:21 uživatel Georgios Andrianakis <gand...@redhat.com> napsal:Hi folks,A few of us have been thinking about how to improve the integration of RESTEasy Reactive with Reactive Messaging.Currently when we a Channel needs to be streamed, our documentation proposes this:Although this is simple, it feels a little too ceremonious@Path("/quotes") public class QuotesResource { @Channel("quotes") Multi<Quote> quotes; @GET @Produces(MediaType.SERVER_SENT_EVENTS) public Multi<Quote> stream() { return quotes; } }
Seriously?
I mean, this is simplicity distilled. In my eyes, removing from this would be actively adding complexity.Also the practical benefit is virtually zero, I'd say. The moment you need to do anything more, such as transform the data in some way, or send the client some initial data at the time of subscription, you need to go back to this.
Frankly, I'm not a fan of shortcuts that stop working when you need anything custom, and you have to go back to the non-shortcut way, and you have to _know_ there's a non-shortcut way. And here, it isn't even a shortcut, it's almost as long as the original.
On Wed, Jul 14, 2021 at 9:59 AM Ladislav Thon <lad...@gmail.com> wrote:Dne út 13. 7. 2021 17:21 uživatel Georgios Andrianakis <gand...@redhat.com> napsal:Hi folks,A few of us have been thinking about how to improve the integration of RESTEasy Reactive with Reactive Messaging.Currently when we a Channel needs to be streamed, our documentation proposes this:Although this is simple, it feels a little too ceremonious@Path("/quotes") public class QuotesResource { @Channel("quotes") Multi<Quote> quotes; @GET @Produces(MediaType.SERVER_SENT_EVENTS) public Multi<Quote> stream() { return quotes; } }
Seriously?Seriously.It's not like I enjoy writing emails. If I thought what I saw made perfect sense, I'd leave it at that
I mean, this is simplicity distilled. In my eyes, removing from this would be actively adding complexity.Also the practical benefit is virtually zero, I'd say. The moment you need to do anything more, such as transform the data in some way, or send the client some initial data at the time of subscription, you need to go back to this.Indeed, but Clement says that most processing will happen at the processor level anyway.
Dne st 14. 7. 2021 9:02 uživatel Georgios Andrianakis <gand...@redhat.com> napsal:On Wed, Jul 14, 2021 at 9:59 AM Ladislav Thon <lad...@gmail.com> wrote:Dne út 13. 7. 2021 17:21 uživatel Georgios Andrianakis <gand...@redhat.com> napsal:Hi folks,A few of us have been thinking about how to improve the integration of RESTEasy Reactive with Reactive Messaging.Currently when we a Channel needs to be streamed, our documentation proposes this:Although this is simple, it feels a little too ceremonious@Path("/quotes") public class QuotesResource { @Channel("quotes") Multi<Quote> quotes; @GET @Produces(MediaType.SERVER_SENT_EVENTS) public Multi<Quote> stream() { return quotes; } }
Seriously?Seriously.It's not like I enjoy writing emails. If I thought what I saw made perfect sense, I'd leave it at thatFair enough, though not everything we write has to be serious :-) The line between useless ceremony and expressing the essentials may be thin, but it's there.
I mean, this is simplicity distilled. In my eyes, removing from this would be actively adding complexity.Also the practical benefit is virtually zero, I'd say. The moment you need to do anything more, such as transform the data in some way, or send the client some initial data at the time of subscription, you need to go back to this.Indeed, but Clement says that most processing will happen at the processor level anyway.I'm thinking presentation-level transformations. It's been a while since I worked on something actually end-user-facing, but I still remember that system of record data and data presented to users or other systems are often almost-the-same-but-not-quite. It would surely be possible to do such transformations on an in-memory channel, but I'd personally do them in the JAX-RS resource method, it just makes more sense to me.Ah, one more thing. Don't we have an HTTP connector for Reactive Messaging in Quarkus? I think it allows both producing and consuming messages, though not sure how the consumption stuff works. Maybe for the super-simple cases, that would be easier?
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALbocOmJZgg5OdPBcoJLHw4PmMU3UtHO_MkTonOxSyUf_gevNg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKW6fidjkQK1izDyLVC2c464WixSNMvvYX-MrU1vhmDCMcWqyA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjTK_JY4vZo1WijkBW_CBsows-RaJN%3D%3DTQXafApi9qOZqA%40mail.gmail.com.
The quarkus-http connector (for reactive messaging) that was already mentioned can consume WebSockets and HTTP, and can feed a WebSocket or HTTP endpoint.It's rather basic but it can be extended to also expose SSE and WebSocket endpoints.That was the original plan but I never had time to do this.If we think it's worth it, I can get back to this.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-nfB%2BJx7fh94eFvH%2BaF9dhsQX8VUaoKGLBBLiEvE3O4Ug%40mail.gmail.com.
@Incoming("some-source-channel")
@Outgoing("my-http-sink")
SomeType passThroughWithCustomSerializer(SomeMaybeDifferentType foo) {
...
}
mp.messaging.outgoing.my-http-sink.connector=quarkus-http
mp.messaging.outgoing.my-http-sink.path=/my-http-sink
mp.messaging.outgoing.my-http-sink.method=POST
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjSrMv9TQLhFpJTgV6NDCNvqqeh8VB9aExm0iVdgT%2B1Ofg%40mail.gmail.com.
I think it would have to be something along the lines of:@Incoming("some-source-channel")
@Outgoing("my-http-sink")
SomeType passThroughWithCustomSerializer(SomeMaybeDifferentType foo) {
...
}mp.messaging.outgoing.my-http-sink.connector=quarkus-http
mp.messaging.outgoing.my-http-sink.path=/my-http-sink
mp.messaging.outgoing.my-http-sink.method=POST
@Path("/quotes")
public class QuotesResource {
@Channel("quotes")
Multi<Quote> quotes;
@GET
@Produces(MediaType.SERVER_SENT_EVENTS)
public Multi<Quote> stream() {
return quotes;
}
}
Even though I'd simplify it to:
@Path("/quotes")
public class QuotesResource {
@GET
@Produces(MediaType.SERVER_SENT_EVENTS)
public Multi<Quote> stream(
@Channel("quotes") Multi<Quote> quotes) {
return quotes;
}
}
@Path("/quotes")
public class QuotesResource {
@GET
@Produces(MediaType.SERVER_SENT_EVENTS)
@Channel("quotes")
Multi<Quote> quotes;
}
We have to acknowledge that this is probably an edge-case, and in most other cases we will want to do something to the channel data as we send it through, so perhaps this is a demo-feature that may not be actually useful, so methods will be required in most cases?--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9u1FBucdxotNh%3DpytgjNaBcQqz8ou-12NZW-ciWwHaXRQ%40mail.gmail.com.