Kotlin में GraphQL बनाम REST: 2025 में बैकएंड के लिए क्या चुनें

परिचय: REST मर गया, GraphQL जिंदाबाद? (स्पॉयलर: नहीं)

यदि आप Kotlin में कोड लिखते हैं और बैकएंड विकसित करते हैं, तो आपने निश्चित रूप से पवित्र युद्ध के बारे में सुना होगा: GraphQL बनाम REST। रिंग के एक कोने में पुराना अच्छा REST है, जिसे हर जूनियर जानता है। दूसरे कोने में फैशनेबल GraphQL है, जो वादा करता है "मुझे वह दो, जो मैं नहीं जानता, लेकिन सिर्फ एक क्वेरी में"।

मैं Kotlin पर अनुभव वाला एक बैकएंड डेवलपर हूं, और पिछले कुछ वर्षों में मैंने तीन प्रोजेक्ट्स को REST से GraphQL और वापस कन्वर्ट किया है। स्पॉयलर: प्रत्येक उपकरण अपने कार्य के लिए अच्छा है। इस लेख में हम कट्टर नहीं होंगे। इसके बजाय, हम वास्तविक कोड उदाहरणों के साथ देखेंगे कि Kotlin पर REST कब जीतता है, और कब GraphQL आपका उद्धारकर्ता है।

चलिए बिना बकवास और मार्केटिंग के Kotlin में GraphQL और REST की तुलना देखते हैं।

1. मुख्य बातें संक्षेप में: क्या है क्या

कोड में जाने से पहले, आइए शर्तों पर सहमत हों। REST API एक आर्किटेक्चरल शैली है, जहां प्रत्येक संसाधन (उपयोगकर्ता, ऑर्डर, उत्पाद) का अपना URL और HTTP विधियाँ (GET, POST, PUT, DELETE) होती हैं। Kotlin डेवलपर्स अक्सर REST सेवाएँ बनाने के लिए Spring Boot या Ktor का उपयोग करते हैं।

GraphQL एक क्वेरी भाषा है, जहां आपका एक एंडपॉइंट (आमतौर पर /graphql) होता है, और क्लाइंट स्वयं तय करता है कि उसे कौन से फ़ील्ड चाहिए। Kotlin पर लोकप्रिय लाइब्रेरीज़ KGraphQL (हल्की) और Spring for GraphQL (Spring प्रशंसकों के लिए) हैं।

मुख्य अंतर: REST का अर्थ है "सर्वर तय करता है कि क्या देना है"। GraphQL का अर्थ है "क्लाइंट केवल वही मांगता है जो उसे चाहिए"।

2. Kotlin (Ktor) पर REST API का उदाहरण

चलिए क्लासिक से शुरू करते हैं। मान लीजिए हमारे पास एक ऑनलाइन स्टोर है। हमें एक उपयोगकर्ता और उसके पिछले ऑर्डर का डेटा प्राप्त करना है।

यहां Ktor (Kotlin के लिए हल्का फ्रेमवर्क) पर एक विशिष्ट REST कंट्रोलर कैसा दिखता है:

// REST endpoint: GET /api/users/{id}\nfun Application.userModule() {\n    routing {\n        get("/api/users/{id}") {\n            val userId = call.parameters["id"]?.toIntOrNull() ?: return@get call.respondText("Bad Request", status = HttpStatusCode.BadRequest)\n            val user = userService.getUserById(userId) ?: return@get call.respondText("Not Found", status = HttpStatusCode.NotFound)\n            call.respond(user)\n        }\n    }\n}\n\n// प्रतिक्रिया के लिए Data class\n@Serializable\ndata class UserResponse(\n    val id: Int,\n    val name: String,\n    val email: String,\n    val lastOrders: List<Order>\n)

समस्या: यदि क्लाइंट (मोबाइल ऐप) को केवल उपयोगकर्ता का ईमेल चाहिए, तो सर्वर फिर भी ऑर्डर के साथ पूरा UserResponse ऑब्जेक्ट देगा। यह over-fetching है - डेटा का अत्यधिक स्थानांतरण। कमज़ोर मोबाइल नेटवर्क पर यह दर्दनाक है।

समाधान नंबर एक - कई छोटे एंडपॉइंट बनाना: GET /api/users/{id}/email। लेकिन तब अनुरोधों की संख्या बढ़ जाती है (under-fetching)।

3. Kotlin (Spring for GraphQL) पर GraphQL का उदाहरण

अब वही परिदृश्य, लेकिन GraphQL के साथ। यहाँ स्कीमा (schema.graphqls) है:

type Query {\n    user(id: ID!): User\n}\n\ntype User {\n    id: ID!\n    name: String\n    email: String\n    lastOrders: [Order]\n}\n\ntype Order {\n    id: ID!\n    total: Float\n    date: String\n}

और यह Spring for GraphQL (एनोटेशन दृष्टिकोण) का उपयोग करते हुए Kotlin कोड है:

@Controller\nclass UserController(private val userService: UserService) {\n\n    @QueryMapping\n    fun user(@Argument id: Int): User {\n        return userService.getUserById(id) ?: throw UserNotFoundException("User not found")\n    }\n}\n\n// बिना अनावश्यक फ़ील्ड के Data class\ndata class User(val id: Int, val name: String, val email: String, val lastOrders: List<Order>)

अब क्लाइंट केवल वही मांग सकता है जो उसे चाहिए:

query {\n    user(id: 42) {\n        email\n    }\n}