[
https://issues.apache.org/jira/browse/THRIFT-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035952#comment-16035952
]
Devansh Gupta commented on THRIFT-4220:
---------------------------------------
This is a problem I've faced with Thrift and push back to using Thrift in 3
different companies I've worked at (and from my friends at AirBnb and Evernote)
I've used this before in all 3 of them and its made the developers life
extremely easy and made it easy to use Thrift as the _only_ medium of
communication _everywhere_ from our external APIs to Internal APIs to what we
put on our Messaging Systems (RabbitMQ, Kafka) etc. During development use the
simple json, easy to debug and iterate. In staging and production and in
automated tests use Compact or Binary.
This has been super useful which is why I thought it might be nice to
contribute back incase more people want to use (also improve upon it).
I've used Thrifts tiny Compact Protocol _even_ on Android and iOS because we
routinely deal with people:
1. On very slow & bad networks
2. With so many different versions of our Mobile Application, Thrift is godsend
to maintain backwards compatibility with clear API contracts.
However for other usage. From my article:
{quote}
So, one problem I have heard is, “Hey, so we are publishing our Thrift APIs to
third party vendors, and we need it to be easy to use.” Now, you either:
1. Expose the Thrift endpoints and coach your API consumers on Thrift and help
them debug any issues.
2. You maintain a library that is wrapper around the different Thrift services
for each language/platform you want to support.
3. Create a way to manually convert between human readable JSON to Thrift and
vice versa, and maintain it for every single struct, service & function.
If these options sound unappealing to you, you’re right — they can be a lot of
work. But is there another way?
{quote}
The TJSONProtocol you mention produces output like this
{code}
[
1,
"login",
1,
0,
{
"1": {
"str": "deva...@wi.co"
},
"2": {
"str":"<PASSWORD>"
}
}
]
{code}
For a _very simple_ call _login(email, password)_. Its very hard to get Third
Party users to use this. Or even for internal development for Simple Scripts.
But yes I agree its not as performant TJSONProtocol since we need parse JSON
upfront and we are using variable names and not keys.
However, I believe this adheres to the rest of the Thrift Goals of Simplicity
(I think its _far_ more simple) and _far more_ transparent (easier to read and
debug).
So the developer will have a choice - choose simplicity over some cost to
performance. In our case actually - we use both. In our simple internal scripts
like our Health APIs we choose simplicity since they are tiny Python scripts.
In our critical usage like from Mobile Apps we use Compact Protocol (in fact we
have made Compact even more compact since we use UUIDs and we send them down as
two longs-16 bytes- as opposed to 36 bytes of a string). For external 3rd party
users, who use the API infrequently its easier to teach them to call our
endpoints in a REST like manner using simple JSON than what Thrift offers today.
Since this is a Protocol we are not changing anything in the Thrift Code or
Thrift Generator itself. I initially thought we can modify the code base to be
able to Parse JSON (just create another scheme like the TupleScheme). But its
harder to get that adopted than simply a new kind of protocol.
Please let me know what you think [~jensg].
> Allow Service calls to be made using TSimpleJSONProtocol (using Simple JSON)
> ----------------------------------------------------------------------------
>
> Key: THRIFT-4220
> URL: https://issues.apache.org/jira/browse/THRIFT-4220
> Project: Thrift
> Issue Type: New Feature
> Components: Wish List
> Affects Versions: 1.0
> Reporter: Devansh Gupta
> Fix For: 1.0
>
>
> https://blog.parsable.com/using-human-readable-json-endpoints-with-thrift-for-free-774ba505c893
> https://github.com/degupta/human_readable_json_protocol
> If we publish our Services/APIs as Thrift today you can't make requests using
> simple Human Readable JSON. This means publishing our APIs to third party
> users means they have to
> 1. Know how to use Thrift
> 2. Have all the Thrift definition files or the generated code
> Or we have to build Libraries for each of the platforms we want to support.
> This is not always possible.
> I propose we do something like this:
> {code}
> exception SystemException {
> 1: i32 errorCode,
> 2: string message,
> }
> struct User {
> 1: string id,
> 2: string email,
> 3: string name,
> 4: i64 validatedAt
> }
> struct LoginResult {
> 1: string authToken,
> 2: User currentUser
> }
> service AuthenticationService {
> LoginResult login(1: string email, 2: string password) throws(1:
> SystemException err)
> }
> {code}
> Request Format:
> {code}
> {
> "method": "METHOD_NAME",
> "arguments": { ... }
> }
> {
> "method": "login",
> "arguments": {
> "email": "deva...@wi.co",
> "password": "password"
> }
> }
> {code}
> RESULT:
> {code}
> {
> "method": "login",
> "result": {
> "success": {
> "authToken": "some_auth_token",
> "currentUser": {
> "id": "6a6c982b-62f9-46d2-aff9-bd3a1cdf43f9",
> "email": "us...@wi.co",
> "name": "user1",
> "validatedAt": 0
> }
> }
> }
> }
> {code}
> This uses the JSON generated by the JSON Generator as "metadata" to figure
> out the Field Keys and Types.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
