Thay Supabase bằng Nhost: GraphQL Backend cho Team Hiện Đại

Thay thế Supabase bằng Nhost: lựa chọn gần giống Supabase cho team thích GraphQL

Supabase → lựa chọn phổ biến khi cần backend nhanh: Postgres, Auth, Storage, Edge Functions, Realtime. Nhưng nếu team thích GraphQL-first, muốn query linh hoạt, schema rõ, permission chi tiết theo role, Nhost đáng cân nhắc.

Nhost giống Supabase ở triết lý: open-source backend platform trên Postgres. Khác biệt lớn: Nhost dùng Hasura GraphQL Engine làm lõi API. Nghĩa là thay vì REST/PostgREST là mặc định như Supabase, Nhost đưa GraphQL lên trung tâm.

Nếu bạn đang xây SaaS, dashboard nội bộ, app mobile, marketplace, CMS tùy biến, hệ thống nhiều quan hệ dữ liệu → Nhost có thể hợp hơn Supabase, đặc biệt khi frontend cần lấy dữ liệu phức tạp nhưng không muốn viết nhiều API thủ công.

Nhost là gì?

– Postgres → DB chính. – Hasura → GraphQL API tự động từ schema DB. – Auth → đăng ký, đăng nhập, JWT, role, social login. – Storage → upload file, quản lý file. – Serverless Functions → logic custom. – CLI + cloud hosting → dev/prod workflow. – Permission layer → quyền truy cập dựa trên role, user, điều kiện DB.

Điểm mạnh nhất: bạn thiết kế bảng trong Postgres → Hasura sinh GraphQL query/mutation/subscription gần như tức thì.

Ví dụ query:

query GetProjects {
  projects {
    id
    name
    tasks {
      id
      title
      done
    }
  }
}

Một request → lấy project + tasks liên quan. Không cần tự viết endpoint /projects/:id/tasks.

Vì sao team Supabase nên nhìn sang Nhost?

Supabase rất mạnh, nhưng mặc định thiên về:

– SQL trực tiếp qua client. – REST API tự sinh qua PostgREST. – Realtime trên Postgres changes. – Edge Functions cho logic thêm.

Nhost lại thiên về:

– GraphQL schema. – Query nested data. – Permission declarative. – Subscription GraphQL. – Hasura metadata/migrations.

Nếu team frontend đã quen Apollo Client, urql, Relay, GraphQL Codegen → Nhost tự nhiên hơn.

Supabase phù hợp khi

– Team thích SQL. – Data model đơn giản/vừa. – Muốn ecosystem lớn. – Cần vector, AI, realtime, edge tốt. – Muốn DX cực nhanh với JS client.

Nhost phù hợp khi

– Team thích GraphQL. – Dữ liệu nhiều quan hệ. – Cần nested query. – Cần role/permission phức tạp. – Muốn auto API nhưng vẫn kiểm soát chặt. – Frontend muốn type-safe GraphQL.

So sánh nhanh: Supabase vs Nhost

| Tiêu chí | Supabase | Nhost | |—|—|—| | DB | Postgres | Postgres | | API chính | REST/PostgREST + JS client | GraphQL qua Hasura | | Auth | Mạnh, phổ biến | Tích hợp Hasura claims | | Storage | Có | Có | | Realtime | Có | GraphQL subscriptions | | Permission | RLS Postgres | Hasura permissions + roles | | DX frontend | Rất tốt | Rất tốt nếu dùng GraphQL | | Learning curve | Dễ hơn | Cần hiểu Hasura | | Open-source | Có | Có | | Best fit | SQL-first app | GraphQL-first app |

Kết luận ngắn: Supabase = Postgres-first developer platform. Nhost = Hasura GraphQL-first backend platform.

Điểm mạnh lớn nhất của Nhost: GraphQL tự động

Với Nhost, khi tạo bảng:

– users – projects – tasks – comments

