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

মোবাইল ডেভেলপারদের বিশ্বাস করতে শেখানো হয় যে অ্যাপ্লিকেশনগুলি যে গতিতে প্রকাশ করা হয় এবং আপডেট করা হয় তা সরাসরি ব্যবহারকারীদের কাছে কত দ্রুত পৌঁছায় তার সাথে সম্পর্কিত। অ্যাপ স্টোর সংযম সময় হতাশাজনকভাবে দীর্ঘ হতে পারে। একটি সফ্টওয়্যার ডেভেলপমেন্ট কিট (SDK) তৈরি করা আরও ধীর হবে কারণ আপনাকে অন্য কারও পণ্য বিকাশ এবং প্রকাশ চক্রের সাথে আপনার প্রয়োজনগুলি পূরণ করতে হবে। অনুমানগুলি পরীক্ষা না করা একটি ভাল অজুহাত হতে পারে।

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

ব্যাকএন্ড চালিত উন্নয়ন কি?

ব্যাকএন্ড-চালিত বিকাশ (বা ব্যাকএন্ড-চালিত উন্নয়ন, বা ব্যাকএন্ড-চালিত UI, বা সার্ভার-চালিত UI) হল সার্ভার প্রতিক্রিয়াগুলির উপর ভিত্তি করে ফ্রন্ট-এন্ড অ্যাপ্লিকেশন বিকাশের ধারণা। সার্ভারের প্রতিক্রিয়ার উপর ভিত্তি করে স্ক্রিন এবং প্রবাহ পরিবর্তন হয়।

মোবাইল অ্যাপ্লিকেশন তৈরির বেশিরভাগ কাজ সাধারণত একটি ব্যবহারকারী ইন্টারফেস তৈরির সাথে যুক্ত থাকে: ব্যবহারকারী যে উপাদানগুলির সাথে স্ক্রীনে ইন্টারঅ্যাক্ট করে সেগুলি স্থাপন করা যাতে সে দ্রুত একটি বা অন্য ক্রিয়া সম্পাদন করতে পারে। এই উপাদানগুলির মধ্যে কিছু এপিআই পেলোড দিয়ে ভরা হয়: সাধারণত আদিম প্রকার (পূর্ণসংখ্যা, বুলিয়ান, স্ট্রিং) বা অ্যাপ্লিকেশন ব্যবসায়িক প্রক্রিয়া সহ JSON।

স্ক্রিনগুলি বাস্তবায়নের ঐতিহ্যগত পদ্ধতির কিছু ত্রুটি রয়েছে, কারণ অ্যাপ্লিকেশনের দিকে প্রচুর ব্যবসায়িক যুক্তি থাকতে পারে এবং কোডটি বজায় রাখা আরও কঠিন হয়ে পড়ে:

  • অনেক প্ল্যাটফর্মের জন্য একই কোড প্রয়োজন (Android, iOS, Web, ইত্যাদি)। এই পদ্ধতিটি ক্রস-প্ল্যাটফর্ম সামঞ্জস্য বজায় রাখা কঠিন করে তোলে, যা বাগ এবং অসামঞ্জস্যতার সম্ভাবনা বাড়ায়;
  • একটি মোবাইল অ্যাপ্লিকেশনের প্রতিটি আপডেট বা পরিবর্তন কোড পরিবর্তন করার প্রয়োজনীয়তা বোঝায়, যা অ্যাপ স্টোরে অ্যাপ্লিকেশনগুলির একটি বর্ধিত প্রকাশের দিকে নিয়ে যায়;
  • ডিজিটালে, A/B পরীক্ষা করা আরও কঠিন। গুরুত্বপূর্ণ পণ্যের তথ্য বোঝার জন্য ধারণাগুলি পরীক্ষা করা এবং ব্যবহারকারীদের কাছ থেকে ডেটা সংগ্রহ করা আরও চ্যালেঞ্জিং;
  • যেহেতু বেশিরভাগ ব্যবসায়িক যুক্তি প্রয়োগের দিকে, কোডটি বজায় রাখা এবং বজায় রাখা আরও চ্যালেঞ্জিং।

এই সমস্যাগুলি সমাধান করতে ব্যাকএন্ড-ভিত্তিক উন্নয়ন এসেছে।

নিম্নলিখিত দৃশ্যকল্পটি বিবেচনা করুন (যা নমুনা iOS অ্যাপের উপর ভিত্তি করে তবে সহজেই অন্য যেকোনো ফ্রন্ট-এন্ড প্রকল্পে অনুবাদ করা যেতে পারে):

Scenario for backend driven development

 {
    "pageTitle" : "প্রদর্শক শিরোনাম" ,
    "বক্স" : [
        {
            "টাইপ ": "বিগব্লু" ,
            "শিরোনাম" : "চমৎকার বক্স" ,
            "সাবটাইটেল" : " বক্সের সাবটাইটেল"
        } ,
        {
            "টাইপ ": "ছোট লাল" ,
            "শিরোনাম" : "দারুণ বাক্স"
        } ,
        {
            "টাইপ ": "আয়তক্ষেত্র সবুজ" ,
            "শিরোনাম" : "অবিশ্বাস্য বক্স" ,
            "সাবটাইটেল" : " বক্সের সাবটাইটেল" ,
            "সংখ্যা" : 10
        }
    ]
}

