+1 to have service proxy context.
> 11 окт. 2021 г., в 09:43, Ivan Daschinsky <ivanda...@gmail.com> написал(а):
>
> 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 business code?
>
> Without this functionality, our service grid cannot compete with grpc and
> others as microservice framework, unfortunately.
>
> But if we introduce limited support for this "request headers", it can
> drastically improves this aspects of our service grid framework.
>
>
> пн, 11 окт. 2021 г. в 00:48, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
>> 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 doesn't? I assume it will get an error,
>> which is very counterintuitive. Even more importantly, how should one learn
>> about this requirement in the first place? It is not reflected in the API
>> in any way - and that's a big problem.
>>
>> The fact that the service implementor needs to update the API methods when
>> such requirements are introduced is actually a good thing, in my opinion.
>> This forces the developer to stop and think about how the updated API
>> should look like and how to make sure it's backward-compatible (or not, in
>> case the new requirements are mandatory). Doing this through an external
>> context is basically the equivalent of saying "let the end user deal with
>> this". Not a good practice, in my view.
>>
>> Conversely, passing everything exclusively via method arguments guarantees
>> that:
>>
>> - The user's code is always compliant with the service contract. You
>> can't "forget" to pass something to the service.
>> - Any changes in the service contract (backward-compatible or otherwise)
>> are explicitly reflected in the API.
>>
>>
>> -Val
>>
>>
>> On Sun, Oct 10, 2021 at 6:21 AM Pavel Tupitsyn <ptupit...@apache.org>
>> wrote:
>>
>>> 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 <ivanda...@gmail.com>
>>> wrote:
>>>
>>>> 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 services and allow to enrich
>> request
>>>> context in this middlewares. It is very common approach everywhere and
>> is
>>>> very useful in distributed systems. The use cases are so obvious,
>> aren't
>>>> they?
>>>>
>>>>
>>>>
>>>> сб, 9 окт. 2021 г., 20:14 Pavel Tupitsyn <ptupit...@apache.org>:
>>>>
>>>>> 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 has its own limitations.
>>>>> There is no obvious correct way to do things.
>>>>>
>>>>>>> Ambient state is not obvious and the API looks confusing even
>>> though I
>>>>> understand our services stack quite well both in Java and .NET
>>>>>> Can you clarify please?
>>>>>
>>>>> The proposed API adds a "side channel" for the data.
>>>>> Some is passed as arguments, which is obvious, and some becomes
>>> magically
>>>>> available on the server side through some external context.
>>>>> - You have to know about the context
>>>>> - You have to understand that the context is only available during
>> the
>>>>> method call (can't use it in some background logic)
>>>>>
>>>>> In my opinion, this is a bit too clever. I'm a fan of the functional
>>>>> programming approach where everything you need is passed as
>> arguments.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 8, 2021 at 4:29 PM Pavel Pereslegin <xxt...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> 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, there's no possibility to do that without
>> modifying
>>>>>> the service interface and implementation. Moreover, the user must
>>>>>> modify all methods of service to pass this parameter. For example,
>> in
>>>>>> REST service, he can set such parameters in request headers, why we
>>>>>> can't provide such usability in Ignite.
>>>>>>
>>>>>>> This will reduce the performance of all calls
>>>>>> This feature is optional, if the context is not passed - then
>> there's
>>>>>> shouldn't be any performance difference.
>>>>>>
>>>>>>> Ambient state is not obvious and the API looks confusing even
>>> though
>>>> I
>>>>>> understand our services stack quite well both in Java and .NET
>>>>>> Can you clarify please?
>>>>>>
>>>>>> пт, 8 окт. 2021 г. в 15:46, Pavel Tupitsyn <ptupit...@apache.org>:
>>>>>>>
>>>>>>> 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 even
>>>> though
>>>>> I
>>>>>>> understand our services stack quite well both in Java and .NET
>>>>>>> - This will reduce the performance of all calls
>>>>>>>
>>>>>>> On Fri, Oct 8, 2021 at 3:44 PM Igor Sapego <isap...@apache.org>
>>>> wrote:
>>>>>>>
>>>>>>>> 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?
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Igor
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Oct 8, 2021 at 2:17 PM Eduard Rakhmankulov <
>>>>>> erixon...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> 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 can use TypedContext but
>>>> other
>>>>>>>> clients
>>>>>>>>> can't. I believe that the majority of services users are
>> using
>>>> Java
>>>>>> and
>>>>>>>> it
>>>>>>>>> should be taken in accordance.
>>>>>>>>>
>>>>>>>>> P.S. I think it is possible to send plain objects from .NET
>>>> context
>>>>>> to
>>>>>>>>> cluster.
>>>>>>>>>
>>>>>>>>> Best regards, Ed
>>>>>>>>>
>>>>>>>>> On Fri, 8 Oct 2021 at 14:40, Pavel Pereslegin <
>>> xxt...@gmail.com>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> 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 окт. 2021 г. в 14:21, Eduard Rakhmankulov <
>>>>>> erixon...@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>> 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 the wrong type
>> context.
>>>>>>>>>>>
>>>>>>>>>>> public <T extends ContextedWith<CtxType>, CtxType> T
>>>>>>>>>>> serviceProxyTyped(ClusterGroup prj, String name, Class<?
>>>> super
>>>>> T
>>>>>>>
>>>>>>>>>>> srvcCls, CtxType optCtx, boolean sticky, long timeout)
>>>>>>>>>>>
>>>>>>>>>>> //new interface which services with scoped context should
>>>>>> implement
>>>>>>>>>>>
>>>>>>>>>>> public interface ContextedWith<T> {
>>>>>>>>>>> T getCtx();
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> // implementation can delegate to Map-like context or be
>>>> POJO.
>>>>>>>>>>> interface MyServiceContext {
>>>>>>>>>>> int getArg1();
>>>>>>>>>>> String getUserId();
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> class MyService implements
>> ContextedWith<MyServiceContext>
>>> {
>>>>>>>>>>> void doThings() {
>>>>>>>>>>> MyServiceContext ctx = getCtx();
>>>>>>>>>>>
>>>>>>>>>>> System.out.println("ctx.getArg1() = " + ctx.getArg1());
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> @Override public MyServiceContext getCtx() {
>>>>>>>>>>> return ServiceProxyContext.current();
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> WDYT?
>>>>>>>>>>>
>>>>>>>>>>> Best regards, Ed.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, 8 Oct 2021 at 13:26, Pavel Pereslegin <
>>>>> xxt...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> 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 used to track the origin of a service
>> call
>>>>> (user
>>>>>> id,
>>>>>>>>>>>> request id, session id eg see this user question [2]).
>>>>>>>>>>>> At the moment, the only way to pass such parameters to
>> a
>>>>>> service is
>>>>>>>>> by
>>>>>>>>>>>> adding argument(s) to all called methods of the
>> service,
>>>>> which
>>>>>>>> makes
>>>>>>>>>>>> the code messy and also complicates development and
>>>>>> maintenance.
>>>>>>>>>>>>
>>>>>>>>>>>> I propose letting the user set a custom context for the
>>>>> service
>>>>>>>> proxy
>>>>>>>>>>>> and implicitly pass that context to the methods being
>>>> called.
>>>>>> This
>>>>>>>>>>>> function should not affect the execution of service
>>> methods
>>>>> in
>>>>>> any
>>>>>>>>> way
>>>>>>>>>>>> unless the user has specified a context.
>>>>>>>>>>>>
>>>>>>>>>>>> An example of using the proposed API [1].
>>>>>>>>>>>> PoC (except thin clients) [3].
>>>>>>>>>>>>
>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>
>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-15572
>>>>>>>>>>>> [2]
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> https://stackoverflow.com/questions/57459071/apache-ignite-service-grid-service-call-context
>>>>>>>>>>>> [3] https://github.com/apache/ignite/pull/9440
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