Hasura đọc schema DB → tạo:

– Query. – Mutation. – Subscription. – Relationship. – Filter. – Sort. – Pagination. – Aggregate.

Ví dụ:

query {
  tasks(
    where: { done: { _eq: false } }
    order_by: { created_at: desc }
    limit: 20
  ) {
    id
    title
    project {
      id
      name
    }
  }
}

Không cần viết controller. Không cần viết route. Không cần join thủ công ở frontend. Hasura chuyển GraphQL → SQL tối ưu tương đối tốt.

Với app nhiều màn hình dashboard, filter, bảng dữ liệu, quan hệ cha-con → tốc độ phát triển rất nhanh.

Auth trong Nhost: hợp với Hasura

Auth của Nhost tạo JWT có custom claims cho Hasura, ví dụ:

– x-hasura-user-id – x-hasura-default-role – x-hasura-allowed-roles

Nhờ đó, Hasura biết user hiện tại là ai, role gì, được xem/sửa dòng nào.

Ví dụ permission:

– User role user chỉ đọc task có user_id = x-hasura-user-id. – Role admin đọc tất cả. – Role manager đọc project thuộc team mình.

Cách này rất mạnh cho multi-tenant SaaS:

– Mỗi user thuộc org. – Mỗi org có project riêng. – Mỗi member có role riêng. – Permission cần áp dụng nhất quán ở DB/API.

Supabase dùng RLS cũng mạnh. Nhưng Nhost/Hasura cho UI cấu hình permission trực quan hơn, dễ thấy rule nào áp dụng cho bảng nào.

Permission: nơi Nhost thật sự đáng giá

Hasura permission hoạt động theo bảng, role, operation:

– select – insert – update – delete

Bạn cấu hình điều kiện:

{
  "user_id": {
    "_eq": "X-Hasura-User-Id"
  }
}

Nghĩa là user chỉ thao tác dữ liệu của chính họ.

Có thể thêm rule phức tạp:

– Theo organization_id. – Theo bảng membership. – Theo trạng thái record. – Theo role trong team. – Theo field-level permission.

Ví dụ user được đọc project nếu là member:

{
  "organization": {
    "members": {
      "user_id": {
        "_eq": "X-Hasura-User-Id"
      }
    }
  }
}

Với GraphQL API public-facing, permission sai → lộ dữ liệu. Nhost/Hasura bắt bạn nghĩ rõ về quyền truy cập từ đầu. Đây là điểm cộng lớn.

Storage và file upload

Nhost Storage tương tự Supabase Storage:

– Upload file. – Bucket. – Public/private access. – Metadata trong Postgres. – Permission theo role. – Tích hợp auth.

Use case:

– Avatar. – Attachment. – Image CMS. – File nội bộ. – Document theo tenant.

Nếu app chỉ cần upload đơn giản, Supabase và Nhost đều ổn. Nếu muốn file metadata truy vấn cùng GraphQL, Nhost tiện hơn vì storage metadata có thể đi qua Hasura.

Serverless Functions: khi GraphQL chưa đủ

Không phải logic nào cũng nên đưa vào DB/GraphQL. Bạn vẫn cần functions cho:

– Thanh toán Stripe. – Webhook. – Gửi email. – Tích hợp bên thứ ba. – Cron/job. – Logic bảo mật cao. – Xử lý file.

Nhost Functions cho phép viết endpoint custom. Kiểu kiến trúc hợp lý:

– CRUD chuẩn → GraphQL. – Permission dữ liệu → Hasura. – Logic nghiệp vụ đặc biệt → Functions. – Background/external integration → Functions/webhook.

Tránh nhồi toàn bộ logic vào frontend hoặc permission rule quá phức tạp.

Migration từ Supabase sang Nhost: cần lưu ý gì?

Nếu đang dùng Supabase, chuyển sang Nhost không phải “1-click”. Cả hai cùng Postgres, nên DB có thể chuyển tương đối thuận, nhưng API/Auth/Storage khác nhau.