ক্ষেত্রগুলি প্রদর্শন এবং পাঠ্য এবং ভিজ্যুয়াল তথ্য প্রদর্শনের জন্য সমস্ত ব্যবসায়িক যুক্তি সার্ভার-সাইডে একত্রিত এবং বিমূর্ত করা হয়, এই API প্রক্রিয়া করার জন্য একাধিক ইন্টারফেসের প্রয়োজনীয়তা দূর করে। সার্ভার তারপর ব্যবসায়িক যুক্তি প্রয়োগ করে এবং JSON বিন্যাসে একটি API প্রতিক্রিয়া তৈরি করতে এর ফলাফল ব্যবহার করে।

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

আপনি সম্ভবত ইতিমধ্যেই অনুমান করেছেন যে এই পরিস্থিতিতে আপনি কীভাবে A/B পরীক্ষা পরিচালনা করতে পারেন? সার্ভার শুধুমাত্র "বিগ ব্লু" ব্লক দেখতে নির্দিষ্ট ব্যবহারকারীদের নির্বাচন করতে পারে, অন্যরা তিন ধরনের ব্লক দেখতে পারে। এছাড়াও, আপনি A / B পরীক্ষা পরিচালনা করতে পারেন যা স্ক্রিনে ব্লক প্রদর্শনের ক্রম পরিবর্তন করে।

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

Making changes to the interface in backend driven development

 {
    "pageTitle" : "প্রদর্শক শিরোনাম" ,
    "বক্স" : [
        {
            "টাইপ ": "আয়তক্ষেত্র সবুজ" ,
            "শিরোনাম" : "আরেকটি শিরোনাম" ,
            "সাবটাইটেল" : "আরেকটি সাবটাইটেল" ,
            "সংখ্যা" : 100
        } ,
        {
            "টাইপ ": "ছোট লাল" ,
            "শিরোনাম" : "ভিন্ন শিরোনাম"
        }
        {
            "টাইপ ": "বিগব্লু" ,
            "শিরোনাম" : "ব্যাকএন্ড চালিত" ,
            "সাবটাইটেল" : "উন্নয়ন"
        }
    ]
}

আবার ভাব

ব্যাকএন্ড ড্রাইভেন ডেভেলপমেন্ট পদ্ধতি ব্যবহার করার সময় কিছু বিষয় মাথায় রাখতে হবে। প্রথমত, আপনার কোন ডিগ্রি নমনীয়তা প্রয়োজন?

অভিজ্ঞতা এবং গবেষণার উপর ভিত্তি করে, আমরা মাঝারি নমনীয়তাকে সর্বোত্তম বলে বিবেচনা করি।

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

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

একটি সুপার অ্যাপ তৈরি, মুভিল টেক কেস

আপনি সম্ভবত সুপার অ্যাপ ধারণার সাথে পরিচিত এবং WeChat এর মতো একটি অ্যাপের কথা শুনেছেন। WeChat হল একটি মোবাইল মেসেজিং প্ল্যাটফর্ম এবং সোশ্যাল নেটওয়ার্ক যা চীনে তৈরি হয়েছে এবং বিশ্বব্যাপী অত্যন্ত জনপ্রিয় হয়ে উঠেছে।

এই ধরনের একটি অ্যাপ্লিকেশনের লক্ষ্য হল এক জায়গায় একাধিক পুনরাবৃত্ত পরিষেবা সংগ্রহ করা এবং ব্যবহারকারীদের তাদের দৈনন্দিন জীবনের বেশিরভাগ অনলাইন প্রশ্নের অ্যাক্সেসের একক পয়েন্ট দেওয়া। এটি সফ্টওয়্যার ডেভেলপমেন্টের পবিত্র গ্রিল: এটিকে দেখতে অনেক বেশি কার্যকারিতা একত্রিত করাe, ব্যবহারকারীদের জটিল প্রশ্নের সহজ উত্তর এবং বড় সমস্যার সমাধান প্রদান করে।

অতীতে, MovilePay একটি সুপার অ্যাপ তৈরিতে জড়িত ছিল, যার একটি উন্নত সংস্করণ তৈরির প্রক্রিয়া এই নিবন্ধে বর্ণনা করা হয়েছে। এটি একটি পরীক্ষা এবং বৈধতা কেন্দ্র হওয়ার কথা ছিল যেখানে দলটি নতুন পরিষেবাগুলি পরীক্ষা করতে পারে এবং তাদের ব্যবহারের সাধারণ স্থল খুঁজে পেতে পারে।

