Nuxt 3 + GraphQL Yoga: Membangun BFF Tipe Aman untuk Frontend yang Kompleks

Pada aplikasi frontend yang mulai kompleks, masalah utamanya biasanya bukan lagi sekadar mengambil data lalu menampilkannya. UI perlu menggabungkan data dari beberapa service, menyamakan bentuk respons, menerapkan otorisasi berdasarkan pengguna, mengurangi overfetching, dan menjaga kontrak data tetap konsisten di banyak halaman. Dalam kondisi seperti ini, pola Backend for Frontend (BFF) menjadi sangat relevan.

Artikel ini membahas bagaimana Nuxt 3 + GraphQL Yoga dapat dipakai untuk membangun BFF yang type-safe ketika frontend harus berhadapan dengan banyak REST API. Fokusnya bukan hanya pada cara membuat endpoint GraphQL, tetapi juga pada keputusan arsitektur: kapan GraphQL cocok dipakai, bagaimana merancang schema yang stabil, bagaimana resolver memanggil service downstream dengan aman, bagaimana context autentikasi bekerja, serta bagaimana mengelola batching, caching, error handling, dan integrasi ke composable Nuxt.

Tujuannya sederhana: frontend mendapat kontrak data yang rapi dan stabil, sementara kompleksitas integrasi antar-service dipusatkan di satu layer yang lebih mudah dipelihara.

Mengapa BFF Dibutuhkan di Proyek Nuxt 3 yang Kompleks?

Tanpa BFF, halaman frontend sering langsung memanggil banyak endpoint REST yang berbeda. Dampaknya:

Kontrak data tersebar di banyak komponen dan composable.
Transformasi data berulang karena setiap halaman menormalisasi respons sendiri.
Autentikasi dan otorisasi tidak konsisten antara satu fitur dan fitur lain.
Jumlah request membengkak dan sulit dioptimalkan.
Frontend terlalu tahu detail backend, misalnya nama endpoint, struktur nested, atau perbedaan respons antar-service.

Dengan BFF, Nuxt 3 tidak hanya bertugas sebagai UI, tetapi juga menjadi layer mediasi antara browser dan service downstream. GraphQL kemudian berperan sebagai kontrak tunggal yang lebih ergonomis untuk frontend: klien meminta data sesuai kebutuhan, sementara server BFF yang menangani orkestrasi ke REST service.

Prinsip pentingnya: GraphQL schema sebaiknya merepresentasikan kebutuhan produk dan UI, bukan sekadar menyalin bentuk respons REST yang ada.

Kapan GraphQL Yoga Lebih Tepat Dibanding REST Biasa?

GraphQL tidak selalu harus dipilih. Untuk aplikasi sederhana dengan sedikit endpoint dan kebutuhan data yang stabil, REST biasa sering sudah cukup. Namun GraphQL Yoga menjadi menarik ketika:

Satu halaman perlu menggabungkan data dari banyak service.
Kebutuhan field antar-halaman berbeda-beda dan sering berubah.
Frontend butuh single contract yang konsisten meskipun backend terdiri dari banyak API.
Tim ingin mengadopsi code generation TypeScript agar query dan hasil respons tervalidasi.
Anda butuh kontrol lebih baik terhadap batching, field-level resolver, dan evolusi schema.

Jika kebutuhan utama Anda hanya meneruskan satu endpoint ke satu service tanpa transformasi berarti, GraphQL bisa terasa berlebihan. Tetapi jika Nuxt berperan sebagai REST gateway atau orchestration layer, GraphQL memberikan nilai yang jauh lebih jelas.

Gambaran Arsitektur

Secara konseptual, arsitekturnya dapat dibagi menjadi empat lapisan:

Client Nuxt: halaman, komponen, dan composable yang mengirim query atau mutation GraphQL.
GraphQL Yoga handler: endpoint GraphQL di sisi server Nuxt.
Resolver layer: logika untuk membaca context, memanggil service, memetakan data, dan menangani error.
Downstream services: REST API internal, service pihak ketiga, atau backend lama yang belum seragam.

Dengan model ini, browser tidak perlu mengetahui detail banyak endpoint di belakang layar. Browser hanya mengetahui satu endpoint GraphQL yang stabil.

Alur request secara ringkas

