সার্ভার এবং ক্লায়েন্টের মধ্যে একটি ইন্টারফেস ভাগ করে নেওয়া কেন এইরকম খারাপ ধারণা?


12

আমি যখন এইচটিটিপি সার্ভার এবং এর ক্লায়েন্টের মধ্যে একটি ইন্টারফেস ভাগ করার উপায় সম্পর্কে জানতে পারি তখন আমি স্প্রিং ক্লাউড নেটফ্লিক্স ডকুমেন্টেশন পড়ছিলাম । তারা এই উদাহরণটি মাইক্রোসার্ভেসিসের জন্য ব্যবহার করে, যদিও এটি জেনেরিক এইচটিটিপি যোগাযোগের ক্ষেত্রে প্রসারিত করতে পারে না তার কোনও কারণ নেই:

// The shared interface, in a common library
public interface UserService {
    @RequestMapping(method = GET, value = "/users/{id}")
    User getUser(@PathVariable long id);
}

// The controller, on the server
@RestController
public class UserResource implements UserService {
}

// The same interface used for the client
@FeignClient("users")
public interface UserClient extends UserService {
}

এটি এমন একটি ইন্টারফেসকে সংজ্ঞায়িত করে যা একটি সার্ভার (স্প্রিং @RestControllerএটিকে HTTP সার্ভারে রূপান্তর করে) এবং ক্লায়েন্ট উভয় হিসাবে ব্যবহৃত হয় (দ্য ফিগেন @FeignClientএটি HTTP ক্লায়েন্ট ব্যবহারের জন্য সেট আপ করে)। সার্ভার এবং ক্লায়েন্ট শ্রেণীর প্রয়োগগুলি পৃথক প্রকল্পে ব্যবহার করা যেতে পারে তবে এখনও ধরণের মিল মেলে তা নিশ্চিত করতে একই ইন্টারফেস ব্যবহার করুন।

যাইহোক, উদাহরণের নীচে তারা নিম্নলিখিত সাবধানবাণী রাখে:

দ্রষ্টব্য: সাধারণত কোনও সার্ভার এবং ক্লায়েন্টের মধ্যে একটি ইন্টারফেস ভাগ করে দেওয়া উচিত নয়। এটি আঁটসাঁট মিলনের সাথে পরিচিত হয় এবং স্প্রিং এমভিসির সাথে তার বর্তমান আকারে আসলে কাজ করে না (পদ্ধতি প্যারামিটার ম্যাপিং উত্তরাধিকার সূত্রে প্রাপ্ত হয় না)।

ঠিক আছে, সুতরাং এটি এখনই সুসংহত নয় ... তবে সেই অংশটি কোড ভাগ করে নেওয়ার বিরুদ্ধে সতর্ক করার পরে এবং সার্ভার এবং ক্লায়েন্টের মধ্যে সংযুক্তকরণ প্রবর্তন করার পরে আসে যা তারা মনে করেন যে এটি আরও গুরুত্বপূর্ণ। তারা কেন মনে করে যে কোনও ইন্টারফেসটি এভাবে ভাগ করে নেওয়া এত খারাপ ধারণা?

এটি ছাড়া, আপনি গ্যারান্টি দেওয়ার ক্ষমতা হারাবেন যে সার্ভার এবং ক্লায়েন্ট একে অপরকে ডেটা প্রেরণ করবে যা তারা উভয়ই বুঝতে পারে। আপনি একটিতে একটি ক্ষেত্র যুক্ত করতে পারেন তবে অপরটি নয় এবং কেবল রানটাইম পর্যন্ত মিল খুঁজে পেতে পারেন। আমার মনে, এটি সংযুক্তির পরিচয় দিচ্ছে না , কেবল ইতিমধ্যে বিদ্যমান কাপলিংয়ের প্রকাশ করছে। সার্ভারগুলি কী ধরণের ডেটা গ্রহণ করবে তা তাদের জানানোর প্রয়োজনের চেয়ে সার্ভারগুলি সম্পূর্ণ স্বাধীন করার প্রয়োজনীয়তা কি আরও বেশি?