MovilePay-এর একটি অ্যাপ্লিকেশন তৈরিতে সমস্যা হয়েছে যা দ্রুত কোডে পরিবর্তন করতে পারে। এটির জন্য অনেক পরিষেবা এবং পরিষেবাগুলি পরীক্ষা করা এবং প্রদর্শিত তথ্যের উপর ভিত্তি করে ব্যবহারকারীর আচরণের উপর গবেষণা পরিচালনা করা এবং অনুমানগুলি পরীক্ষা করা প্রয়োজন৷ MovilePay দ্রুত বৈশিষ্ট্য চালু এবং বন্ধ করতে সক্ষম হতে চেয়েছিল। এই ধরনের পরিস্থিতিতে, প্রতিটি পরিবর্তনের জন্য একটি রিলিজ সহ ঐতিহ্যগত পদ্ধতি ব্যবহার করা অসম্ভব ছিল। এই সমস্ত পয়েন্ট এবং একটি জটিল পরিস্থিতি বিবেচনা করে, ব্যাকএন্ড-চালিত বিকাশ প্রয়োগ করার সিদ্ধান্ত নেওয়া হয়েছিল।

এই সমস্যা সমাধানের জন্য MovilePay একটি বিভাগ-ভিত্তিক হোম স্ক্রিন তৈরি করেছে। প্রতিটি বিভাগে উইজেট নামক আইটেমগুলির নিজস্ব সেট রয়েছে। বিভাগগুলি যে কোনও ক্রমানুসারে যে কোনও ইতিমধ্যে বাস্তবায়িত পরিষেবাগুলির জন্য প্রবেশ পয়েন্টগুলি প্রদর্শন করে এবং পৃথক উইজেটগুলিকে হাইলাইট করে৷

কখনও কখনও শুধুমাত্র একটি পরিষেবা প্রদর্শিত হয়. অন্য সময় তিনটি ছিল, বর্তমানে যা পরীক্ষা করা হচ্ছে তার উপর নির্ভর করে। MovilePay অ্যাপ্লিকেশনটিতে কোনও নিয়ম হার্ড-কোড করার পরিবর্তে সার্ভারের পছন্দটি ছেড়ে দিয়েছে। ফলস্বরূপ, অ্যাপ্লিকেশনটি শুধুমাত্র পরিষেবার এন্ট্রি পয়েন্টের সংজ্ঞা এবং প্রতিটি নির্দিষ্ট শৈলীকে কীভাবে রেন্ডার করতে হয় তা জানে৷ তাদের সার্ভার বলে যে কোন পরিষেবাগুলি তৈরি করা উচিত এবং কোন ক্রমে। এখানে কিছু উইজেট রয়েছে যা MovilePay অ্যাপ্লিকেশন প্রদর্শন করতে পারে।

Widgets that the MovilePay application

Widgets in MovilePay application

Widgets in MovilePay application

Widgets in MovilePay application

সুতরাং, একটি অত্যন্ত অভিযোজনযোগ্য হোম স্ক্রীন তৈরি করতে, আমাদেরকে ব্যাকএন্ড থেকে বিভাগগুলির একটি তালিকা সহ একটি প্রতিক্রিয়া পেতে হয়েছিল, প্রতিটিতে উইজেটের একটি তালিকা রয়েছে। নিম্নলিখিত একটি JSON প্রতিক্রিয়ার একটি উদাহরণ যা MovilePay অ্যাপ্লিকেশনটিকে পার্স করা উচিত এবং নীচের উদাহরণের মতো একটি হোম স্ক্রীন তৈরি করা উচিত৷

Parsing and creating a home screen

 [
    {
        "শিরোনাম" : "বিভাগ 1" ,
        "উইজেট" : [
            {
                "শনাক্তকারী" : "COLLECTION_WIDGET" ,
                "সামগ্রী" : [
                    {
                        "শিরোনাম" : "শিরোনাম এ" ,
                        "ছবি" : "ক" ,
                        "রঙ" : "হলুদ"
                    } ,
                    {
                        "শিরোনাম" : "শিরোনাম বি" ,
                        "ছবি" : "বি" ,
                        "রঙ" : "নীল"
                    } ,
                    {
                        "শিরোনাম" : "শিরোনাম সি" ,
                        "ছবি" : "সি" ,
                        "রঙ" : "লাল"
                    } ,
                    {
                        "শিরোনাম" : "শিরোনাম ডি" ,
                        "ছবি" : "ডি" ,
                        "রঙ" : "বেগুনি"
                    } ,
                    {
                        "শিরোনাম" : "শিরোনাম ই" ,
                        "ছবি" : "ই" ,
                        "রঙ" : "সবুজ"
                    }
                ]
            } ,
            {
                "শনাক্তকারী" : "IMAGES_WIDGET" ,
                "সামগ্রী" : [
                    {
                        "ছবি" : "চিত্র" ,
                        "রঙ" : "সবুজ"
                    } ,
                    {
                        "ছবি" : "চিত্র" ,
                        "রঙ" : "নীল"
                    } ,
                    {
                        "ছবি" : "চিত্র" ,
                        "রঙ" : "কমলা"
                    }
                ]
            } ,
            {
                "শনাক্তকারী" : "COLLECTION_WIDGET" ,
                "সামগ্রী" : [
                    {"শিরোনাম" : "শিরোনাম E" , "চিত্র" : "E" , "রঙ" : "সবুজ" } , { "শিরোনাম" : "শিরোনাম F" , "চিত্র" : "F" , "রঙ" : "বেগুনি " } , { "শিরোনাম" : "শিরোনাম জি" , "চিত্র" : "জি" , "রঙ" : "লাল" } , { "শিরোনাম" : "শিরোনাম এইচ" , "চিত্র" : "এইচ" , "রঙ " : "নীল" } , { "শিরোনাম" : "শিরোনাম H" , "চিত্র" : "H" , "রঙ" : "হলুদ" } ] } ] } , { "শিরোনাম" : "বিভাগ 2" , "উইজেট " : [ { "শনাক্তকারী" : "CELLS_WIDGET" , "সামগ্রী" : [ { "শিরোনাম" : "সেল 1" , "রঙ" : "লাল" } , { "শিরোনাম" : "সেল 2" , "রঙ" : "বেগুনি" } , { "শিরোনাম" : "সেল 3" , "রঙ" : "হলুদ" } , { "শিরোনাম" : "সেল 4" , "রঙ" : "নীল" } , { "শিরোনাম" : "সেল 5" , "রঙ" : "গাঢ় সবুজ" } ] } ] } ]