Pengguna membuka halaman Nuxt.
Composable menjalankan query GraphQL ke endpoint server.
GraphQL Yoga membuat context berdasarkan request masuk, misalnya token, user ID, locale, atau tenant.
Resolver memanggil satu atau lebih REST service.
Resolver menormalkan data menjadi bentuk schema GraphQL.
Client menerima data yang sudah terstruktur sesuai field yang diminta.

Struktur Direktori yang Masuk Akal

Struktur proyek dapat bervariasi, tetapi pola berikut cukup mudah dipelihara:

.
├── server
│   ├── api
│   │   └── graphql.ts
│   └── graphql
│       ├── schema
│       │   └── typeDefs.ts
│       ├── resolvers
│       │   ├── query.ts
│       │   ├── mutation.ts
│       │   ├── user.ts
│       │   └── order.ts
│       ├── context.ts
│       ├── dataloaders
│       │   └── userLoader.ts
│       ├── services
│       │   ├── users.ts
│       │   └── orders.ts
│       └── utils
│           ├── errors.ts
│           └── cache.ts
├── composables
│   ├── useGraphqlQuery.ts
│   └── useGraphqlMutation.ts
├── graphql
│   ├── queries
│   │   ├── dashboard.gql
│   │   └── user-profile.gql
│   └── mutations
│       └── update-profile.gql
└── generated
    └── graphql.ts

Pemisahan ini membantu menjaga tanggung jawab tetap jelas:

schema untuk definisi kontrak GraphQL,
resolvers untuk pemetaan field dan orkestrasi,
services untuk integrasi REST,
dataloaders untuk batching,
generated untuk tipe hasil codegen.

Menyiapkan Endpoint GraphQL Yoga di Nuxt 3

Di Nuxt 3, endpoint GraphQL umumnya ditempatkan di area server route. Intinya adalah membuat handler GraphQL Yoga lalu mengekspornya sebagai endpoint server.

import { createYoga, createSchema } from 'graphql-yoga'
import { typeDefs } from '../graphql/schema/typeDefs'
import { resolvers } from '../graphql/resolvers'
import { createGraphqlContext } from '../graphql/context'

const yoga = createYoga({
  schema: createSchema({
    typeDefs,
    resolvers
  }),
  context: async ({ request }) => {
    return createGraphqlContext(request)
  },
  graphqlEndpoint: '/api/graphql'
})

export default defineEventHandler(async (event) => {
  return yoga.handleNodeRequest(event.node.req, {
    req: event.node.req,
    res: event.node.res
  })
})

Contoh di atas bersifat konseptual. Implementasi detail bisa sedikit berbeda tergantung adapter runtime yang dipakai. Yang penting, pisahkan pembuatan schema, resolver, dan context agar endpoint tetap tipis.

Merancang Schema GraphQL yang Baik

Kesalahan umum saat membangun BFF GraphQL adalah menjadikan schema sebagai cermin mentah dari API REST yang ada. Hasilnya, GraphQL hanya menjadi lapisan pembungkus tanpa manfaat nyata. Sebaiknya schema dirancang berdasarkan kebutuhan domain dan kebutuhan layar frontend.

Contoh schema

export const typeDefs = /* GraphQL */ `
  type Query {
    me: User
    dashboard: Dashboard!
    order(id: ID!): Order
  }

  type Mutation {
    updateProfile(input: UpdateProfileInput!): UpdateProfilePayload!
  }

  type User {
    id: ID!
    name: String!
    email: String!
    role: String
    profile: UserProfile
  }

  type UserProfile {
    avatarUrl: String
    phone: String
  }

  type Order {
    id: ID!
    status: String!
    total: Float!
    customer: User!
  }

  type Dashboard {
    user: User!
    recentOrders: [Order!]!
    notifications: [Notification!]!
  }

  type Notification {
    id: ID!
    title: String!
    read: Boolean!
  }

  input UpdateProfileInput {
    name: String!
    phone: String
  }

  type UpdateProfilePayload {
    success: Boolean!
    message: String
    user: User
  }
`

Beberapa prinsip penting saat mendesain schema:

Gunakan nama yang konsisten dengan domain, bukan nama endpoint downstream.
Sembunyikan detail backend internal seperti field yang sebenarnya hanya relevan untuk service tertentu.
Stabilkan bentuk respons agar perubahan di REST API tidak langsung memecahkan frontend.
Hindari field yang ambigu; lebih baik eksplisit daripada terlalu generik.
Pikirkan evolusi schema; GraphQL cocok untuk penambahan field, tetapi penghapusan field perlu strategi deprecation.