1
ক্লায়েন্ট / সার্ভার দ্বারা পরিচালিত ডেটা / ফর্ম্যাটিংয়ের ক্ষেত্রে, বিদ্যমান সংযুক্তিটি প্রোটোকল দ্বারা নির্ধারিত হয় - নথিভুক্তির একটি অংশ যা কনভেনশন হিসাবে ব্যবহার করা যেতে পারে । একটি ইন্টারফেস ভাগ করে সংযুক্ত সংযোগটি একটি সংকলন-কালীন মিলন - বিবেচনা করুন যখন ইন্টারফেসটি পরিবর্তিত হয় তখন কী ঘটে যায় (উদাহরণস্বরূপ, পশ্চাদমুখে-অসম্পূর্ণ পদ্ধতিতে) তবে সেই ইন্টারফেসটি ব্যবহার করে ক্লায়েন্ট / সার্ভার কোডটি বিভিন্ন সময়ে স্থাপন করা হয়। যে স্থাপনার সময় কাপলিং বিশেষত Netflix এর 'স্কেল, কঠিন পরিচালনা করতে হতে পারে।
কাস্তাগলিয়া

1
আমি নিশ্চিত যে আমি নেটফ্লিক্সের স্কেলে অপারেটিং করছি না :) তবে যদি ইন্টারফেসগুলি একটি পশ্চাৎপদ- অসম্পূর্ণ পদ্ধতিতে পরিবর্তন করা হয়, তবে এটি কেবল সংকলনের সময় পাওয়া থেকে ত্রুটিটি রানটাইমের পরিবর্তে সন্ধানের পরিবর্তিত হবে না? তারা ধীরে ধীরে সমস্ত সার্ভারগুলি আপগ্রেড করার সময় কয়েকটি ফাংশন কলকে ব্যর্থ হতে দেওয়া কি ঠিক বলে বিবেচনা করে?
বেন এস

1
সম্ভবত; ক্লায়েন্ট কোড উপর নির্ভর করে। অন্যান্য
কেসটিও

1
কেবল কৌতুহলী, এই ইন্টারফেসটি ভাগ করে, কী ক্লায়েন্টটি তৈরি করতে পারে তা কোন ভাষা / স্ট্যাককে সীমাবদ্ধ করে?
JeffO

হ্যাঁ - এটি একটি জাভা ফাইল তাই আপনাকে জাভা ব্যবহার করতে হবে। আপনি পারে কিন্তু অন্য জেভিএম ভাষা ব্যবহার করতে পারবেন আমি এটা চেষ্টা করেন নি।
বেন এস

উত্তর:


6

মন্তব্যে যেমন বলা হয়েছে তার কারণ হ'ল এটির ফলে আপনার ক্লায়েন্ট প্ল্যাটফর্মটি আপনার সার্ভার প্ল্যাটফর্মে দৃly়ভাবে মিলিত হয়। এখানে, এর অর্থ হল আপনার ক্লায়েন্টকে আপনার সার্ভারের প্রত্যাশিত চুক্তিটি বোঝার জন্য আপনি যে ভাষা / প্ল্যাটফর্মটি সার্ভারে ব্যবহার করছেন তা ব্যবহার করা দরকার। নোট করুন যে একই কোডটি ভাগ করা (একটি নির্দিষ্ট ভাষা / প্ল্যাটফর্মের একটি শৈল্পিক) এবং একটি নির্দিষ্ট চুক্তিতে সম্মত হওয়ার মধ্যে পার্থক্য রয়েছে।

