আপনার NextJS প্রয়োজন নেই
React অ্যাপ তৈরির জন্য Next.js হলো ডিফল্ট সমাধান। এটি একটি চমৎকার ফ্রেমওয়ার্ক। কিন্তু ডিফল্ট মানেই যে এটি প্রয়োজনীয়, তা নয়।
ভুল প্রজেক্টে এটি ব্যবহার করার ফলে আমাদের কাজের গতি কমে গিয়েছিল এবং টিমের মধ্যে কাজের সমন্বয় ব্যাহত হয়েছিল। আমরা ড্যাশবোর্ড এবং চার্ট সম্বলিত একটি ডেটা-ভারী (data-heavy) প্রোডাক্ট তৈরি করেছিলাম। প্রায় প্রতিটি স্ক্রিনই লগইন করার পর দেখা যেত।
এই ধরণের অ্যাপের জন্য, server-side rendering (SSR) কোনো বাড়তি ভ্যালু যোগ না করেই খরচ বাড়িয়ে দিয়েছিল।
সঠিক টুলটি নির্ভর করে আপনি কী তৈরি করছেন তার ওপর।
Content-first প্রজেক্ট: • মার্কেটিং সাইট • ব্লগ • স্টোরফ্রন্ট • ডকুমেন্টেশন • এখানে Next.js ব্যবহার করুন। এখানে SEO গুরুত্বপূর্ণ এবং কন্টেন্ট স্ট্যাটিক থাকে।
Application-first প্রজেক্ট: • ইন্টারনাল টুলস • ড্যাশবোর্ড • অ্যাডমিন প্যানেল • SaaS কনসোল • এখানে একটি Vite-ভিত্তিক SPA ব্যবহার করুন। এই অ্যাপগুলো অথেনটিকেশনের (auth) পেছনে থাকে এবং API-এর ওপর নির্ভর করে।
আমরা Next.js থেকে একটি Vite SPA-তে চলে এসেছি। এর কারণগুলো নিচে দেওয়া হলো:
১. সহজ ডিবাগিং (Easier Debugging) সার্ভার এররগুলো আপনার কম্পোনেন্টের সাথে সরাসরি মেলানো যায় না। অন্যদিকে, ক্লায়েন্ট-সাইড এররগুলো ব্রাউজারে পরিষ্কার স্ট্যাক ট্রেস (stack traces) সহ ঘটে। এতে বাগ ফিক্স করা দ্রুত হয়।
২. উন্নত টেস্টিং (Better Testing) একটি সার্ভার কম্পোনেন্ট যা অন্য সার্ভার কম্পোনেন্ট রেন্ডার করে, সেটিকে সহজে ইউনিট টেস্ট করা যায় না। আমরা শুধুমাত্র টেস্ট করার সুবিধার জন্য কিছু ডিজাইনে পরিবর্তন এনেছিলাম, যা ছিল একটি ভুল সিদ্ধান্ত।
৩. সহজ অথেনটিকেশন (Simpler Auth) SSR-এর ক্ষেত্রে প্রতিটি রিকোয়েস্টের সময় সার্ভারকে টোকেন ভ্যালিডেট করতে হয়। এটি অ্যাটাক সারফেস (attack surfaces) বাড়িয়ে দেয় এবং কুকি লজিককে জটিল করে তোলে। একটি ক্লায়েন্ট-ফার্স্ট অ্যাপে অথেনটিকেশন এক জায়গাতেই হ্যান্ডেল করা যায়: API।
৪. কম ইনফ্রাস্ট্রাকচার খরচ (Lower Infrastructure Costs) SSR-এর প্রতিটি রিকোয়েস্টের জন্য একটি সবসময় চালু থাকা সার্ভার প্রয়োজন। অন্যদিকে, একটি স্ট্যাটিক ফ্রন্টএন্ড CDN থেকে ফাইল হিসেবে ডেলিভারি করা যায়। এতে আপনাকে চালাতে এবং সুরক্ষিত রাখতে একটি সার্ভিস কম লাগে।
৫. কম জটিলতা (Less Complexity) Next.js সার্ভার এবং ক্লায়েন্টের মধ্যে একটি বিভাজন তৈরি করে। ফ্রন্টএন্ড ইঞ্জিনিয়ারদের মিডলওয়্যার (middleware) এবং ক্যাশিংয়ের (caching) মতো সার্ভার সংক্রান্ত বিষয়গুলোও সামলাতে হতো। এটি আমাদের কাজের গতি কমিয়ে দিয়েছিল।
আমরা ধাপে ধাপে মাইগ্রেশন করেছি। পাবলিক এবং SEO-গুরুত্বপূর্ণ পেজগুলোর জন্য আমরা Next.js রেখে দিয়েছি। বাকি সবকিছু আমরা একটি Vite SPA-তে সরিয়ে নিয়েছি।
এর ফলে হওয়া পরিবর্তনগুলো (trade-offs) ছিল সামান্য: • SEO: লগইন করা ড্যাশবোর্ডের জন্য SEO-এর প্রয়োজন নেই। • ইনিশিয়াল লোড (Initial load): ডেটা-ভারী অ্যাপগুলো সাধারণত ডেটাবেসের কারণে ধীরগতির হয়, ফ্রেমওয়ার্কের কারণে নয়।
যদি SEO এবং সোশ্যাল প্রিভিউ গুরুত্বপূর্ণ হয়, তবে Next.js ব্যবহার করুন। যদি আপনার অ্যাপটি ইন্টারঅ্যাক্টিভ, ডেটা-চালিত এবং লগইন সিস্টেমের পেছনে থাকে, তবে একটি Vite SPA ব্যবহার করুন।
ডিফল্ট অপশনটি ব্যবহার করা বন্ধ করুন। নিজেকে প্রশ্ন করুন আপনি আসলে কী তৈরি করছেন।
উৎস: https://dev.to/moruno21/you-dont-need-nextjs-heres-why-708