1. Database

Dễ nhất nếu schema Postgres sạch:

– Export schema/data từ Supabase. – Import sang Nhost Postgres. – Kiểm tra constraint, index, extension. – Rebuild relationship trong Hasura metadata.

Cẩn thận nếu dùng nhiều Supabase-specific feature.

2. API layer

Supabase client:

supabase.from('tasks').select('*')

Nhost/GraphQL:

query {
  tasks {
    id
    title
  }
}

Frontend phải đổi data fetching layer. Nếu app lớn, nên migration từng module.

3. Auth

Auth user migration thường khó nhất:

– Password hash compatibility. – Social login provider. – JWT claims. – Role mapping. – Session handling.

Nên kiểm tra tài liệu hiện tại, làm staging migration, test đăng nhập kỹ.

4. Permission

Supabase RLS → Hasura permission. Không thể copy nguyên xi. Cần chuyển logic:

– Policy SQL → Hasura rule. – Role → Hasura role. – JWT claim → Hasura claim. – Edge case → test bằng user thật.

5. Storage

File cần migrate:

– Object. – Metadata. – Permission. – Public URL/private access. – Reference trong DB.

Nếu file nhiều, cần script riêng.

Khi nào không nên chọn Nhost?

Nhost không phải lựa chọn mặc định cho mọi team.

Không nên chọn nếu:

– Team không quen GraphQL. – App rất đơn giản, CRUD ít bảng. – Muốn ecosystem plugin/community lớn hơn. – Cần Supabase Edge Functions/Realtime đặc thù. – Muốn RLS thuần Postgres hơn Hasura permission. – Không muốn học Hasura metadata/migration workflow.

GraphQL cũng có trade-off:

– Cache phức tạp hơn REST nếu setup kém. – Permission phải cực chặt. – Query quá linh hoạt có thể gây performance issue. – Team backend truyền thống có thể thấy “ma thuật”.

Nhost mạnh, nhưng cần kỷ luật schema, permission, migration.

Kiến trúc đề xuất với Nhost

Một setup thực tế:

– Postgres → source of truth. – Hasura GraphQL → API chính. – Nhost Auth → user/session/role. – Hasura permissions → row/field access. – Nhost Storage → file. – Functions → payment/email/webhook. – GraphQL Codegen → type-safe frontend. – Apollo/urql → client state/data fetching. – CI migration → kiểm soát schema/metadata.

Nguyên tắc:

– Không expose role admin ra client. – Tắt permission mặc định nếu chưa cần. – Viết index cho field hay filter. – Dùng limit/pagination. – Test permission bằng nhiều role. – Theo dõi slow query.

Kết luận: Nhost là “Supabase cho team GraphQL”?

Có thể nói: đúng, nhưng không hoàn toàn.

Nhost gần Supabase ở tầng sản phẩm: Postgres, Auth, Storage, Functions, open-source, backend nhanh. Nhưng khác triết lý: Nhost đặt GraphQL/Hasura ở trung tâm.

Chọn Nhost nếu team:

– Thích GraphQL. – Cần query dữ liệu quan hệ phức tạp. – Muốn API tự sinh nhưng permission chi tiết. – Xây SaaS nhiều role, nhiều tenant. – Muốn frontend type-safe, ít viết backend CRUD.

Giữ Supabase nếu team:

– Thích SQL/RLS. – Muốn DX đơn giản. – App nhỏ-vừa. – Đã dùng sâu Supabase ecosystem. – Không muốn đổi data fetching layer.

Thực tế nhất: nếu dự án mới, GraphQL-first → thử Nhost sớm. Nếu dự án đang chạy trên Supabase, chỉ migrate khi pain point rõ: REST/query layer khó mở rộng, permission cần quản trị trực quan hơn, frontend GraphQL là ưu tiên chiến lược.