আমরা ব্যাকএন্ড-চালিত বিকাশ ব্যবহার করে নির্মিত হতে পারে এমন কিছু স্ক্রীনের মাধ্যমেও যাব।

Home screens in backend-driven development

নমনীয় নেভিগেশন

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

MovilePay Google Pay, Apple Pay, বা VisaCheckout মডেলের উপর ভিত্তি করে একটি পেমেন্ট SDK বিকাশ করার সিদ্ধান্ত নিয়েছে যা অন্য যেকোন অ্যাপ্লিকেশনের সাথে একত্রিত করা যেতে পারে।

যাইহোক, যেহেতু একটি SDK-তে কাজ করা সাধারণ বিকাশের নিদর্শনগুলি ব্যবহার করে পরীক্ষা করার খুব কম ক্ষমতা বোঝায়, তাই অটোমেশন প্রয়োজন।

যেহেতু MovilePay অর্থপ্রদান নিয়ে কাজ করে, তাই প্রবাহের রূপান্তর ছিল গুরুত্বপূর্ণ। MovilePay কোনো রূপান্তর ফানেল পর্যায়ে তার ব্যবহারকারীদের হারানোর সামর্থ্য রাখে না। অতএব, সমগ্র ব্যবসায়িক প্রক্রিয়াটি অপ্টিমাইজ করা প্রয়োজন ছিল — ব্যবহারকারীর নিবন্ধন থেকে শুরু করে একটি কার্ড যোগ করা এবং অর্থপ্রদান করা পর্যন্ত। এটি যেখানে ব্যাকএন্ড-চালিত উন্নয়ন আবার কাজে এসেছে, সার্ভারটিকে অ্যাপ্লিকেশনের "নেভিগেটর" এ পরিণত করেছে।

Optimizing the business process with BDD

MovilePay অ্যাপ্লিকেশন স্ক্রীনগুলির মধ্যে কোনটিই জানত না যে কোন স্ক্রীন পরবর্তী ছিল৷ পূর্ববর্তী স্ক্রীনটি তার কাজগুলি সম্পন্ন করার পরে, সার্ভারটি পরবর্তী কোন স্ক্রীনটি প্রদর্শিত হবে তা ফেরানোর জন্য দায়ী ছিল।

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

কৌশলের এই পরিমিত পরিবর্তন স্ট্রিমলাইন করার অনুমতি দিয়েছে। MovilePay সাইন আপ ফর্ম প্রদর্শন করার জন্য বিভিন্ন উপায় চেষ্টা করেছে। কার্ড যোগ করার আগে বা পরে চেকআউট স্ক্রীন দেখানো পছন্দনীয় কিনা তা পরীক্ষা করা সম্ভব ছিল। উদাহরণস্বরূপ, অন্যান্য অর্থপ্রদানের বিকল্পগুলির তুলনায় MovilePay তার রূপান্তর হার 30% বৃদ্ধি করতে সক্ষম হওয়ার একটি কারণ।

আরেকটি উদাহরণ হল কিভাবে MovilePay ব্যাকএন্ড-ড্রাইভেন ডেভেলপমেন্ট ব্যবহার করে তার সমস্যাগুলি সমাধান করে। আমরা মনে করি আপনি বিস্ময়করঅনুশীলনে এই পদ্ধতির প্রয়োগ কিভাবে ering. আমাকে দেখান এটা কত সহজ.

একই লক্ষ্য অর্জনের জন্য অনেকগুলি বিকল্প পদ্ধতি রয়েছে। আমরা আপনাকে দেখাব কিভাবে MovilePay এটি iOS এর জন্য করেছে। যদি ইচ্ছা হয়, এই ধারণাটি অন্য যেকোনো ফ্রন্ট-এন্ড প্ল্যাটফর্মে প্রয়োগ করা যেতে পারে।

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

উইজেট (iOS)

নমনীয়তার পরিপ্রেক্ষিতে, MovilePay মনে করেছে যে সর্বোত্তম সমাধান হবে উইজেটগুলিকে সাধারণীকরণ করা যা একটি প্রোটোকলের সাথে পার্স করা দরকার। MovilePay কোন উইজেট কাঠামো ডেটা পার্স করতে হবে তা নির্ধারণ করতে একটি enum সেট করে।

 প্রোটোকল উইজেট : ডিকোডেবল { }

