thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Serhii Kanin (Jira)" <>
Subject [jira] [Commented] (THRIFT-5164) Go middleware support
Date Fri, 12 Jun 2020 17:44:00 GMT


Serhii Kanin commented on THRIFT-5164:

[~fishywang] thanks for the answer, so we are close to get a common understanding.
defer func() { resp := respGen() //how will you know the response type as it is different
for every service method?
the same question about request type.


You suggest to have a dedicated middleware for every service method or switch/case inside
a middleware?

What's the reason to have a list middleware which are not generic and require additional code
for every new method.

Our solution is much better, since it is generic, once you implement a loggerInterceptor you
can reuse it everywhere, the same as in GRPC solution I provided.

> Go middleware support
> ---------------------
>                 Key: THRIFT-5164
>                 URL:
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Go - Library
>            Reporter: Yuxuan Wang
>            Assignee: Duru Can Celasun
>            Priority: Major
>              Labels: Breaking-Change
>             Fix For: 0.14.0
>          Time Spent: 2h
>  Remaining Estimate: 0h
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen the discussion
to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our Baseplate.go
library, and we think that our implementation is generic enough that it might make sense to
contribute that into the thrift library. The related implementation are all in this file:
is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo (with renames,
of course). One implementation detail I'm not sure is that whether we want to expand the TProcessor
interface to also include ProcessorMap and AddToProcessorMap, or do we want to keep the two
iinterfaces separate.

This message was sent by Atlassian Jira

View raw message