Web Frontend System Design

Web এর frontend system design এর প্রশ্ন আসে product company গুলোর interview তে ("Facebook এর news feed এর UI design করো", "একটা e-commerce site দ্রুত করো"), আর তোমার Flutter web বা অফিসের JavaScript কাজেও সরাসরি লাগে। এখানে মূল প্রশ্নগুলো: page কোথায় তৈরি হবে (browser নাকি server), data কীভাবে আনবে আর cache করবে, আর কীভাবে দ্রুত দেখাবে।

#Rendering এর ধরন

বাস্তবে মিশ্রণ: Next.js, Nuxt, Astro এর মতো framework একই site এ কিছু পেজ static, কিছু server-rendered, কিছু client-rendered রাখতে দেয়। একটা e-commerce site এ:

• Home আর product page: SSR বা ISR (দ্রুত, Google খুঁজে পায়)
• Cart, checkout, account: CSR (ব্যক্তিগত, SEO লাগে না)
• Blog, help: SSG (CDN থেকে)

Flutter web মূলত CSR ধরনের (বড় JS/WASM bundle), তাই app-ধরনের জিনিস (dashboard, admin panel, internal tool) এর জন্য ভালো, কিন্তু SEO দরকার এমন marketing site বা blog এর জন্য সাধারণত HTML-ভিত্তিক framework ভালো।

#Performance: Core Web Vitals

Google এর তিনটা মাপকাঠি, যা SEO তেও প্রভাব ফেলে:

#দ্রুত করার কৌশল

• কম পাঠাও: code splitting (প্রতিটা পেজ শুধু নিজের JS), tree shaking, অপ্রয়োজনীয় library বাদ
• ছবি: সঠিক আকার (srcset), আধুনিক format (WebP/AVIF), loading="lazy" নিচের ছবিতে, উপরের প্রধান ছবিতে না
• Cache: hash করা file নামে স্থায়ী cache (CDN অধ্যায়), API তে stale-while-revalidate
• আগে আনা: গুরুত্বপূর্ণ জিনিস preload, পরের সম্ভাব্য পেজ prefetch
• Font: font-display: swap, শুধু দরকারি weight
• দুর্বল network মাথায় রাখো: Chrome DevTools এ "Slow 3G" আর CPU slowdown দিয়ে পরীক্ষা করো। বাংলাদেশের অনেক user এর বাস্তবতা এটাই।

#Data আনা আর state

Server state এর library গুলো যা নিজে করে দেয়: cache, একই data এর একাধিক request কে একটায় মেলানো (deduplication), পেছনে নতুন করে আনা, retry, pagination, optimistic update। নিজে এগুলো লিখলে প্রায়ই bug হয়।

#নিরাপত্তা (frontend)

• XSS: user এর লেখা কখনো সরাসরি HTML হিসেবে বসাবে না; framework এর স্বাভাবিক escape ব্যবহার করো; Content Security Policy header
• Token কোথায়: browser এ localStorage এ token রাখলে XSS হলে চুরি হয়। নিরাপদ বিকল্প: HttpOnly; Secure; SameSite cookie (JS পড়তে পারে না), সাথে CSRF সুরক্ষা
• CORS server এ শুধু নিজের domain (FastAPI অধ্যায়)
• গোপন key frontend এ কখনো না: browser এ যা যায় সবাই দেখতে পারে। AI এর API key ও। সবসময় backend এর মাধ্যমে।

#Interview: "একটা news feed এর frontend design করো"

1. Requirement: infinite scroll, ছবি/video, like/comment, নতুন post এর খবর, দুর্বল network
2. Rendering: প্রথম পেজ SSR (দ্রুত আর SEO), তারপর CSR দিয়ে scroll
3. Data: cursor pagination, server state library এ cache, like এ optimistic update
4. Performance: virtualized list (শুধু দৃশ্যমান item DOM এ), ছবি lazy আর সঠিক আকার, skeleton loader, layout shift নেই
5. Real-time: "১২টা নতুন post" ব্যানার (SSE বা polling), নিজে থেকে list লাফাবে না
6. Accessibility আর i18n: keyboard দিয়ে চলা, screen reader, বাংলা font আর সংখ্যা

#অনুশীলন

#নিজেকে যাচাই করো

CSR, SSR আর SSG এর মূল পার্থক্য কী?

CSR এ browser JS চালিয়ে পেজ বানায় (প্রথম দেখা ধীর, SEO দুর্বল)। SSR এ প্রতিটা request এ server পূর্ণ HTML বানায় (দ্রুত প্রথম দেখা, server খরচ)। SSG এ build এর সময় HTML বানিয়ে CDN থেকে দেওয়া হয় (সবচেয়ে দ্রুত আর সস্তা, কিন্তু ব্যক্তিগত data এর জন্য না)।

CLS কী, আর একটা সাধারণ কারণ বলো।

পেজ load হওয়ার সময় জিনিসগুলো কতটা লাফিয়ে সরে যায়। সাধারণ কারণ: ছবির আকার আগে থেকে না দেওয়া, ফলে ছবি আসার পর নিচের লেখা সরে যায়।

Browser এ AI এর API key রাখলে কী হবে?

Browser এ পাঠানো যেকোনো কিছু user দেখতে পারে। Key চুরি হয়ে অন্যরা তোমার খরচে ব্যবহার করবে। API key সবসময় backend এ, browser backend কে call করবে।

Filter আর sort এর অবস্থা URL এ রাখার সুবিধা কী?

Link share করলে অন্যজন একই অবস্থা দেখে, back/forward button ঠিক কাজ করে, আর reload এর পরও অবস্থা থাকে।