බහු-කිරුනු SaaS පද්ධති නිර්මාණය කරන විට, පළමුවෙන්ම ගැටළුව වන්නේ කුමන ක්රමයෙන් පාරිභෝගික (tenant) දත්ත වෙන් කරගන්නද යන්නයි. සාමාන්යයෙන් වෙන් වුණු දත්ත ගබඩා, හෝ එකම දත්ත ගබඩාව තුළ පේළි මට්ටමේ සීමා කිරීම වැනි විකල්ප තිබේ, නමුත් API‑යෙහි පාරිභෝගික කාලය (tenant context) හඳුනාගැනීමට අවශ්ය ක්රමය අඩුවෙන්ම සාකච්ඡා වේ.
මෙම ලිපියේදී අපි නිෂ්පාදනයේ භාවිතා කරන x-tenant-id නමැති අභිරුචි HTTP හෙඩර් පදනමෙන් tenant‑කාරකය හඳුනාගැනීමේ රටාව විස්තර කරමු. මෙය JWT පරීක්ෂණය සමඟ එක් කරමින්, සරල, පරීක්ෂා කළ හැකි, සහ එක් පරිශීලක ගිණුමකින් බහු‑tenant ප්රවේශය ලබා දීමට හැකිවීමේ වාසි ඇත.
සාමාන්යව භාවිතා වන තුන් ක්රම
- Subdomain‑පදනම – tenant.yourdomain.com ලෙස උප-ඩොමේන් නාමය භාවිතා කිරීම. URL එකේ පාරිභෝගිකයා පෙනෙයි, නමුත් wildcard TLS සහ DNS සැකසුම අවශ්ය වේ.
- URL‑පථය – /api/tenants/{tenantId}/... ලෙස පථයේ tenant‑අංකය ඇතුළත් කිරීම. RESTful වුවද, සියලු රූට් වලට පථය එකතු කිරීමෙන් සංකීර්ණතාවය වැඩිවේ.
- Header‑පදනම – x-tenant-id හෙඩර් එකෙන් tenant‑අංකය යැවීම. රූට් පථය සරළව තබා, මධ්යම මෘදුකාංග (middleware) තුළ tenant‑සීමාව පරීක්ෂා කරයි.
අපි Header‑පදනම තෝරාගැනීමේ ප්රධාන හේතු වන්නේ රූට් පථය අඩු කිරීම, JWT සමඟ ඒකාබද්ධ කිරීමේ පහසුව, සහ මධ්යම මෘදුකාංගයේ ඒකාකාරී පාලනයයි.
ක්රියාත්මක කිරීමේ විස්තර
API දෙකේම සත්යාපනයක් ඇත:
- Authorization හෙඩර් තුළ JWT – ඉල්ලීම කරන පරිශීලකයා කවුද කියා හඳුනාගනී.
- x-tenant-id හෙඩර් – එම පරිශීලකයා කුමන tenant නමින් ක්රියා කරන්නේද කියා පෙන්වයි.
මුලින් JWT පරීක්ෂා කරන requireAuth middleware එක ක්රියාත්මක වේ. එය සාර්ථක නම්, පරිශීලකයාගේ payload එක req.user වෙත සුරකින්නෙයි. දෙවන middleware වන requireTenantContext හෙඩර් එකෙන් tenant‑අංකය ගෙන, එම පරිශීලකයාට ඒ tenant‑යට ප්රවේශය තිබේදැයි membership වගුවේ පරීක්ෂා කරයි. පරීක්ෂාව සාර්ථක නම් req.tenantId සහ req.role සකසා, ඉදිරි රූට් හඳුනාගැනීමේ ලොජික් එකට භාවිතා කරයි.
රූට් ලියාපදිංචි කිරීමේදී tenant‑අවශ්ය රූට් (members, invoices, settings) සඳහා දෙකම middleware එක් කරයි. එමඟින් නව රූට් එකක් එක් කළාම ස්වයංක්රීයව tenant‑පරිපාලනය ලබා ගනී.
ශ්රී ලංකාවට ඇති වැදගත්කම
ශ්රී ලංකාවේ තාක්ෂණික ආරම්භකයන් සහ සංවර්ධකයන්ට මෙම රටාව බහු‑tenant SaaS නිර්මාණය කිරීමේ වැදගත් පියවරක් වේ. ප්රධාන වාසි කිහිපයක්:
- වියදම් අඩු කිරීම – එක් දත්ත ගබඩාව භාවිතා කරමින්, වෙන් වූ DB අවශ්ය නොවේ.
- ඉක්මන් සංවර්ධනය – middleware එකක් තුළ tenant‑සීමාව පාලනය කිරීම නිසා, රූට් ලේඛන සරලයි.
- ආරක්ෂණය – JWT සහ header පරීක්ෂණය එක්ක, පරිශීලකයාට අනුමත tenant පමණක් පරිශීලනය කළ හැක.
- ඉදිරි අභ්යන්තර විකසනය – එකම ගිණුමෙන් බහු‑tenant ප්රවේශය ලබා දීම නිසා, B2B SaaS ව්යාපාරික මොඩලය ඉතා සරල වේ.
ඉතින්, ශ්රී ලංකාවේ තරුණ සංවර්ධකයන්ට මේ රටාව ඉගෙනගැනීම, ස්ථානයීය SaaS නිෂ්පාදනවල තත්ත්වය ඉහළ දැමීමට, සහ ග්ලෝබල් වෙළඳපලට තක්සේරුකාරී API සැලසුම් ලබා දීමට උපකාරී වේ.
අවසානයේ, x-tenant-id හෙඩර් පදනමෙන් tenant‑පරිපාලනය කරණ API සැලසුම, සංකීර්ණතාවය අඩු කරමින්, ආරක්ෂාව සහ සවිස්තරාත්මක පරිපාලනය සපයයි. ඔබේ SaaS ව්යාපෘතියේ මෙම රටාව අනුගමනය කර, ඉදිරි පරීක්ෂණයට සූදානම් වන්න.