enum WidgetIdentifier : স্ট্রিং , ডিকোডেবল {
    কেস ব্যানার = "ব্যানার"
    কেস কালেকশন = "সংগ্রহ"
    কেস তালিকা = "তালিকা"

    var মেটাটাইপ : উইজেট  প্রকার {
        নিজেকে পরিবর্তন করুন {
        মামলা _ ব্যানার :
            ব্যানার উইজেট ফেরত দিন  স্ব
        মামলা _ সংগ্রহ :
            কালেকশনউইজেট ফেরত দিন  স্ব
        মামলা _ তালিকা :
            ফিরতি লিস্টউইজেট  স্ব
        }
    }
}

তারা উইজেট প্রোটোকল দ্বারা বাস্তবায়িত Decodable প্রোটোকলের মাধ্যমে Codable API-এর সুবিধা নিচ্ছে। নীচে একটি উইজেট গঠন সংজ্ঞায়িত একটি উদাহরণ.

 struct ব্যানারউইজেট : উইজেট {
    ব্যক্তিগত যাক imageURLString : স্ট্রিং
}

struct CollectionWidget : উইজেট {

    struct আইটেম : ডিকোডেবল {
        যাক imageURLString : স্ট্রিং
        যাক শিরোনাম : স্ট্রিং
        যাক সাবটাইটেল : স্ট্রিং
    }

    যাক সেকশন শিরোনাম : স্ট্রিং
    যাক তালিকা : [ আইটেম ]
}

struct ListWidget : উইজেট {

    struct আইটেম : ডিকোডেবল {
        যাক imageURLString : স্ট্রিং
        যাক পাঠ্য : স্ট্রিং
    }

    যাক সেকশন শিরোনাম : স্ট্রিং
    যাক তালিকা : [ আইটেম ]
}

অবশেষে, এটিকে একটি টাইপ ইরেজার হিসাবে সংজ্ঞায়িত করা হয়েছিল, যা প্রয়োজনীয় আরম্ভ পদ্ধতির সাথে যেকোন উইজেটকে ব্যাখ্যা করে, যখন একজনকে ডিকোডেবল দ্বারা প্রদত্ত কাস্টম ইনিশিয়ালাইজেশন পরিবর্তন করতে হবে।

 চূড়ান্ত ক্লাস AnyWidget : ডিকোডেবল {

    প্রাইভেট enum CodingKeys : CodingKey {
        কেস শনাক্তকারী
    }

    যাক উইজেট : উইজেট ?

    প্রয়োজনীয় init ( ডিকোডার থেকে : ডিকোডার ) নিক্ষেপ {
        কর {
            ধারক = ডিকোডার চেষ্টা করুন  কন্টেইনার ( keyedBy : CodingKeys . স্বয়ং )
            let type = ধারক চেষ্টা করুন  ডিকোড ( উইজেটআইডেন্টিফায়ার  সেলফ , কী ফরকি : আইডেন্টিফায়ার )
            স্ব উইজেট = টাইপ চেষ্টা করুন  মেটাটাইপ init ( থেকে : ডিকোডার )
        } ধর {
            স্ব উইজেট = শূন্য
        }
    }
}

এই মুছে ফেলার ধরনটি উইজেটের শনাক্তকারী এবং এর "মেটা-টাইপ" বৈশিষ্ট্যকে ডিক্রিপ্ট করতে ব্যবহৃত হয় যাতে পার্স করা উইজেটের অবশিষ্ট ডেটা পার্স করতে কোন উইজেট কাঠামো ব্যবহার করা উচিত।

এই সবের ফলে নিচের কাঠামোটি উইজেট সম্পর্কে সমস্ত তথ্য সম্বলিত একটি প্রতিক্রিয়া পার্স করতে সক্ষম হয়। এটির একটি অনন্য বৈশিষ্ট্য রয়েছে: উইজেট প্রোটোকল প্রকারের একটি অ্যারে এবং উপরে সংজ্ঞায়িত টাইপ ইরেজার ব্যবহার করে প্রতিটি উইজেট ডিক্রিপ্ট করতে পারে।

 struct হোম রেসপন্স : ডিকোডেবল {

    প্রাইভেট enum CodingKeys : CodingKey {
        কেস উইজেট
    }

    যাক উইজেট : [ উইজেট ]

    init ( ডিকোডার থেকে : ডিকোডার ) নিক্ষেপ করে {
        ধারক = ডিকোডার চেষ্টা করুন  কন্টেইনার ( keyedBy : CodingKeys . স্বয়ং )
        স্ব উইজেট = কন্টেইনার চেষ্টা করুন  ডিকোড ( [ যেকোন উইজেট ] . স্ব , কী জন্য : . উইজেট৷ss="টোকেন বিরাম চিহ্ন">)  কমপ্যাক্টম্যাপ {$ 0. উইজেট } } init ( উইজেট : [ উইজেট ] ) { স্বয়ং উইজেট = উইজেট } }

