GraphQL — API-র জন্য একটি কোয়েরি ভাষা এবং সেই কোয়েরিগুলি সম্পাদনের জন্য একটি রানটাইম, যা Facebook 2012 সালে তৈরি করেছে এবং 2015 সালে ওপেন-সোর্স করেছে। REST-এর বিপরীতে, যেখানে সার্ভার প্রতিক্রিয়ার কাঠামো নির্ধারণ করে, GraphQL ক্লায়েন্টকে নির্দিষ্ট করে বলতে দেয় তার কী ডেটা প্রয়োজন, যা overfetching এবং underfetching-এর সমস্যা সম্পূর্ণরূপে দূর করে। State of JavaScript Survey (2025) অনুযায়ী, 35% জরিপকৃত ডেভেলপার GraphQL ব্যবহার করেন, এবং বড় কোম্পানিগুলির মধ্যে GitHub, Shopify, Airbnb এবং The New York Times এটি গ্রহণ করেছে। GraphQL তিন ধরণের অপারেশন সমর্থন করে: query (পড়া), mutation (লেখা) এবং subscription (WebSocket-এর মাধ্যমে রিয়েল-টাইম আপডেট)।
মুখ্য বিষয়
GraphQL — API-র জন্য একটি স্পেসিফিকেশন এবং রানটাইম যা ক্লায়েন্টকে প্রাপ্ত ডেটার উপর সম্পূর্ণ নিয়ন্ত্রণ দেয়। Facebook ইঞ্জিনিয়ারদের দ্বারা News Feed মোবাইল অ্যাপ্লিকেশনের সমস্যা সমাধানের জন্য তৈরি, স্পেসিফিকেশনটি 2015 সালে একটি ওপেন স্ট্যান্ডার্ড হিসাবে প্রকাশিত হয়েছিল। 2018 সাল থেকে, GraphQL GraphQL Foundation-এর অধীনে Linux Foundation এবং Apollo, AWS, GitHub, SAP এবং অন্যান্য কোম্পানিগুলির সমর্থনে পরিচালিত হচ্ছে।
REST-এর বিপরীতে, যেখানে প্রতিটি endpoint একটি নির্দিষ্ট ডেটা কাঠামো ফেরত দেয়, GraphQL একটি একক endpoint ব্যবহার করে যা একটি কোয়েরি স্ট্রিং গ্রহণ করে। ক্লায়েন্ট কোয়েরিতে বর্ণনা করে তার কী কী ফিল্ড প্রয়োজন, এবং সার্ভার ঠিক সেগুলি ফেরত দেয়। উদাহরণস্বরূপ, কোয়েরি { user(id: "1") { name email } } শুধুমাত্র ব্যবহারকারীর নাম এবং ইমেল ফেরত দেবে, address, phone বা createdAt-এর মতো অতিরিক্ত ফিল্ড ছাড়া যা REST-এ পেতে হত।
GraphQL কোনো নির্দিষ্ট ডাটাবেস বা ভাষার সাথে আবদ্ধ নয়। স্পেসিফিকেশন শুধুমাত্র কোয়েরি এবং প্রতিক্রিয়ার বিন্যাস নির্ধারণ করে। Node.js (graphql-js, Apollo Server), Kotlin (graphql-kotlin, Netflix DGS Framework), Python (Graphene, Strawberry), Ruby (graphql-ruby) এবং অন্যান্য ভাষায় সার্ভার বাস্তবায়ন বিদ্যমান। ক্লায়েন্ট লাইব্রেরি সমস্ত প্রধান প্ল্যাটফর্মের জন্য উপলব্ধ, যার মধ্যে iOS, Android এবং ওয়েবের জন্য Apollo Client অন্তর্ভুক্ত।
GraphQL আর্কিটেকচার তিনটি মূল উপাদান নিয়ে গঠিত: স্কিমা (Schema), রিজলভার (Resolvers) এবং GraphQL ইঞ্জিন (GraphQL Engine)। স্কিমা নির্ধারণ করে কী কী ডেটা টাইপ উপলব্ধ, কী কী কোয়েরি কার্যকর করা যেতে পারে এবং সেগুলি কী কী আর্গুমেন্ট গ্রহণ করে। রিজলভার হল সার্ভার-সাইড ফাংশন যা প্রতিটি স্কিমা ফিল্ডের জন্য ডেটা ফেরত দেয়। ইঞ্জিন আগত কোয়েরি গ্রহণ করে, স্কিমার বিরুদ্ধে এটি বৈধ কিনা যাচাই করে, উপযুক্ত রিজলভার কল করে এবং প্রতিক্রিয়া সংগ্রহ করে।
কোয়েরি প্রক্রিয়াকরণের ধারা এইরকম:
GraphQL আর্কিটেকচারের মূল সুবিধা হল ফিল্ড-স্তরের রেজোলিউশন। REST-এ, ডেভেলপার একটি রিসোর্সের সমস্ত ফিল্ড পায় (সম্ভবত অতিরিক্ত সহ) বা ?fields=name,email-এর মতো এক্সটেনশন ব্যবহার করে। GraphQL-এ, এই ধরনের ফিল্টারিং ভাষাতেই নির্মিত: প্রতিটি কোয়েরি স্পষ্টভাবে নির্দিষ্ট করে কী কী ফিল্ড প্রয়োজন, এবং সার্ভার ঠিক সেগুলি ফেরত দেয়। এটি মোবাইল অ্যাপ্লিকেশনের জন্য বিশেষভাবে গুরুত্বপূর্ণ, যেখানে স্থানান্তরিত ডেটার পরিমাণ সরাসরি লোডিং গতি এবং ডেটা ব্যবহারকে প্রভাবিত করে।
GraphQL তিন ধরণের অপারেশন নির্ধারণ করে, প্রতিটি একটি নির্দিষ্ট মিথস্ক্রিয়া পরিস্থিতির সাথে সম্পর্কিত। Query — ডেটা পড়ার জন্য, REST-এ GET-এর অনুরূপ। Mutation — ডেটা পরিবর্তনের জন্য (তৈরি, আপডেট, মুছে ফেলা), POST/PUT/DELETE-এর অনুরূপ। Subscription — WebSocket-এর মাধ্যমে রিয়েল-টাইম আপডেটের জন্য, যার ক্লাসিক REST-এ কোনো সরাসরি সাদৃশ্য নেই (WebSocket বা Server-Sent Events-এর মতো অতিরিক্ত সমাধান প্রয়োজন)।
মৌলিক কোয়েরি সিনট্যাক্স স্বজ্ঞাত:
// আর্গুমেন্টসহ সরল কোয়েরি
query {
user(id: "42") {
name
email
avatarUrl
}
}
// মিউটেশন যা পরিবর্তিত ডেটা ফেরত দেয়
mutation {
updateProfile(name: "ইভান") {
id
name
updatedAt
}
}
// Subscription — রিয়েল-টাইম আপডেট শোনে
subscription {
newMessage(chatId: "chat_1") {
id
text
sender { name }
}
}
Query সমান্তরালভাবে কার্যকর হয় — একই স্তরের সমস্ত ফিল্ড একসাথে লোড হয়। এটি একক অনুরোধে একাধিক round-trip ছাড়াই সম্পর্কিত ডেটা (ব্যবহারকারী এবং তার পোস্ট) লোড করার অনুমতি দেয়। Mutation ক্রমিকভাবে কার্যকর হয় — একটি অনুরোধে মিউটেশনগুলি ঘোষণার ক্রমে একের পর এক কার্যকর হয়। Subscription WebSocket-এর মাধ্যমে একটি স্থায়ী সংযোগ স্থাপন করে, যার মাধ্যমে সার্ভার কোনো ঘটনা ঘটলে ডেটা পাঠায়।
অপারেশনগুলি ডেটাকে কোয়েরি থেকে আলাদা করতে ভেরিয়েবল, শর্তসাপেক্ষে ফিল্ড অন্তর্ভুক্ত করতে ডিরেক্টিভ (@include, @skip) এবং ফিল্ড সেট পুনরায় ব্যবহার করতে ফ্র্যাগমেন্ট গ্রহণ করতে পারে। এই ক্ষমতাগুলি GraphQL কোয়েরিকে নমনীয় এবং পুনর্ব্যবহারযোগ্য করে তোলে, যা একাধিক স্ক্রিন এবং কম্পোনেন্টযুক্ত বড় প্রকল্পে বিশেষভাবে গুরুত্বপূর্ণ।
GraphQL-এর কেন্দ্রে রয়েছে একটি টাইপ সিস্টেম যা সমস্ত সম্ভাব্য ডেটা এবং API অপারেশন বর্ণনা করে। স্কিমা হল টাইপগুলির একটি বর্ণনা যা সার্ভার ফেরত দিতে পারে এবং এটি যে কোয়েরি গ্রহণ করে। স্কিমা Schema Definition Language (SDL)-এ লেখা হয় এবং ক্লায়েন্ট ও সার্ভারের মধ্যে চুক্তি হিসাবে কাজ করে। ক্লায়েন্ট ইন্ট্রোস্পেকশনের মাধ্যমে স্কিমা পেতে পারে — একটি বিশেষ কোয়েরি __schema যা API-র সম্পূর্ণ বিবরণ ফেরত দেয়।
একটি ব্লগের জন্য স্কিমার উদাহরণ:
// SDL — Schema Definition Language
type User {
id: ID!
name: String!
email: String
posts: [Post!]!
}
type Post {
id: ID!
title: String!
content: String
author: User!
}
type Query {
user(id: ID!): User
posts(page: Int): [Post!]!
}
বিস্ময়সূচক চিহ্ন (!) একটি non-null ফিল্ড নির্দেশ করে — এটি প্রতিক্রিয়ায় উপস্থিত থাকার নিশ্চয়তা দেওয়া হয়। বর্গাকার বন্ধনী [ ] একটি তালিকা নির্দেশ করে। GraphQL স্কেলার টাইপ (Int, Float, String, Boolean, ID), অবজেক্ট টাইপ, enum, union, interface এবং ইনপুট টাইপ (মিউটেশন আর্গুমেন্টের জন্য) সমর্থন করে। কঠোর টাইপিং API-কে স্ব-ডকুমেন্টিং করে এবং ক্লায়েন্ট টুলগুলিকে কোড তৈরি করার অনুমতি দেয়: TypeScript টাইপ, Kotlin ডেটা ক্লাস, Swift স্ট্রাকচার।
ইন্ট্রোস্পেকশন GraphQL-এর একটি অনন্য বৈশিষ্ট্য যা REST-এ অনুপস্থিত। ক্লায়েন্ট স্কিমায় একটি কোয়েরি পাঠাতে পারে এবং সমস্ত টাইপ, ফিল্ড, আর্গুমেন্ট এবং ডিরেক্টিভের সম্পূর্ণ বিবরণ পেতে পারে। এটি GraphiQL এবং Apollo Studio-র মতো সরঞ্জামগুলির ভিত্তি, যা স্বয়ংক্রিয়ভাবে ডেভেলপারদের জন্য ডকুমেন্টেশন এবং অটোকমপ্লিট তৈরি করে। ইন্ট্রোস্পেকশন স্বয়ংক্রিয় পরীক্ষা লেখারও অনুমতি দেয় যা প্রত্যাশিত কাঠামোর সাথে স্কিমার সামঞ্জস্য যাচাই করে।
GraphQL এবং REST-এর মধ্যে পছন্দ API ডিজাইন করার সময় একটি মূল আর্কিটেকচারাল সিদ্ধান্ত। উভয় পদ্ধতিরই নিজস্ব শক্তি এবং দুর্বলতা রয়েছে এবং পছন্দ প্রকল্পের নির্দিষ্ট প্রয়োজনীয়তার উপর নির্ভর করে। REST সরলতা এবং সার্বজনীনতায় জয়ী হয়, GraphQL নমনীয়তা এবং কোয়েরি দক্ষতায়। আসুন তুলনা সারণী দেখি।
| মানদণ্ড | REST | GraphQL |
|---|---|---|
| প্রতিক্রিয়া কাঠামো | নির্দিষ্ট, সার্ভার-সংজ্ঞায়িত | নমনীয়, ক্লায়েন্ট-সংজ্ঞায়িত |
| Overfetching | প্রায়ই — সার্ভার সমস্ত ফিল্ড ফেরত দেয় | না — ক্লায়েন্ট শুধুমাত্র প্রয়োজনীয় ফিল্ড অনুরোধ করে |
| অনুরোধের সংখ্যা | একাধিক round-trips | সমস্ত ডেটার জন্য একটি অনুরোধ |
| ক্যাশিং | নেটিভ HTTP ক্যাশিং | ম্যানুয়াল কনফিগারেশন প্রয়োজন |
| টাইপিং | অন্তর্নির্মিত নয় (ফরম্যাটের উপর নির্ভর) | কঠোর, SDL স্কিমার মাধ্যমে |
| সরঞ্জাম | curl, Postman, Swagger | GraphiQL, Apollo Studio, ইন্ট্রোস্পেকশন |
| ফাইল আপলোড | মূলত multipart-এর মাধ্যমে | অতিরিক্ত প্রোটোকল প্রয়োজন |
| কার্যকারিতা | পূর্বানুমেয়, অপ্টিমাইজ করা সহজ | নেস্টেড কোয়েরি জটিলতার উপর নির্ভর |
GraphQL-এর প্রধান ত্রুটি হল ক্যাশিং জটিলতা। REST-এ, HTTP ক্যাশিং URL স্তরে কাজ করে: /api/users/42-তে একটি অনুরোধ সবসময় একই কাঠামো ফেরত দেয় এবং প্রতিক্রিয়া URL দ্বারা ক্যাশ করা যায়। GraphQL-এ, সমস্ত অনুরোধ একটি একক endpoint-এ যায় এবং প্রতিক্রিয়ার কাঠামো অনুরোধের বডির উপর নির্ভর করে। এই সমস্যা সমাধানের জন্য, Apollo Client ক্লায়েন্ট সাইডে একটি সাধারণীকৃত ক্যাশ ব্যবহার করে, যা প্রতিক্রিয়াগুলিকে id দ্বারা পৃথক সত্তায় ভাগ করে এবং নতুন ডেটা প্রাপ্ত হলে স্বয়ংক্রিয়ভাবে সেগুলি আপডেট করে।
আরেকটি গুরুত্বপূর্ণ দিক হল N+1 সমস্যা। নেস্টেড ডেটা (যেমন, ব্যবহারকারীর পোস্ট এবং প্রতিটি পোস্টের মন্তব্য) অনুরোধ করার সময়, GraphQL তালিকার প্রতিটি আইটেমের জন্য একটি পৃথক SQL কোয়েরি কার্যকর করতে পারে। এটি DataLoader ব্যবহার করে সমাধান করা হয় — ডাটাবেস কোয়েরি ব্যাচ এবং ক্যাশ করার জন্য একটি ইউটিলিটি, যা পৃথক অনুরোধগুলিকে একটি ব্যাচে গ্রুপ করে। REST-এ, এই সমস্যা কম প্রকট কারণ ডেভেলপার সার্ভার সাইডে প্রতিক্রিয়ার কাঠামো নিয়ন্ত্রণ করে।
আসুন Apollo Client-এর সাথে Kotlin মোবাইল অ্যাপ্লিকেশনে GraphQL-এর ব্যবহারিক উদাহরণ দেখি। উদাহরণগুলি সাধারণ পরিস্থিতি প্রদর্শন করে: প্রোফাইল স্ক্রিনের জন্য ডেটা লোড করা (query), একটি নতুন পোস্ট তৈরি করা (mutation) এবং নতুন মন্তব্যে সাবস্ক্রাইব করা (subscription)। প্রতিটি উদাহরণে GraphQL কোয়েরি এবং ক্লায়েন্ট-সাইড কোড উভয়ই অন্তর্ভুক্ত।
একটি GraphQL কোয়েরি ব্যবহারকারী, তার সর্বশেষ পোস্ট এবং মোট ফলোয়ারের সংখ্যা লোড করে। REST-এ, এর জন্য কমপক্ষে 2-3টি অনুরোধের প্রয়োজন হত: /users/42, /users/42/posts, /users/42/stats। GraphQL সেগুলিকে একটি round-trip-এ একত্রিত করে, ধীর সংযোগে স্ক্রিন লোডের সময় হ্রাস করে।
// GraphQL কোয়েরি (.graphql ফাইলে)
query ProfileScreen($userId: ID!) {
user(id: $userId) {
name
bio
avatarUrl
posts(limit: 10) {
id
title
createdAt
}
followersCount
followingCount
}
}
// ক্লায়েন্টে কল (Apollo Client + Kotlin)
val response = apolloClient
.query(ProfileScreenQuery(userId = "42"))
.execute()
binding.nameText.text = response.data?.user?.name
মিউটেশন শুধুমাত্র একটি রিসোর্স তৈরি করে না, বরং UI আপডেটের জন্য এর বর্তমান ডেটাও ফেরত দেয়। __typename ফিল্ডটি Apollo Client ক্যাশ সাধারণীকরণের জন্য ব্যবহার করে — ক্লায়েন্ট সফল মিউটেশন প্রতিক্রিয়ায় ক্যাশে Post রেকর্ড স্বয়ংক্রিয়ভাবে আপডেট করবে।
// GraphQL মিউটেশন
mutation CreatePost($input: CreatePostInput!) {
createPost(input: $input) {
id
title
createdAt
author {
id
name
}
}
}
// input টাইপসহ মিউটেশন কল
val input = CreatePostInput(
title = "GraphQL সম্পর্কে নতুন পোস্ট",
content = "GraphQL API-র সাথে কাজ সহজ করে..."
)
val result = apolloClient
.mutation(CreatePostMutation(input))
.execute()
মোবাইল ডেভেলপমেন্টের প্রসঙ্গে REST-এর ওপর GraphQL-এর একটি গুরুত্বপূর্ণ সুবিধা হল স্বয়ংক্রিয় কোড জেনারেশন। Kotlin-এর জন্য Apollo Client (Apollo GraphQL) বিল্ড সময়ে .graphql ফাইল থেকে টাইপ-সেফ ক্লাস তৈরি করে। যদি সার্ভার স্কিমা পরিবর্তন করে, কোয়েরি আপডেট না হওয়া পর্যন্ত প্রকল্প বিল্ড হবে না। এটি REST-এর সাধারণ রানটাইম ত্রুটিগুলি প্রতিরোধ করে, যেখানে প্রতিক্রিয়া কাঠামোর পরিবর্তন ডেভেলপমেন্টের সময় অলক্ষিত থাকতে পারে।
GraphQL ইকোসিস্টেমে বেশ কয়েকটি মূল লাইব্রেরি এবং সরঞ্জাম অন্তর্ভুক্ত যা ডেভেলপমেন্ট এবং পরিচালনা সহজ করে। Apollo Client সবচেয়ে জনপ্রিয় ক্লায়েন্ট লাইব্রেরি, যা React, iOS, Android এবং Kotlin Multiplatform সমর্থন করে। Facebook-এর Relay ডেটা ব্যবস্থাপনা এবং ক্যাশিংয়ের অনন্য পদ্ধতির সাথে React অ্যাপ্লিকেশনের জন্য একটি বিকল্প। Apollo এবং Relay-এর মধ্যে পছন্দ প্ল্যাটফর্ম এবং কর্মক্ষমতা প্রয়োজনীয়তার উপর নির্ভর করে।
সার্ভার সাইডে, শীর্ষে রয়েছে Apollo Server (Node.js), Netflix DGS Framework (Kotlin/Java) এবং graphql-ruby। স্কিমা ডেভেলপমেন্ট এবং কোয়েরি পরীক্ষার জন্য GraphiQL ব্যবহার করা হয় — ব্রাউজারে নির্মিত একটি ইন্টারেক্টিভ IDE। Apollo Studio প্রোডাকশন পরিবেশের জন্য কর্মক্ষমতা মেট্রিক্স, কোয়েরি ট্রেসিং এবং স্কিমা ব্যবস্থাপনা প্রদান করে। আলাদাভাবে উল্লেখযোগ্য GraphQL Code Generator — একটি সরঞ্জাম যা SDL স্কিমা থেকে TypeScript, Kotlin, Swift এবং Dart টাইপ তৈরি করে।
মোবাইল ডেভেলপমেন্টের জন্য, Apollo Kotlin (Apollo GraphQL) বিশেষ আগ্রহের বিষয় — একটি লাইব্রেরি যা সম্পূর্ণরূপে Kotlin-এ লেখা করুটিন, Flow এবং Multiplatform সমর্থন সহ। এটি Kotlin Multiplatform প্রকল্পে Android এবং iOS-এর জন্য একীভূত GraphQL কোয়েরি ব্যবহারের অনুমতি দেয়। Apollo Kotlin ক্যাশ সাধারণীকরণ করে, ফিল্ড-স্তরের ত্রুটি (আংশিক ত্রুটি) সমর্থন করে এবং .graphql ফাইল থেকে স্বয়ংক্রিয়ভাবে ডেটা মডেল তৈরি করে। এটি GraphQL-কে বড় মোবাইল প্রকল্পের জন্য পছন্দের বিকল্প করে তোলে যেখানে ডেভেলপমেন্ট গতি এবং টাইপ নিরাপত্তা গুরুত্বপূর্ণ।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
GraphQL REST-এর স্থান নেয় না, বরং একটি বিকল্প পদ্ধতি প্রদান করে। REST সাধারণ CRUD API, HTTP ক্যাশিং এবং পূর্বানুমেয় লোডসহ পাবলিক API-র জন্য ভাল। GraphQL অনেক সম্পর্কিত ডেটাসহ জটিল ইন্টারফেসের জন্য সর্বোত্তম।
মাইগ্রেশন ক্রমিকভাবে সম্ভব: GraphQL বিদ্যমান REST পরিষেবাগুলির সামনে একটি স্তর (gateway) হিসাবে কাজ করতে পারে। অনেক কোম্পানি পুরানো API বন্ধ না করে REST-এর পাশাপাশি GraphQL যুক্ত করে। সম্পূর্ণ প্রতিস্থাপনের জন্য রিজলভার পুনরায় লেখা প্রয়োজন।
N+1 ঘটে যখন তালিকার প্রতিটি আইটেমের জন্য একটি পৃথক ডাটাবেস কোয়েরি কার্যকর করা হয়। এটি DataLoader ব্যবহার করে সমাধান করা হয় — একটি লাইব্রেরি যা পৃথক অনুরোধগুলিকে একটিতে ব্যাচ করে এবং একটি HTTP অনুরোধের মধ্যে ফলাফল ক্যাশ করে।
GraphQL স্পেসিফিকেশন সরাসরি ফাইল আপলোড নির্ধারণ করে না। বাস্তবে, নিম্নলিখিতগুলি ব্যবহার করা হয়: base64 এনকোডিং (বড় ফাইলের জন্য সহজ কিন্তু অদক্ষ), graphql-multipart-request-spec প্রোটোকল অনুযায়ী multipart অনুরোধ বা ফাইলের জন্য একটি পৃথক REST endpoint।
GraphQL নিরাপত্তার জন্য অতিরিক্ত ব্যবস্থা প্রয়োজন: নেস্টিং গভীরতা সীমিত করা, কোয়েরি জটিলতা সীমা, অপারেশন স্তরে রেট লিমিটিং। পাবলিক স্কিমা ইন্ট্রোস্পেকশন ডেটা কাঠামো প্রকাশ করতে পারে — প্রোডাকশনে এটি নিষ্ক্রিয় করার সুপারিশ করা হয়।
সারসংক্ষেপ
আমরা একটি মোবাইল অ্যাপ্লিকেশন টার্নকি তৈরি করব
IT Sectr 2017 সাল থেকে স্টার্টআপ এবং ব্যবসার জন্য iOS এবং Android অ্যাপ্লিকেশন তৈরি করে। আমরা আপনাকে পরামর্শ দেব এবং সেরা সমাধান প্রস্তাব করব।
আরও পড়ুন