Membangun Context untuk Auth, Tenant, dan Metadata Request

Context adalah fondasi penting pada GraphQL Yoga karena hampir semua resolver akan membutuhkannya. Biasanya context memuat:

informasi pengguna yang sedang login,
token akses atau cookie sesi,
tenant atau organisasi aktif,
locale, timezone, atau preferensi lain,
service client untuk memanggil REST API,
instance DataLoader, logger, dan cache helper.

type GraphqlContext = {
  user: { id: string; role?: string } | null
  accessToken: string | null
  services: {
    users: ReturnType<typeof createUsersService>
    orders: ReturnType<typeof createOrdersService>
  }
  loaders: {
    userById: ReturnType<typeof createUserByIdLoader>
  }
}

export async function createGraphqlContext(request: Request): Promise<GraphqlContext> {
  const accessToken = request.headers.get('authorization')?.replace('Bearer ', '') ?? null

  const user = accessToken
    ? await resolveUserFromToken(accessToken)
    : null

  return {
    user,
    accessToken,
    services: {
      users: createUsersService({ accessToken }),
      orders: createOrdersService({ accessToken })
    },
    loaders: {
      userById: createUserByIdLoader({ accessToken })
    }
  }
}

Praktik yang baik adalah jangan memasukkan logika bisnis berlebihan ke pembuatan context. Context sebaiknya bertugas menyiapkan dependensi per-request, bukan menjalankan orkestrasi besar.

Resolver: Tempat BFF Memberi Nilai Nyata

Resolver adalah titik di mana BFF benar-benar bekerja. Di sinilah Anda:

menggabungkan beberapa service,
memetakan field dari REST menjadi shape GraphQL,
menegakkan auth atau permission,
menerapkan fallback jika service tertentu bermasalah,
mengubah error teknis menjadi error yang lebih bermakna untuk client.

Contoh resolver query

export const resolvers = {
  Query: {
    me: async (_parent: unknown, _args: unknown, ctx: GraphqlContext) => {
      if (!ctx.user) return null
      return ctx.services.users.getMe()
    },

    dashboard: async (_parent: unknown, _args: unknown, ctx: GraphqlContext) => {
      if (!ctx.user) {
        throw new Error('UNAUTHENTICATED')
      }

      const [user, recentOrders, notifications] = await Promise.all([
        ctx.services.users.getById(ctx.user.id),
        ctx.services.orders.getRecentOrders(ctx.user.id),
        ctx.services.users.getNotifications(ctx.user.id)
      ])

      return {
        user,
        recentOrders,
        notifications
      }
    }
  },

  Order: {
    customer: async (order: { customerId: string }, _args: unknown, ctx: GraphqlContext) => {
      return ctx.loaders.userById.load(order.customerId)
    }
  }
}

Contoh di atas menunjukkan dua hal penting:

Resolver root seperti dashboard cocok untuk orkestrasi multi-service.
Resolver field seperti Order.customer cocok memakai DataLoader untuk menghindari masalah N+1.

Lapisan Service: Jangan Panggil REST Langsung dari Semua Resolver

Walau secara teknis resolver bisa langsung memakai fetch, praktik ini cepat membuat kode sulit diuji dan sulit dipelihara. Lebih baik siapkan lapisan service khusus.

export function createUsersService({ accessToken }: { accessToken: string | null }) {
  const headers = accessToken
    ? { Authorization: `Bearer ${accessToken}` }
    : {}

  return {
    async getMe() {
      return $fetch('/users/me', { baseURL: 'https://api.internal.local', headers })
    },
    async getById(id: string) {
      return $fetch(`/users/${id}`, { baseURL: 'https://api.internal.local', headers })
    },
    async getNotifications(userId: string) {
      return $fetch(`/users/${userId}/notifications`, { baseURL: 'https://api.internal.local', headers })
    }
  }
}

Keuntungan pendekatan ini:

konfigurasi header dan base URL tidak berulang,
mocking lebih mudah saat testing,
mapping error bisa dipusatkan,
perubahan endpoint downstream tidak menyebar ke semua resolver.

Auth dan Otorisasi: Validasi di Tempat yang Tepat

Banyak implementasi awal hanya memeriksa apakah user login atau tidak. Padahal pada BFF, kebutuhan otorisasi sering lebih rinci:

