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 talking about not Ignite auth, but external auth. Here I am considering
Ignite Service Grid as a microservice platform.
Authentication microservice can be not related to Ignite at all, but author
of service may want to retrieve or authenticate user by user_id, that is
provided in request headers or context in jwt token, for example.
The same is for tracing or metrics. Ignite internal mechanisms here cannot
help at all, because there is no context related to user's code.
If we want to leave Ignite Service Grid as dump as possible, it is ok. But
therefore it cannot compete with more functional variants.
But just adding request headers at first step and custom interceptors
(client and server side) we can give to user's of Ignite Service Grid a
lot of opportunities.
There is an example of golang grpc middlewares -- see how many interesting
use cases here:
https://github.com/grpc-ecosystem/go-grpc-middleware
вт, 12 окт. 2021 г. в 07:31, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:
> 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 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.
>
> Maybe you can pick one of the use cases that you think would benefit from
> this feature the most, and provide a little more detail? How would you like
> to see the use case to be addressed and what is currently missing?
>
> Also, just to be clear: I'm not necessarily against the suggestion, and
> it's highly unlikely that I will want to veto it if you or someone else
> will decide to implement it. Just expressing my concerns.
>
> -Val
>
> On Sun, Oct 10, 2021 at 11:52 PM Nikolay Izhikov
> wrote:
>
> > +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 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
> > >> wrote:
> > >>
> > >>> Ivan,
> > >>>
> > >>> Yes, this approach is used by some other sy
