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

আমি সবকিছু একেবারে নতুন করে তৈরি করার সিদ্ধান্ত নিলাম। নতুন স্ট্যাকটি হলো Astro এবং Sanity। এটি নিয়ে কিছু সময় কাজ করার পর, এখানে বিস্তারিত দেওয়া হলো যে ঠিক কী কী কাজ করেছে, কী কাজ করেনি এবং আগের টুলগুলোর তুলনায় এটি কোথায় দাঁড়িয়ে আছে।

পোর্টফোলিও-র জন্য কেন Astro?

বেশিরভাগ আধুনিক ওয়েব ফ্রেমওয়ার্ক প্রথমে JavaScript পাঠায় এবং পরে অন্যান্য বিষয় নিয়ে ভাবে। Astro এই ধারণাটি উল্টে দেয়। এটি বিল্ড টাইমে সাধারণ স্ট্যাটিক HTML তৈরি করে এবং শুধুমাত্র তখনই ব্রাউজারে JavaScript পাঠায় যখন একটি নির্দিষ্ট কম্পোনেন্টের আসলে প্রয়োজন হয়। তারা একে islands architecture বলে, তবে এর ব্যবহারিক ফলাফলটি আরও সহজ: আমার পোর্টফোলিও পেজগুলোর ওজন প্রায় শূন্যের কাছাকাছি।

রাউটিং ফাইল-ভিত্তিক, তাই একটি নতুন পেজ তৈরি করা একটি ফোল্ডারে ফাইল ড্রপ করার মতোই সহজ। কম্পোনেন্টগুলো এমন একটি সিনট্যাক্স ব্যবহার করে যা আপনি যদি React, Vue, বা Svelte ব্যবহার করে থাকেন তবে আপনার কাছে পরিচিত মনে হবে। প্রতিবার যখন আমি একটি প্রজেক্ট কেস স্টাডি যোগ করতে চাই, তখন আমাকে নতুন কোনো প্যারাডাইম বা ধারণা খুঁজতে হয় না।

তা সত্ত্বেও, আমি একটি জটিল ওয়েব অ্যাপ্লিকেশন তৈরির জন্য Astro ব্যবহার করব না। আপনি যদি অথেন্টিকেশন সেটআপ করেন, গ্লোবাল স্টেট ম্যানেজ করেন বা রিয়েল-টাইম ডেটা হ্যান্ডেল করেন, তবে আপনি ফ্রেমওয়ার্কটির সাথে লড়াই করতে থাকবেন। তবে মার্কেটিং সাইট, ব্লগ এবং পোর্টফোলিও-র জন্য এটি কোনো বাধা হয়ে দাঁড়ায় না। পেজগুলো দ্রুত মনে হয় কারণ সেগুলো আসলেই দ্রুত। কোনো হেডলাইন বা প্যারাগ্রাফ রেন্ডার করার জন্য hydration overhead-এর অপেক্ষা করতে হয় না।

WordPress থেকে Sanity-তে স্থানান্তর

এই নতুন করে তৈরির আগে, আমার বিকল্প ছিল সবসময় Advanced Custom Fields সহ WordPress। ACF ওয়ার্ডপ্রেসকে সুপারপাওয়ার দেয়, কিন্তু আপনি তবুও অন্য কারো তৈরি করা বাড়িতেနေছেন। Sanity এর উল্টোটা করে। আপনি কোডের মাধ্যমে একটি স্কিমা লেখেন যা ঠিকভাবে নির্ধারণ করে আপনার কন্টেন্ট মডেলটি দেখতে কেমন হবে, এবং Sanity আপনার সেই সিদ্ধান্তগুলোর ওপর ভিত্তি করে এডিটিং ইন্টারফেস তৈরি করে।

আমি সেই নিয়ন্ত্রণ ব্যবহার করে পুনরায় ব্যবহারযোগ্য ব্লক দিয়ে একটি সাধারণ পেজ বিল্ডার তৈরি করেছি। আমি একবার একটি হিরো সেকশন তৈরি করেছি। একবার একটি টেস্টিমোনিয়াল ক্যারোসেল তৈরি করেছি। একবার একটি কার্ড গ্রিড তৈরি করেছি। এখন আমি কোনো নতুন কোড না লিখে বা কোনো পেজ টেমপ্লেট পরিবর্তন না করেই সেই ব্লকগুলো যেকোনো ক্রমে সাজিয়ে নতুন পেজ তৈরি করতে পারি।