apakah user boleh mengakses data tenant tertentu,
apakah role tertentu boleh menjalankan mutation,
apakah field sensitif boleh ditampilkan untuk pengguna ini.

Pola yang umum adalah membuat helper otorisasi agar resolver lebih ringkas.

function requireUser(ctx: GraphqlContext) {
  if (!ctx.user) {
    throw new Error('UNAUTHENTICATED')
  }
  return ctx.user
}

function requireRole(ctx: GraphqlContext, roles: string[]) {
  const user = requireUser(ctx)
  if (!user.role || !roles.includes(user.role)) {
    throw new Error('FORBIDDEN')
  }
  return user
}

Yang perlu diingat: BFF bukan pengganti otorisasi di service utama. Jika service downstream sudah memiliki validasi izin, tetap pertahankan. BFF sebaiknya menambah lapisan proteksi dan konsistensi, bukan menjadi satu-satunya penjaga.

Error Handling yang Konsisten dan Aman

Error handling adalah area yang sering diabaikan. Tanpa strategi yang jelas, client akan menerima campuran pesan error mentah dari berbagai service, yang sulit dipakai untuk UX dan berisiko membocorkan detail internal.

Strategi yang lebih baik:

Normalisasi error downstream menjadi kategori yang konsisten.
Pisahkan error teknis dan error bisnis.
Jangan bocorkan detail internal seperti stack trace atau URL service ke client.
Log detail lengkap di server, tampilkan pesan yang aman di response.

class AppError extends Error {
  constructor(
    message: string,
    public code: string,
    public status?: number
  ) {
    super(message)
  }
}

function mapServiceError(error: unknown): never {
  if (isNotFoundError(error)) {
    throw new AppError('Data tidak ditemukan', 'NOT_FOUND', 404)
  }

  if (isUnauthorizedError(error)) {
    throw new AppError('Akses ditolak', 'FORBIDDEN', 403)
  }

  throw new AppError('Terjadi kesalahan pada layanan', 'UPSTREAM_ERROR', 502)
}

Untuk mutation, sering kali berguna mengembalikan payload yang eksplisit, misalnya success, message, dan user, terutama jika UX perlu menampilkan status yang mudah dibaca. Namun untuk error sistemik seperti autentikasi gagal, melempar error tetap lebih tepat.

Menghindari N+1 Query dengan DataLoader

Salah satu jebakan paling umum di GraphQL adalah masalah N+1. Misalnya, query mengambil 20 order, lalu setiap field customer memicu request user terpisah. Akibatnya, satu query GraphQL bisa berubah menjadi puluhan request downstream.

Di sinilah DataLoader berguna. DataLoader menggabungkan permintaan item yang sama dalam satu batch per request, lalu meng-cache hasilnya selama siklus request tersebut.

import DataLoader from 'dataloader'

export function createUserByIdLoader({ accessToken }: { accessToken: string | null }) {
  return new DataLoader<string, any>(async (userIds) => {
    const users = await $fetch('/users/batch', {
      baseURL: 'https://api.internal.local',
      method: 'POST',
      headers: accessToken ? { Authorization: `Bearer ${accessToken}` } : {},
      body: { ids: userIds }
    })

    const map = new Map(users.map((user: any) => [user.id, user]))
    return userIds.map((id) => map.get(id) ?? null)
  })
}

Best practice penting:

Buat instance DataLoader per request, bukan global.
Gunakan untuk akses data by-id atau pola lookup yang sering berulang.
Jangan memaksa semua query lewat DataLoader jika tidak memberi manfaat nyata.

Caching: Request Scope, Application Scope, dan HTTP Cache

Caching pada BFF tidak cukup dipahami sebagai satu mekanisme tunggal. Ada beberapa level cache yang biasanya relevan:

1. Cache per request

Ini adalah cache paling aman dan paling umum, biasanya otomatis terbantu oleh DataLoader. Cocok untuk mencegah request duplikat dalam satu eksekusi query.

2. Cache aplikasi

Untuk data yang relatif stabil, Anda bisa memakai cache in-memory atau cache terpisah. Namun hati-hati dengan:

staleness data,
invalidasi setelah mutation,
perbedaan perilaku pada environment serverless atau multi-instance.

3. Cache dari service downstream

