Pavel,
> I would say it is linear, not geometric.
Without service context, there were 2 serviceProxy methods. The patch with
service contexts adds two more methods. Each next parameter according to
this pattern will add the same amount of methods as there were before.
> I suggest introducing
Pavel,
> Can you clarify please, is it going to be a new interface, let's say
> IgniteServicesSomething, and "IgniteServices extends IgniteServicesSomething"?
Yes, that's what I meant (if we go this way).
пн, 20 дек. 2021 г. в 15:32, Pavel Tupitsyn :
>
> Alex,
>
> > the count of methods will
Alex,
> the count of methods will increase in geometric progression
I would say it is linear, not geometric.
Anyway, a common fix for "too many parameters" issue is Parameter Object
pattern [1],
I suggest introducing "ServiceProxyConfiguration" class.
> We already using such an approach in
Pavel,
As for option (1): the count of methods will increase in geometric
progression with each new parameter. For example, if we decide to add
tracing to services, we should keep current methods as-is for backward
compatibility and add new methods supporting a tracing parameter.
> Also, we
Pavel,
My vote is for option (1). Simple and clear.
As you noted, with (2) it is not clear which methods are affected.
Also, we don't provide methods like withTimeout, withSticky, so adding
withContext will introduce another inconsistency.
(3) seems to be too complicated.
On Thu, Dec 16, 2021
Hi folks!
The discussed feature is currently under development and recently
there was a proposal for an API improvement, which I want to discuss.
It is about how the user can specify a service call context when
getting a proxy.
I see the following options:
1. Passing the context as an argument
> 1. Add init/execute/cancel methods without parameters.
> 2. Add default no-op implementations for the new methods (this is required
> to preserve compatibility).
> 3. For old methods that take ServiceContext as a parameter, add default
> implementations that delegate to new methods.
> 4.
> and it fully switches to annotation-based injection.
+1 to do it.
> 19 окт. 2021 г., в 22:14, Valentin Kulichenko
> написал(а):
>
> That's actually a good point. In Java, we can do the following:
> 1. Add init/execute/cancel methods without parameters.
> 2. Add default no-op implementations
That's actually a good point. In Java, we can do the following:
1. Add init/execute/cancel methods without parameters.
2. Add default no-op implementations for the new methods (this is required
to preserve compatibility).
3. For old methods that take ServiceContext as a parameter, add default
> Removing parameters from a public interface method is a breaking change,
> or do you mean something else?
Sorry, I meant that we can inject the service context, but leave it
available in the init/execute/cancel methods and add a default "no-op"
implementation in the interface for them. Can we
Pavel,
> From my point of view, this should not break anything
Removing parameters from a public interface method is a breaking change,
or do you mean something else?
Regarding .NET - let's have a separate ticket for that?
We can discuss and implement Java changes first.
On Tue, Oct 19, 2021 at
Thanks a lot for your suggestions.
> We might consider injecting the ServiceContext instead of passing it to
> IgniteService methods, but I believe this will be a breaking change?
>From my point of view, this should not break anything. We can inject a
service context when initializing a service
I support #2, because we already have the ServiceContext. Having
both ServiceContext and @ServiceRequestContextResource that injects some
function (or any other mechanism for that matter) will be VERY confusing.
Let's keep it simple.
At the same time, I do agree with Nikolay that injection is the
I am for limiting types of attributes values only to UTF-8 strings and
bytearrays.
Also, I agree with Pavel, (2) is clear and without any reflection.
вт, 19 окт. 2021 г. в 14:18, Nikolay Izhikov :
> I like (1) options.
>
>@ServiceRequestContextResource
>private Function ctxFunc;
>
>
I like (1) options.
@ServiceRequestContextResource
private Function ctxFunc;
Because, we use this style of API for injection of other resources - logger,
ignite instance, etc.
It may be confusing for the user to use several API styles for solving similar
tasks.
> 19 окт. 2021 г., в
(2) seems to be the cleanest and most discoverable to me,
also simpler to implement (no reflection necessary).
But existing ServiceContext properties are for the entire instance, not for
the current call.
So, to make it clear and obvious, let's do
Folks,
I agree with Ivan that we can improve the user experience in Ignite
services by adding support for "middleware".
And as a first step, we need to pass the "caller context" to the service.
I see the following API options for reading this "context" inside a service:
(please see "API
Hi, Val
>>The examples you mentioned are more related to internal activities (e.g.,
>> if authentication is handled by an Ignite server node, it can create its
>> internal context for a connection - this is certainly reasonable). I'm
only
>> worried about exposing this to the end user.
I'm
Ivan,
I'm a bit confused :) Unless I misread the initial suggestion, the idea is
to provide a public API to create the context. In other words, it will be
up to the end user to create this context properly, which affects the
business code - and that's exactly where I see an issue.
The examples
+1 to have service proxy context.
> 11 окт. 2021 г., в 09:43, Ivan Daschinsky написал(а):
>
> Val, Pavel both of you are right, but on the other hand there are some
> other tasks
>
> 1. Distributed tracing.
> 2. Custom metrics/measurements
> 3. Auth and some related tasks (i.e. ingests full
Val, Pavel both of you are right, but on the other hand there are some
other tasks
1. Distributed tracing.
2. Custom metrics/measurements
3. Auth and some related tasks (i.e. ingests full User info by calling some
auth service in middleware).
Do you both think that this is a good idea in
I agree with Pavel. The suggested approach is indeed utilized quite
frequently, but it's inherently error-prone.
The main issue is that it creates implicit assumptions about the behavior
of both the service and the user's code. For example, if the user's code
must provide a username, what if it
Ivan,
Yes, this approach is used by some other systems, and still, I don't like
it very much.
Let's hear more opinions.
On Sat, Oct 9, 2021 at 9:00 PM Ivan Daschinsky wrote:
> Hi.
> Pavel T., Ok, http rest dosn't have the clean design, in your opinion.
>
> But what about grpc? The same?
>
> As
Hi.
Pavel T., Ok, http rest dosn't have the clean design, in your opinion.
But what about grpc? The same?
As for me, it is ok to pass additional parameters as list of key-value
pairs with keys as strings and values as bytearrays or strings. It is ok to
allow user to set up middlewares for
Pavel,
Thanks for the explanation, I understand the use cases.
> in REST service, he can set such parameters in request headers
I don't consider HTTP-based services as a good example of a
clean architecture.
Data can be passed in URL parameters, in headers, and in body, and each of
those ways
Igor, Pavel.
> Why can not a user implement such context on application level? I believe
> Ignite provides all necessary tools for that.
The user wants to trace the source of the service call. For example, a
service must log the name of the user who made the calls of the
service. For now,
Agree with Igor.
I'm not sure this feature is a good fit for Ignite.
Ignite should not be responsible for such a high-level concept, this should
be on the application side instead.
- As Eduard noted, it is hard to make this type-safe
- Ambient state is not obvious and the API looks confusing
Hi guys,
Why can not a user implement such context on application level?
I believe Ignite provides all necessary tools for that. User can just
implement such a context as user type and pass it to services they
need. Are the arguments why would Ignite need a separate feature
for such a use case?
I am not aware .NET capabilities, but as I can see service must be
implemented in *java* and even if can't serialize other that Map on .NET
side, on java side we can wrap this map with provided TypedContext (context
should be convertible from map in this case).
That leads to a situation when Java
Hi, Eduard!
Thanks for your feedback.
The idea sounds very good, but don't forget about the platform services.
For example, we may call Java service from .Net and vice-versa. I'm
not sure if the context can be implemented as a custom class (instead
of Map/Dictionary) in this case.
пт, 8 окт.
Hi, Pavel
Is it possible to provide type-safe API for ServiceProxyContext ?
I think constructions like int arg1 = ctx.attribute("arg1"); are error
prone.
Can we make something like this :
//Signature with two generic params which allow the compiler to check
if the service will be called with
Hello Igniters!
I want to implement a feature to support a custom "caller" context in
ignite services (see example in ticket description [1]).
Sometimes, when using Ignite services, it becomes necessary to pass
custom parameters from the "request source" to the service. This is
most commonly
32 matches
Mail list logo
