परिचय: REST मर गया? नहीं, बस एक विकल्प आ गया है
\n\nहर Java डेवलपर ने कम से कम एक बार REST API लिखा है। यह सुविधाजनक, परिचित है, और JSON को आँखों से पढ़ा जा सकता है। लेकिन जब लोड बढ़ता है और विलंबता महत्वपूर्ण हो जाती है, तो REST चरमराने लगता है। और तब मंच पर आता है gRPC — Google की तकनीक, जो स्थानीय कॉल जितनी गति, JSON से 10 गुना अधिक सीरियलाइज़ेशन गति और अंतर्निहित स्ट्रीमिंग समर्थन का वादा करती है।
\n\nइस लेख में हम समझेंगे कि जावा में gRPC वास्तव में कब उचित है और कब REST पर बने रहना बेहतर है। कोई फालतू बात नहीं — केवल वास्तविक परिदृश्य, कोड उदाहरण और ईमानदार बेंचमार्क।
\n\ngRPC क्या है और इसके बारे में क्यों बात हो रही है?
\n\ngRPC रिमोट प्रोसीजर कॉल (RPC) के लिए एक फ्रेमवर्क है। JSON के बजाय यह Protocol Buffers (protobuf) का उपयोग करता है — एक बाइनरी सीरियलाइज़ेशन फॉर्मेट। HTTP/1.1 के बजाय — HTTP/2 मल्टीप्लेक्सिंग और हेडर कंप्रेशन के साथ।
\n\nJava के लिए इसका मतलब है:
\n- \n
.protoफ़ाइलों के माध्यम से सख्त टाइपिंग कॉन्ट्रैक्ट \n - क्लाइंट और सर्वर का स्वचालित जनरेशन \n
- चार प्रकार की इंटरैक्शन: unary, server streaming, client streaming, bidirectional streaming \n
- टाइमआउट, डेडलाइन और लोड बैलेंसिंग के लिए अंतर्निहित समर्थन \n
एक सामान्य .proto फ़ाइल कैसी दिखती है?
\n\nsyntax = "proto3";\n\npackage com.pythonlib.example;\n\nservice UserService {\n rpc GetUser (UserRequest) returns (UserResponse);\n rpc ListUsers (UserListRequest) returns (stream UserResponse);\n rpc UpdateUser (stream UserUpdateRequest) returns (UserResponse);\n rpc Chat (stream ChatMessage) returns (stream ChatMessage);\n}\n\nmessage UserRequest {\n int32 id = 1;\n}\n\nmessage UserResponse {\n int32 id = 1;\n string name = 2;\n string email = 3;\n}\n\nmessage UserListRequest {\n int32 page = 1;\n int32 size = 2;\n}\n\nmessage UserUpdateRequest {\n int32 id = 1;\n string name = 2;\n}\n\nmessage ChatMessage {\n string user = 1;\n string text = 2;\n}\n\n\nprotoc के माध्यम से संकलन के बाद आपको बिल्डरों के साथ एक तैयार Java क्लास मिलेगा — कोई मैन्युअल मैपर नहीं।
जावा में gRPC कब सबसे अच्छा विकल्प है? 5 परिदृश्य
\n\n1. उच्च लोड वाले माइक्रोसर्विसेज
\n\nयदि आपके पास 50+ माइक्रोसर्विसेज हैं जो एक-दूसरे से प्रति सेकंड हजारों बार संवाद करते हैं, तो gRPC REST की तुलना में विलंबता को 30-50% कम करता है। Protobuf कम जगह लेता है, HTTP/2 सभी अनुरोधों के लिए एक कनेक्शन बनाए रखने की अनुमति देता है।
\n\nव्यवहार से उदाहरण: हमने एक आंतरिक अनुशंसा सेवा को REST से gRPC में स्थानांतरित किया। प्रतिक्रिया समय 12 ms से घटकर 4 ms हो गया, और ट्रैफ़िक 3 गुना कम हो गया।
\n\n2. रीयल-टाइम डेटा स्ट्रीमिंग
\n\ngRPC बॉक्स से बाहर server-side streaming, client-side streaming और bidirectional streaming का समर्थन करता है। यह इसके लिए आदर्श है:
\n- \n
- लॉग और मेट्रिक्स (एजेंट डेटा की धारा भेजता है) \n
- चैट सिस्टम और सूचनाएँ \n
- बड़ी फ़ाइलों को टुकड़ों में प्रोसेस करना \n
Java पर server streaming के साथ सर्वर का कार्यान्वयन:
\n\nimport io.grpc.stub.StreamObserver;\n\npublic class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {\n\n @Override\n public void listUsers(UserListRequest request,\n StreamObserver<UserResponse> responseObserver) {\n for (int i = 0; i < 10; i++) {\n UserResponse user = UserResponse.newBuilder()\n .setId(i)\n .setName("User_" + i)\n .setEmail("user" + i + "@pythonlib.ru")\n .build();\n responseObserver.onNext(user);\n try {\n Thread.sleep(200); // विलंबता का अनुकरण\n } catch (InterruptedException e) {\n responseObserver.onError(e);\n }\n }\