এই মানসিকতার পার্থক্যটি গুরুত্বপূর্ণ। WordPress-এর সাথে কাজ করার সময় আমার প্রায়ই মনে হতো আমি এমন একটি টুলের সাথে লড়াই করছি যা মূলত একটি ব্লগ হওয়ার জন্য তৈরি। Sanity-র সাথে আমার মনে হয় আমি সফটওয়্যার তৈরি করছি। কন্টেন্টগুলো শর্টকোড মিশ্রিত স্টাইলিশ HTML না হয়ে পরিচ্ছন্ন স্ট্রাকচার্ড ডেটা হয়ে ওঠে। আমার প্রজেক্টের বর্ণনাগুলো পোর্টেবল অবজেক্ট হিসেবে থাকে, যা আমি চাইলে একটি মোবাইল অ্যাপ বা নিউজলেটারটিতেও পাঠাতে পারি।

একটি পরিচ্ছন্ন ডিপ্লয়মেন্ট ওয়ার্কফ্লো

আমার পুরনো WordPress ওয়ার্কফ্লো ছিল FTP আপলোড, স্টেজিং সাবডোমেইন এবং প্লাগইন আপলোডগুলোর একটি বিশৃঙ্খলা, যা সবসময় সবচেয়ে খারাপ সময়ে ভেঙে পড়ত। এমনকি একটি টাইপো ঠিক করার জন্যও আমাকে মনে মনে একটি চেকলিস্ট তৈরি করে রাখতে হতো।

নতুন ওয়ার্কফ্লোটি খুব সংক্ষিপ্ত:

  • আমি লোকালি পরিবর্তন করি এবং তাৎক্ষণিকভাবে তা দেখতে পাই।
  • কোডটি ঠিক মনে হলে আমি GitHub-এ কমিট করি।
  • Vercel পুশটি গ্রহণ করে এবং স্বয়ংক্রিয়ভাবে সাইটটি ডিপ্লয় করে।

এখানে কোনো FTP ক্লায়েন্ট নেই। সিঙ্ক করার জন্য কোনো স্টেজিং ডেটাবেস নেই। রিপোজিটরিই হলো source of truth।

কন্টেন্টও একইভাবে কাজ করে। যখন আমি Sanity-র ভেতরে কোনো পোস্ট পাবলিশ বা আপডেট করি, একটি webhook Vercel-কে সাইটটি রিবিল্ড করতে বলে। স্ট্যাটিক পেজগুলো নতুন কন্টেন্ট দিয়ে পুনরায় তৈরি হয় এবং কোনো সার্ভার স্পর্শ না করেই CDN আপডেট হয়ে যায়। ম্যানুয়ালি কপি করা, এক্সপোর্ট করা বা কোনো প্লাগইন ডেটাবেস মাইগ্রেশন কাজ করবে কি না—তা নিয়ে প্রার্থনা করা ছাড়াই সবকিছু সিঙ্ক থাকে।

টোকেন দিয়ে ডিজাইন এবং কোডকে একত্রে যুক্ত করা

এই নতুন করে তৈরির অন্যতম একটি নীরব সাফল্য ছিল একটি সঠিক টোকেন সিস্টেম সেটআপ করা। আমি একটি মাত্র JSON ফাইল রাখি যা সাইটের প্রতিটি কালার, টাইপ স্কেল এবং স্পেসিং ভ্যালুর মালিক। সেই ফাইলটিই হলো মূল নিয়ন্ত্রক।

আমি সেই একই ভ্যালু সরাসরি Figma-তে নিয়ে আসার জন্য Token Studio ব্যবহার করি। যখন আমার ডিজাইন ফাইলে surface-default লেখা থাকে, তখন এটি ঠিক সেই সংখ্যাটিকেই নির্দেশ করে যা কোড ব্যবহার করছে। একটি ছোট স্ক্রিপ্ট বিল্ড টাইমে JSON-কে CSS custom properties-এ রূপান্তর করে, যাতে আমার স্টাইলশিটগুলো হার্ডকোডেড হেক্স কোডের পরিবর্তে --color-surface-default-এর মতো ভেরিয়েবল ব্যবহার করে।

বাস্তবে এটি কেন গুরুত্বপূর্ণ তা নিচে দেওয়া হলো। যদি আমি বুঝতে পারি যে আমার ব্র্যান্ড রেড (brand red) মোবাইল স্ক্রিনে কিছুটা বেশি আক্রমণাত্মক মনে হচ্ছে, তবে আমি JSON ফাইলের একটি ভ্যালু পরিবর্তন করি। Figma লাইব্রেরি আপডেট হয়ে যায়। CSS আপডেট হয়ে যায়। সাইটের প্রতিটি জায়গায় এটি আপডেট হয়ে যায়। আমাকে আর grep করতে হয় না।