MovilePay অন্যান্য বিকল্পগুলি বেছে নিতে পারে, যেমন প্রোটোকল ব্যবহার না করা এবং পার্সিংয়ের জন্য প্রতিটি সমর্থিত উইজেটের একটি অ্যারে ফিরিয়ে দেওয়ার জন্য ব্যাকএন্ডের উপর নির্ভর করা। যাইহোক, আমরা দেখেছি যে আমাদের প্রোটোকল পছন্দটি রক্ষণাবেক্ষণ এবং পাঠযোগ্যতার জন্য সেরা পছন্দ। এই পদ্ধতিটি একটি নতুন কাঠামো তৈরি করতে এবং প্রতিবার নতুন উইজেট তৈরি করার জন্য enum-এ কেস যোগ করার জন্য যথেষ্ট ছিল। একই পরিস্থিতিতে একটি ভিন্ন সিস্টেমের সাথে, HomeResponse-এর নকশা পরিবর্তন করতে হবে।

নীচে একটি সম্ভাব্য JSON API প্রতিক্রিয়া যা এই মডেলটি পার্স করবে৷

 {
    "উইজেট" : [
        {
            "শনাক্তকারী" : "ব্যানার" ,
            "imageURLString" : "url_image_to_be_downloaded"
        } ,
        {
            "শনাক্তকারী" : "সংগ্রহ" ,
            "sectionTitle" : "বিভাগের শিরোনাম" ,
            "তালিকা" : [
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "শিরোনাম" : "শিরোনাম আইটেম 1" ,
                    "সাবটাইটেল" : "সাবটাইটেল আইটেম 1"
                } ,
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "শিরোনাম" : "শিরোনাম আইটেম 2" ,
                    "সাবটাইটেল" : "সাবটাইটেল আইটেম 2"
                } ,
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "শিরোনাম" : "শিরোনাম আইটেম 3" ,
                    "সাবটাইটেল" : "সাবটাইটেল আইটেম 3"
                }
            ]
        } ,
        {
            "আইডেন্টিফায়ার" : "লিস্ট" ,
            "sectionTitle" : "বিভাগের শিরোনাম" ,
            "তালিকা" : [
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "টেক্সট" : "টেক্সট আইটেম 1"
                } ,
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "টেক্সট" : "টেক্সট আইটেম 2"
                } ,
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "টেক্সট" : "টেক্সট আইটেম 3"
                }
            ]
        } ,
        {
            "শনাক্তকারী" : "ব্যানার" ,
            "imageURLString" : "url_image_to_be_downloaded"
        }
    ]
}

এই পদ্ধতিটি সুপার অ্যাপের বিকাশের খুব কাছাকাছি, যা MovilePay কে বিভিন্ন ব্যবহারকারীদের কাছে বিভিন্ন পরিষেবা উপস্থাপন করতে, অনেকগুলি প্রদর্শন বিকল্প পরীক্ষা করতে, অনুমানগুলি তৈরি করতে এবং কোন পরিষেবার জন্য কোন উইজেট ব্যবহার করা হবে তা নির্ধারণ করতে দেয়৷ স্ক্রিন বাছাই এবং পরিষেবা গ্রুপিংয়ের পরিবর্তনটি মুভিলপে আগে যা করেছিল তার কাছাকাছি ছিল।

নেভিগেশন (iOS)

উইজেট সমস্যা সমাধান করার পরে, MovilePay একইভাবে নেভিগেশন উন্নত করার চেষ্টা করেছে। তারা অ্যাকশন প্রোটোকল তৈরি করেছে, যা উইজেট প্রোটোকলের অনুরূপ।

একটি অ্যাকশন হল একটি কাঠামোগত বস্তু যা কিছু MovilePay API-এর JSON প্রতিক্রিয়াতে ফিরে আসে, একটি আইডি এবং যে কোনও পরামিতি যা এটি প্রতিনিধিত্ব করে এমন দৃশ্যে প্রদর্শিত হওয়া উচিত। ফলস্বরূপ, অ্যাকশন প্রোটোকল স্ট্রাকচার্ড অবজেক্ট ডিকনস্ট্রাকট করতে সাহায্য করার জন্য দায়ী।

 প্রোটোকল অ্যাকশন : ডিকোডেবল {
    func দৃশ্য ( ) - > UIViewController
}

enum ActionIdentifier : স্ট্রিং , ডিকোডেবল {
    কেস হোম = "বাড়ি"
    কেস screenOne = "SCREEN_ONE"
    কেস স্ক্রিনটু = "SCREEN_TWO"

