← Quay lại mặt cắt 02ENVITRI.DEV · SECTION A–A

A-102 · Case study · Mặt cắt 02

EngiHire (Engilink)

Nền tảng tuyển dụng ba bên cho thị trường Nhật Bản

Sơ đồ vị trí · mặt cắt 02 / 8

Đọc nhanh trong 30 giây

Vai trò
Full-stack — FE Architecture dạng monorepo + REST API endpoint & JWT auth ở BE
Giao diện
Agency portal · Manager portal · Visitor portal
Thời gian
≈ 2025–2026 · khoảng 1 năm
Stack
Vue 3 · TypeScript · Feature-Sliced Design · Pinia · TanStack Query · Turborepo · pnpm workspaces · Element Plus · Vite · NestJS · MongoDB · JWT · REST API
Liên kết

Vấn đề

Một nền tảng tuyển dụng ba bên cho thị trường Nhật Bản: agency, công ty và ứng viên, mỗi bên cần một portal riêng trên cùng một sản phẩm.

Ràng buộc

  • Ba portal theo vai trò — agency, manager và visitor
  • Frontend Architecture và backend endpoint do cùng một vị trí đảm nhận
  • Authentication dựa trên token, dùng access token và refresh token

Mặt cắt 02 · vị trí các quyết định

Mặt cắt qua EngiHire (Engilink): từng tầng dự án chạm tới, các thành phần trên mỗi tầng và các tag quyết định D1 đến D4.
  1. D1

    Một monorepo cho ba portal

    Các portal và package dùng chung nằm trong cùng một Turborepo + pnpm workspace.

    Trade-off Một workspace đồng nghĩa với một build pipeline cần giữ cho nhanh, cùng những package dùng chung mà mọi portal đều phụ thuộc. Đổi lại, một bản fix trong package dùng chung đến được cả ba portal agency, manager và visitor cùng lúc, không phải copy code.

  2. D2

    Feature-Sliced Design

    Một quy ước chia layer chung cho codebase của mọi portal.

    Trade-off Feature-Sliced Design đòi hỏi kỷ luật về layer và import, cần thời gian để làm quen. Đổi lại, ba portal có chung một cấu trúc, nên developer chuyển qua lại giữa các portal vẫn tìm thấy code ở cùng một chỗ.

  3. D3

    REST endpoint với NestJS

    Xây dựng và bảo trì API endpoint với NestJS và MongoDB.

    Trade-off NestJS thêm cấu trúc — module, provider, decorator — mà một server tối giản không cần tới. Đổi lại, mọi endpoint theo cùng một pattern, viết bằng cùng TypeScript với các portal.

  4. D4

    Auth bằng access / refresh token

    Các luồng JWT authentication được xây dựng ở backend.

    Trade-off Access token có thời hạn ngắn nên các portal phải refresh session ngầm và xử lý khi token hết hạn. Đổi lại, một access token bị lộ chỉ dùng được trong thời gian ngắn, còn người dùng vẫn giữ được đăng nhập.