পরিবর্তে অনেক প্রকল্প তাদের চুক্তিগুলির জন্য ডকুমেন্টেশন ব্যবহার করে। স্ট্যান্ডার্ড প্রোটোকলগুলির (যেমন REST) ​​ওপরে নিরপেক্ষ বিন্যাসে (যেমন JSON) অনুরোধ এবং প্রতিক্রিয়াগুলির উদাহরণ। ( উদাহরণস্বরূপ স্ট্রিপ এপিআই ডক্স দেখুন )। কারণ আপনি যে কোনও সম্ভাব্য ক্লায়েন্ট প্ল্যাটফর্ম ব্যবহার করতে বা মঞ্জুরি দিতে চাইতে পারেন তার জন্য একটি কোড ভিত্তিক চুক্তি লিখতে অবৈধ। এখনও অন্যরা নিরপেক্ষ চুক্তিগুলি সংজ্ঞায়িত করতে API পরিচালনা সরঞ্জামগুলি ব্যবহার করে ।

আপনার ক্ষেত্র যুক্ত করার উদাহরণটি পৃথক উদ্বেগ - এপিআই চুক্তিগুলির সংস্করণে এটি কেন গুরুত্বপূর্ণ of এর একটি উদাহরণ। ক্লায়েন্টদের সেই সংস্করণটি ব্যবহার করা যাক যার জন্য তারা নকশাকৃত। পুরানো পাশাপাশি একটি পশ্চাদপদ-অসম্পূর্ণ নতুন এপিআই সংস্করণ বিদ্যমান। পুরানো সংস্করণটির ক্লায়েন্ট তার দলটি আপডেট করার আগ পর্যন্ত বা আপনি পুরানো সংস্করণটি অবসর নেওয়ার আগ পর্যন্ত কাজ অব্যাহত রাখে (অবমূল্যায়ন / মাইগ্রেশন সময়ের পরে)। সমান্তরাল পরিবর্তন দেখুন ।

(অন্তর্নিহিত পরামর্শ) সতর্কবার্তা অনুসরণ করা ক্লায়েন্ট এবং সার্ভারকে প্রতিটি ক্ষেত্রে উপলব্ধি করার উপায় এবং গতিতে বিকশিত হতে সহায়তা করে। আপনি যদি যথাযথভাবে গ্যারান্টি দিতে পারেন যে আপনার সার্ভার এবং ক্লায়েন্ট সর্বদা একই ভাষা / প্ল্যাটফর্ম ভাগ করে নেবে এবং একই গতিতে বিকশিত হয়, তবে আপনার চুক্তি হিসাবে কোনও ভাষা- এবং প্ল্যাটফর্ম-নির্দিষ্ট কোড আর্টিক্ট সম্ভবত ব্যবহার করা ঠিক হবে। তবে এটি সম্ভবত যুক্তিসঙ্গত প্রত্যাশা নয়, বিশেষত নেটফ্লিক্স ওএসএসকে লক্ষ্যযুক্ত প্রকল্পগুলির জন্য (যে সমস্ত প্রয়োজনীয় জটিলতার সাথে মেঘ স্কেলাবিলিটি এবং পারফরম্যান্সের জন্য বিশেষভাবে উত্সাহিত কিছু)।


2
ক্লায়েন্টটি কি সত্যই ইন্টারফেসটি ব্যবহার করবে? ক্লায়েন্টদের লেখা আরও সহজ করে তোলার উপায় হিসাবে আমি সবসময় এরকম নির্মাণগুলি দেখেছি। সর্বোপরি আপনি আলাদা ভাষায় একটি REST ক্লায়েন্ট লিখতে পারেন।
জিমি টি।

1
ঠিক যেমন, এপিআই এখনও বিদ্যমান থাকবে, এর রুট সংজ্ঞা সহ কিছুই অন্য ভাষায় ক্লায়েন্ট তৈরি করতে বাধা দেয় না, তবে যতক্ষণ আপনি জাভা ব্যবহার করেন ইন্টারফেসটি ব্যবহার করতে পারে
লিওনার্দো ভিলেলা
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.