    var মেটাটাইপ : অ্যাকশন  প্রকার {
        নিজেকে পরিবর্তন করুন {
        মামলা _ বাড়ি :
            হোম অ্যাকশন ফেরত  স্ব
        মামলা _ পর্দা একওকেন অপারেটর">: স্ক্রিনঅনঅ্যাকশন রিটার্ন করুন  সেলফ কেস  স্ক্রিনটু : রিটার্ন স্ক্রিনটোঅ্যাকশন  সেলফ } } } কাঁচা দেখুন

অ্যাকশন প্রোটোকল এবং উইজেট প্রোটোকলের মধ্যে একমাত্র পার্থক্য হল আমরা এমন একটি পদ্ধতি প্রদান করি যা অ্যাকশন সংজ্ঞায় প্রতিটি অ্যাকশনের জন্য উপযুক্ত দৃশ্য প্রদান করে। একটি উদাহরণ হিসাবে, এই কর্মগুলি কিভাবে বাস্তবায়িত হয় তা দেখুন।

 struct HomeAction : Action {
    func দৃশ্য ( ) - > UIViewController {
        হোম কোঅর্ডিনেটর ফিরুন  দৃশ্য ( )
    }
}

struct ScreenOneAction : Action {
    যাক শিরোনাম : স্ট্রিং

    func দৃশ্য ( ) - > UIViewController {
        ScreenOneCoordinator ফেরত দিন  দৃশ্য ( শিরোনাম : স্ব . শিরোনাম )
    }
}

struct ScreenTwoAction : Action {
    যাক শিরোনাম : স্ট্রিং
    যাক সাবটাইটেল : স্ট্রিং

    func দৃশ্য ( ) - > UIViewController {
        ScreenTwoCoordinator রিটার্ন করুন  দৃশ্য ( শিরোনাম : স্ব . শিরোনাম , উপশিরোনাম : স্ব . উপশিরোনাম )
    }
}

উপরের উদাহরণটি দেখায় যে, যখন তৈরি করা হয়, অ্যাকশনে অবশ্যই তাদের দৃশ্য শুরু করার জন্য এবং UIViewControllerকে ইনস্ট্যান্টিয়েট করার জন্য সমন্বয়কারী পদ্ধতিতে কল করার জন্য প্রয়োজনীয় সমস্ত বৈশিষ্ট্য থাকতে হবে। সমন্বয়কারীরা এমন কাঠামো যা একটি UIViewController প্রদান করে। এখানে উল্লেখ করার মতো কিছু: MovilePay কোঅর্ডিনেটর স্ট্রাকটে একটি ডিজাইন প্যাটার্ন ব্যবহার করে, যা একটি স্ট্যাটিক দৃশ্য() পদ্ধতি দ্বারা প্রতিনিধিত্ব করে যা প্রতিটি পর্যায়ের জন্য একটি UIViewController দৃষ্টান্ত তৈরি করার দায়িত্ব দেওয়া হয়।

 চূড়ান্ত ক্লাস হোম কোঅর্ডিনেটর : সমন্বয়কারী {
    স্ট্যাটিক ফাঙ্ক দৃশ্য ( ) - > UIViewController {
        // ভিউ কন্ট্রোলার এবং এই দৃশ্যের সমস্ত আর্কিটেকচার উপাদান তৈরি করুন...
        তৈরি করা ভিউ কন্ট্রোলার ফেরত দিন
    }
}

চূড়ান্ত ক্লাস ScreenOneCoordinator : সমন্বয়কারী {
    স্ট্যাটিক ফাঙ্ক দৃশ্য ( ) - > UIViewController {
        // ভিউ কন্ট্রোলার এবং এই দৃশ্যের সমস্ত আর্কিটেকচার উপাদান তৈরি করুন...
        তৈরি করা ভিউ কন্ট্রোলার ফেরত দিন
    }
}

চূড়ান্ত ক্লাস স্ক্রিনটু কোঅর্ডিনেটর : সমন্বয়কারী {
    স্ট্যাটিক ফাঙ্ক দৃশ্য ( ) - > UIViewController {
        // ভিউ কন্ট্রোলার এবং এই দৃশ্যের সমস্ত আর্কিটেকচার উপাদান তৈরি করুন...
        তৈরি করা ভিউ কন্ট্রোলার ফেরত দিন
    }
}

এটিও উল্লেখ করা উচিত যে, নির্বাচিত স্থাপত্য নকশা প্যাটার্ন সত্ত্বেও (MVC, MVP, MVVM-C, VIPER-C, VIP, বা অন্য কোনও আর্কিটেকচার যা দৃশ্য তৈরি করতে এবং এক দৃশ্য থেকে অন্য দৃশ্যে যাওয়ার জন্য সমন্বয়কারী ব্যবহার করে), ব্যবহার করে বাস্তবায়ন অ্যাকশন এবং ব্যাকএন্ড-চালিত উন্নয়ন বেশ উপযুক্ত।

অ্যাকশন মুভিলপে প্রেক্ষাপটের জন্য, আমরা সামান্য অভিযোজন সহ উইজেটগুলির জন্য একই ধরণের ইরেজার ব্যবহার করেছি।

 চূড়ান্ত ক্লাস AnyAction : ডিকোডেবল {

    প্রাইভেট enum CodingKeys : CodingKey {
        কেস শনাক্তকারী
    }

    কর্ম যাক : কর্ম ?

    প্রয়োজনীয় init ( ডিকোডার থেকে : ডিকোডার ) নিক্ষেপ {
        কর {
            ধারক = ডিকোডার চেষ্টা করুন  কন্টেইনার ( keyedBy : CodingKeys . স্বয়ং )
            let type = ধারক চেষ্টা করুন  ডিকোড ( ActionIdentifier . self , forKey : . identifier )
            স্ব কর্ম = টাইপ চেষ্টা করুন  মেটাটাইপ init ( থেকে : ডিকোডার )
        } ধর {
            স্ব কর্ম = শূন্য
        }
    }
}

এখানে একটি প্রাসঙ্গিক নোট হল যে MovilePay নকল টাইপ ইরেজার কোড এড়াতে জেনেরিক ডিজাইন প্যাটার্ন ব্যবহার করতে পারে। যাইহোক, তারা না বেছে নিয়েছে। নিম্নলিখিত একটি স্ট্রাকচারের একটি উদাহরণ যেখানে একটি অ্যাকশন রয়েছে।

 struct ResponseModelForActions : ডিকোডেবল {
    ব্যক্তিগত কোডিংকি"টোকেন অপারেটর">: কোডিংকি { কেস অ্যাকশন , টেক্সট } লেট অ্যাকশন : অ্যাকশন ? let text : String init ( decoder থেকে : Decoder ) নিক্ষেপ করে { let container = চেষ্টা করুন ডিকোডার  ধারক ( keyedBy : CodingKeys . self ) self . পাঠ্য = ধারক চেষ্টা করুন  ডিকোড ( স্ট্রিং . সেলফ , ফরকি : টেক্সট ) anyAction = চেষ্টা করতে দিন ? ধারক ডিকোড ( AnyAction . self , forKey : . action ) self . কর্ম = কোনো কাজ ?। কর্ম } }

এটি একটি API দ্বারা প্রদত্ত JSON হতে পারে, উদাহরণস্বরূপ, স্ক্রিনে একটি UIButton তৈরি করতে৷ ব্যবহারকারী এই বোতামটি আলতো চাপার পরে যে অ্যাকশন অবজেক্টটি পরিচালনা করা হয় তা প্রদত্ত ক্রিয়া সম্পাদন করতে পারে, যার ফলে অ্যাপ্লিকেশনটি হোম স্ক্রীন প্রদর্শন করতে পারে।

 {
    "টেক্সট" : "প্রদর্শক পাঠ্য" ,
    "কর্ম" : {
        "শনাক্তকারী" : "HOME_SCREEN"
    }
}

অ্যাকশন অবজেক্টের মাধ্যমে সমস্ত সমন্বয়কারীকে একটি নতুন দৃশ্য পেতে অনুমতি দেওয়ার জন্য সমন্বয়কারী প্রোটোকল প্রসারিত করে এটি সহজেই অর্জন করা হয়েছিল।

এটি সমন্বয়কারীকে কাজ করার অনুমতি দেয়, অর্থাৎ, সেই ক্রিয়াটির জন্য পরবর্তী UIViewController দৃষ্টান্ত তৈরি করে এবং তারপর এটি প্রদর্শন করে।

 এক্সটেনশন সমন্বয়কারী {
    func দৃশ্য ( কর্ম ব্যবহার করে : অ্যাকশন ) - > UIViewController {
        কর্ম ফেরত  দৃশ্য ( )
    }
}

সার্ভার বাস্তবায়ন একটি ইঙ্গিত

আপনি সম্ভবত ভাবছেন যে সার্ভারের দিকে এই সব কেমন দেখাচ্ছে। বাহ্যিক তথ্যের সাথে কীভাবে আপনার পরিষেবা এবং মূল ক্ষমতাগুলিকে বিভ্রান্ত করবেন না? সফটওয়্যার ডেভেলপমেন্টে সাফল্যের রহস্য হল স্তরে স্তরে কাজ করা।

সুতরাং, সমস্ত জটিল মূল পরিষেবাগুলি ছাড়াও, MovilePay সার্ভারে আরেকটি স্তর যুক্ত করেছে, যা, অন্যান্য সমস্ত পরিষেবাকে বিমূর্ত করে এবং সমস্ত অ্যাপ্লিকেশন যুক্তি প্রয়োগ করে, ডেটাকে ফ্রন্টএন্ড দ্বারা প্রত্যাশিত প্রতিক্রিয়াতে রূপান্তরিত করে৷ এই স্তরটিকে BFF বলা হয়, বা ব্যাকএন্ড ফর ফ্রন্টেন্ড একটি স্তর যা সিস্টেমের দুটি পৃথক এবং সম্পর্কহীন প্রান্তের মধ্যে যোগাযোগ সরবরাহ করে। এটি যেখানে স্ট্রিং, ছবি, স্ট্রীম এবং শৈলীর বৈচিত্রগুলি কনফিগার করা হয় এবং অ্যাপ্লিকেশনগুলিতে পাঠানোর আগে অন্তর্নিহিত ডেটাতে প্রয়োগ করা হয়।

উপসংহার

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

সর্বোপরি, আপনার কোন স্তরের নমনীয়তা প্রয়োজন সে সম্পর্কে আপনার সর্বদা সতর্ক হওয়া উচিত। অত্যন্ত বহুমুখী UI উপাদান তৈরি করা বা অ-মানক ফন্ট এবং মার্জিন ব্যবহার করা কোডবেসটিকে অবিশ্বাস্যভাবে জটিল করে তুলতে পারে, যা ব্যবহারকারীর অভিজ্ঞতা আরও খারাপের দিকে নিয়ে যায়।

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