Jika REST service sudah memiliki ETag, cache-control, atau reverse proxy cache, manfaatkan mekanisme tersebut. BFF tidak harus selalu menggantikan strategi cache yang sudah ada.

Prinsipnya, jangan menambahkan cache global terlalu cepat sebelum memahami pola akses data dan konsekuensi invalidasinya.

Query Composition: Kekuatan Utama untuk Halaman Kompleks

GraphQL sangat berguna ketika satu halaman membutuhkan gabungan data yang sebelumnya tersebar di banyak endpoint. Misalnya halaman dashboard:

query DashboardPage {
  dashboard {
    user {
      id
      name
      email
    }
    recentOrders {
      id
      status
      total
      customer {
        id
        name
      }
    }
    notifications {
      id
      title
      read
    }
  }
}

Keuntungan praktisnya:

frontend hanya mengelola satu query,
shape data yang diterima sesuai kebutuhan UI,
kompleksitas gabungan multi-service dipindah ke BFF.

Namun jangan sampai query root menjadi terlalu gemuk dan spesifik untuk satu halaman saja. Jika terlalu banyak field yang hanya berguna pada satu layar, pertimbangkan desain ulang agar domain tetap jelas.

Integrasi ke Composable Nuxt

Agar ergonomis di sisi frontend, siapkan composable tipis untuk mengirim query dan mutation ke endpoint GraphQL. Anda bisa memakai $fetch atau client GraphQL lain sesuai kebutuhan proyek. Untuk BFF sederhana, $fetch sering sudah memadai.

type GraphqlResponse<T> = {
  data?: T
  errors?: Array<{ message: string }>
}

export async function useGraphqlQuery<T>(query: string, variables?: Record<string, unknown>) {
  const response = await $fetch<GraphqlResponse<T>>('/api/graphql', {
    method: 'POST',
    body: {
      query,
      variables
    }
  })

  if (response.errors?.length) {
    throw new Error(response.errors[0].message)
  }

  return response.data as T
}

Contoh pemakaian di halaman atau composable lain:

const dashboardQuery = `
  query DashboardPage {
    dashboard {
      user {
        id
        name
      }
      recentOrders {
        id
        status
        total
      }
    }
  }
`

const data = await useGraphqlQuery<{
  dashboard: {
    user: { id: string; name: string }
    recentOrders: Array<{ id: string; status: string; total: number }>
  }
}>(dashboardQuery)

Jika aplikasi sudah besar, pertimbangkan abstraksi tambahan seperti:

penanganan auth header otomatis,
retry untuk error tertentu,
typed document node hasil codegen,
integrasi dengan state management atau cache client-side.

Code Generation TypeScript untuk Type Safety End-to-End

Nilai terbesar GraphQL pada stack TypeScript muncul ketika Anda tidak menulis tipe secara manual. Dengan code generation, tipe hasil query dan variabel bisa dihasilkan langsung dari schema dan dokumen GraphQL.

Manfaatnya:

mengurangi mismatch antara query dan tipe di frontend,
autocomplete field lebih akurat,
perubahan schema lebih cepat terdeteksi saat build,
refactor query menjadi lebih aman.

Alur umumnya:

Definisikan schema GraphQL di server BFF.
Simpan query/mutation dalam file terpisah.
Jalankan codegen untuk menghasilkan tipe TypeScript.
Pakai tipe hasil generate di composable atau komponen.

Karena detail konfigurasi codegen dapat berbeda tergantung tool dan kebutuhan proyek, fokuskan implementasi pada tiga hal:

sumber schema jelas,
dokumen query tersusun rapi,
hasil generate masuk ke alur build atau CI.

Jika target utama Anda adalah keamanan tipe, jangan campur terlalu banyak query inline di komponen. Simpan dokumen GraphQL secara terstruktur agar codegen dan review perubahan lebih mudah.

Mutation: Validasi Input dan Dampaknya ke Cache

Mutation pada BFF sebaiknya tidak hanya meneruskan input mentah ke backend. Lakukan validasi dasar, sanitasi seperlunya, dan pastikan respons mutation punya bentuk yang konsisten.

export const resolvers = {
  Mutation: {
    updateProfile: async (
      _parent: unknown,
      args: { input: { name: string; phone?: string } },
      ctx: GraphqlContext
    ) => {
      const user = requireUser(ctx)

      const updatedUser = await ctx.services.users.updateProfile(user.id, args.input)

      return {
        success: true,
        message: 'Profil berhasil diperbarui',
        user: updatedUser
      }
    }
  }
}

