Multiple Version Handling বা Multiple API Versioning গ্রাফকিউএল (GraphQL) এর ক্ষেত্রে একটি গুরুত্বপূর্ণ চ্যালেঞ্জ, বিশেষত যখন আপনার API ক্রমাগত আপডেট হয় এবং একাধিক সংস্করণ পরিচালনা করতে হয়। গ্রাফকিউএল API-তে সংস্করণিং সাধারণত REST API-র মতো সরাসরি নির্দিষ্ট সংস্করণ পাথ ব্যবহার করে করা হয় না, কিন্তু এটি সঠিকভাবে পরিচালনা করতে কিছু কৌশল এবং ডিজাইন প্যাটার্ন ব্যবহার করা যেতে পারে। এখানে আমরা গ্রাফকিউএল API তে Multiple Version Handling Techniques এর কিছু সাধারণ পদ্ধতি এবং তাদের ব্যবহার ব্যাখ্যা করব।
GraphQL-এ Multiple Version Handling কীভাবে কাজ করে?
GraphQL-এর প্রকৃতি অনুযায়ী, এটি স্কিমা-ভিত্তিক এবং একটি গ্রাফ স্টাইলের API, যেখানে আপনি ডেটার মধ্যে সম্পর্ক স্থাপন করতে পারেন। তবে যখন আপনার API-তে নতুন ফিচার যোগ করা হয় বা বিদ্যমান ফিচারের আচরণ পরিবর্তন করা হয়, তখন আপনি পুরানো সংস্করণগুলিকে সমর্থন করতে এবং নতুন সংস্করণে আপগ্রেড করতে চান।
GraphQL API তে Versioning সাধারণত দুটি পদ্ধতিতে করা হয়:
- Schema-Based Versioning (স্কিমা-বেসড সংস্করণিং)
- Field/Directive-Based Versioning (ফিল্ড বা ডিরেকটিভ-বেসড সংস্করণিং)
এখানে আমরা এই দুটি পদ্ধতির বিবরণসহ অন্যান্য কার্যকর কৌশলগুলি আলোচনা করব।
1. Schema-Based Versioning
Schema-Based Versioning হল একটি পদ্ধতি যেখানে আপনি API-র বিভিন্ন সংস্করণের জন্য আলাদা স্কিমা তৈরি করেন। এটি একে অপরের সাথে স্বাধীনভাবে সংস্করণ পরিচালনার সুযোগ দেয়। যদি কোনও স্কিমা আপডেট করতে হয় (যেমন নতুন ফিল্ড যোগ করা বা বিদ্যমান ফিল্ড পরিবর্তন করা), তাহলে আপনি একটি নতুন সংস্করণের স্কিমা তৈরি করতে পারেন এবং পুরনো সংস্করণটির সাথে এটি পাশাপাশি রাখতে পারেন।
এই পদ্ধতির সুবিধা:
- সহজ এবং পরিষ্কারভাবে সংস্করণ পরিচালনা করা যায়।
- স্কিমার মধ্যে পরিবর্তন করে আপনি নতুন সংস্করণ তৈরি করতে পারেন, এবং ক্লায়েন্টরা তাদের ব্যবহৃত সংস্করণে থাকতে পারে।
এই পদ্ধতির সীমাবদ্ধতা:
- একাধিক স্কিমার পরিচালনা করা অনেক সময় জটিল হতে পারে।
- স্কিমার মধ্যে সম্পর্ক বা ডেটার সমন্বয়ের সমস্যা হতে পারে, যেমন একই ডেটা জন্য বিভিন্ন কনফিগারেশন।
Example:
আপনি দুটি আলাদা স্কিমা তৈরি করতে পারেন: v1 এবং v2।
# v1 schema
type Query {
getUser(id: ID!): User
}
type User {
id: ID!
name: String!
}
# v2 schema
type Query {
getUser(id: ID!): User
getUsersByEmail(email: String!): [User]
}
type User {
id: ID!
name: String!
email: String
}
এখানে, v2 স্কিমায় নতুন getUsersByEmail ফিল্ড যোগ করা হয়েছে। ক্লায়েন্টরা যেকোনো সংস্করণ ব্যবহার করতে পারে এবং সার্ভারে এদের আলাদা আলাদা স্কিমা পরিচালনা করা হবে।
Apollo Server-এ সংস্করণ পরিচালনার জন্য, আপনি আলাদা ApolloServer ইনস্ট্যান্স তৈরি করতে পারেন।
const { ApolloServer } = require('apollo-server');
const serverV1 = new ApolloServer({ typeDefs: schemaV1, resolvers });
const serverV2 = new ApolloServer({ typeDefs: schemaV2, resolvers });
serverV1.listen(4000).then(() => console.log("Server V1 running"));
serverV2.listen(5000).then(() => console.log("Server V2 running"));
এটি আপনাকে v1 এবং v2 সংস্করণের জন্য আলাদা সার্ভার পরিচালনা করতে সহায়তা করবে।
2. Field/Directive-Based Versioning
এটি এমন একটি পদ্ধতি যেখানে আপনি শুধুমাত্র স্কিমার ফিল্ড বা ডিরেকটিভের মাধ্যমে সংস্করণ পরিচালনা করেন, যেমন নতুন ফিল্ড বা পুরনো ফিল্ড বাদ দেওয়া, তবে মূল স্কিমা একে অপরের সাথে সম্পর্কিত থাকে।
এই পদ্ধতির সুবিধা:
- স্কিমার বড় সংস্করণের পরিবর্তন ছাড়াই সামান্য আপডেট করা সম্ভব।
- ক্লায়েন্টরা পুরানো ফিল্ডগুলিকে এখনও ব্যবহার করতে পারে এবং নতুন ফিল্ড ব্যবহার করে নতুন সংস্করণে কাজ করতে পারে।
Example:
এখানে, আমরা একটি কাস্টম ডিরেকটিভ ব্যবহার করব যা গ্রাফকিউএল ফিল্ডের সংস্করণ নির্ধারণ করবে। ধরুন, আমরা একটি @deprecated ডিরেকটিভ ব্যবহার করতে পারি।
type Query {
getUser(id: ID!): User
getUserEmail(id: ID!): String @deprecated(reason: "Use getUserEmailV2 instead")
getUserEmailV2(id: ID!): String
}
type User {
id: ID!
name: String
}
এখানে:
- getUserEmail ফিল্ডটি পুরানো সংস্করণের ফিল্ড হিসেবে @deprecated ডিরেকটিভ সহ চিহ্নিত করা হয়েছে।
- getUserEmailV2 হল নতুন সংস্করণের ফিল্ড।
আপনি চাইলে আরও কাস্টম ডিরেকটিভ তৈরি করতে পারেন, যেমন @new, @legacy, ইত্যাদি, যা ফিল্ডের সংস্করণ শনাক্ত করতে ব্যবহার করা যেতে পারে।
3. Query-Based Versioning
এটি একটি সহজ পদ্ধতি, যেখানে আপনি একটি কুয়েরি বা মিউটেশন নামের মাধ্যমে সংস্করণ নির্ধারণ করেন। গ্রাফকিউএল ক্লায়েন্ট নির্দিষ্ট সংস্করণ ব্যবহার করতে চাইলে, তারা সেই সংস্করণটির কুয়েরি বা মিউটেশন নামটি পাঠাবে।
এই পদ্ধতির সুবিধা:
- একটি নির্দিষ্ট সংস্করণের কুয়েরি বা মিউটেশন নাম ব্যবহার করলে সরাসরি সংস্করণ ব্যবস্থাপনা হয়।
Example:
# v1 version query
query GetUserV1 {
getUser(id: "1") {
id
name
}
}
# v2 version query
query GetUserV2 {
getUser(id: "1") {
id
name
email
}
}
এখানে, দুটি আলাদা কুয়েরি নাম ব্যবহৃত হয়েছে — GetUserV1 এবং GetUserV2, যাতে ক্লায়েন্ট নির্দিষ্ট সংস্করণের কুয়েরি ব্যবহার করতে পারে।
4. Header-Based Versioning
এটি একটি আধুনিক পদ্ধতি যেখানে আপনি HTTP headers এর মাধ্যমে সংস্করণ পরিচালনা করেন। গ্রাফকিউএল সার্ভার একটি নির্দিষ্ট সংস্করণের জন্য কাস্টম হেডার চেক করে এবং সেই অনুযায়ী স্কিমা বা কুয়েরি প্রসেস করে।
এই পদ্ধতির সুবিধা:
- ক্লায়েন্টকে সংস্করণের নাম উল্লেখ করতে হয় না, এটি সরাসরি হেডারে পাঠানো হয়।
- একাধিক সংস্করণ পরিচালনা করার সময় ইউজারের অভিজ্ঞতা উন্নত হয়।
Example:
const { ApolloServer } = require('apollo-server');
const server = new ApolloServer({
typeDefs,
resolvers,
context: ({ req }) => {
const version = req.headers['api-version']; // header থেকে version গ্রহণ
if (version === 'v2') {
// v2 স্কিমা রিটার্ন করুন
}
return {}; // default version বা v1
}
});
server.listen().then(({ url }) => {
console.log(`Server running at ${url}`);
});
এখানে:
- ক্লায়েন্ট একটি কাস্টম api-version হেডার পাঠাবে এবং সার্ভার সেই হেডারের ভিত্তিতে সংস্করণ নির্বাচন করবে।
Conclusion
GraphQL-এ Multiple Version Handling একটি গুরুত্বপূর্ণ বৈশিষ্ট্য, যা বিভিন্ন সংস্করণের সমর্থন এবং পরিচালনা সহজ করে তোলে। Schema-Based Versioning, Field/Directive-Based Versioning, Query-Based Versioning, এবং Header-Based Versioning এর মাধ্যমে আপনি একটি স্কেলেবল এবং নমনীয় API তৈরি করতে পারেন। প্রতিটি পদ্ধতির নিজস্ব সুবিধা এবং সীমাবদ্ধতা রয়েছে, এবং আপনার অ্যাপ্লিকেশনের চাহিদা অনুযায়ী সঠিক পদ্ধতি নির্বাচন করা উচিত।
Read more