Setelah mutation, pikirkan juga dampaknya:

apakah cache per request masih relevan,
apakah client perlu re-fetch query tertentu,
apakah data turunan lain juga berubah.

Masalah invalidasi sering lebih sulit daripada menambahkan cache itu sendiri. Karena itu, mulai dari strategi yang sederhana dan eksplisit biasanya lebih aman.

Observability dan Debugging

Semakin banyak service yang diorkestrasi, semakin penting observability. Tanpa logging dan tracing yang memadai, GraphQL bisa terasa seperti “kotak hitam” ketika satu field gagal di tengah query yang besar.

Minimum yang sebaiknya ada:

request ID untuk setiap request masuk,
logging per downstream call beserta durasi,
error log terstruktur yang menyertakan operasi GraphQL,
monitoring latency untuk query yang sering dipakai.

Saat debugging, perhatikan tiga area berikut:

Schema mismatch: field yang diminta client tidak sesuai dengan schema atau respons resolver.
N+1 issue: query terlihat normal, tetapi downstream call melonjak.
Permission leak: field tertentu lolos ditampilkan karena validasi auth hanya ada di root resolver.

Trade-off yang Perlu Dipahami

Meskipun kuat, pendekatan ini tetap punya biaya:

Lapisan tambahan berarti lebih banyak kode untuk dipelihara.
Schema design membutuhkan disiplin agar tidak menjadi dumping ground semua kebutuhan halaman.
Debugging bisa lebih kompleks karena melibatkan GraphQL dan service downstream.
Caching dan invalidasi perlu dipikirkan lebih matang daripada API sederhana.

Karena itu, jangan memakai GraphQL hanya karena terdengar modern. Gunakan saat ia benar-benar menyederhanakan konsumsi data di frontend dan menurunkan coupling terhadap backend yang beragam.

Pola Implementasi yang Direkomendasikan

Jika Anda ingin memulai secara bertahap, pola berikut cukup aman:

Buat endpoint GraphQL Yoga tunggal di Nuxt server.
Mulai dari beberapa query yang benar-benar kompleks dan multi-service.
Pisahkan service client dari resolver sejak awal.
Tambahkan auth context dan helper otorisasi.
Pasang DataLoader hanya di area yang jelas mengalami N+1.
Normalisasi error agar kontrak ke frontend konsisten.
Masukkan code generation TypeScript ke workflow build.
Tambahkan logging dan monitoring sebelum skala penggunaan membesar.

Pendekatan bertahap ini membantu tim mengadopsi GraphQL sebagai BFF tanpa harus memigrasikan seluruh aliran data sekaligus.

Kapan Pendekatan Ini Sangat Cocok?

Nuxt 3 + GraphQL Yoga sebagai BFF sangat cocok jika:

frontend Anda melayani banyak layar dengan kebutuhan data yang berbeda-beda,
sumber data berasal dari beberapa REST service,
tim ingin kontrak data yang stabil dan type-safe,
Anda perlu tempat sentral untuk auth, mapping, dan orkestrasi.

Sebaliknya, jika aplikasi masih kecil, service sedikit, dan kebutuhan data tidak kompleks, solusi ini mungkin terlalu berat.

Penutup

Membangun BFF di Nuxt 3 dengan GraphQL Yoga bukan sekadar menambahkan endpoint GraphQL di atas REST. Nilai utamanya ada pada penyederhanaan kontrak data untuk frontend, isolasi kompleksitas integrasi service, dan type safety yang lebih kuat melalui schema serta code generation TypeScript.

Jika dirancang dengan baik, pola ini membantu tim frontend bergerak lebih cepat tanpa terus-menerus bernegosiasi dengan perbedaan bentuk data dari banyak service. Kuncinya adalah disiplin pada desain schema, pemisahan resolver dan service, auth context yang rapi, error handling yang konsisten, serta optimasi yang dilakukan berdasarkan kebutuhan nyata, bukan asumsi.

Dengan fondasi tersebut, Nuxt 3 dapat berfungsi bukan hanya sebagai framework UI, tetapi juga sebagai backend for frontend yang kuat, terstruktur, dan aman untuk aplikasi modern yang semakin kompleks.

Quick Search

shopping_cart Keranjang