Ketika bisnis ingin menambahkan kemampuan AI ke aplikasi, tim biasanya menghadapi dua pilihan arsitektur: menghubungkan aplikasi langsung ke setiap provider atau memakai API aggregator sebagai satu lapisan akses. Keduanya dapat mengirim permintaan ke model AI, tetapi kebutuhan integrasi, pemeliharaan, pengendalian biaya, dan tata kelolanya berbeda.
API langsung memberi hubungan paling dekat dengan provider dan akses cepat ke fitur yang baru dirilis. Sebaliknya, API aggregator menyatukan akses ke beberapa model melalui antarmuka yang lebih konsisten. Nilai aggregator biasanya muncul ketika perusahaan perlu bereksperimen dengan banyak model, mengganti model tanpa perubahan besar, atau mengurangi pekerjaan administratif dari banyak akun dan tagihan.
Pilihan yang lebih efisien tidak hanya ditentukan oleh harga per token. Perusahaan perlu menghitung total biaya kepemilikan, termasuk waktu engineering, pengelolaan kredensial, observability, penanganan kegagalan, proses keuangan, dan risiko ketergantungan pada satu provider. Pada sebagian organisasi, pendekatan hybrid yang menggabungkan keduanya justru memberikan hasil paling seimbang.
Jawaban Singkat API Aggregator vs API Langsung
API langsung lebih sesuai ketika aplikasi sangat bergantung pada fitur khusus satu provider, memerlukan kontrol konfigurasi paling rinci, dan tim siap mengelola integrasi tersebut secara mandiri. API aggregator lebih sesuai ketika bisnis membutuhkan akses ke beberapa model, ingin menyederhanakan integrasi, atau memerlukan satu lapisan untuk routing, pemantauan, dan pengendalian penggunaan.
Untuk eksperimen, produk multi-model, dan organisasi dengan banyak tim pengguna AI, aggregator sering mengurangi pekerjaan operasional. Untuk workload inti yang sudah stabil dan memakai kemampuan eksklusif provider tertentu, koneksi langsung dapat memberikan kontrol teknis lebih dalam. Karena itu, keputusan yang baik dimulai dari karakter workload, bukan dari asumsi bahwa satu pendekatan selalu unggul.
| Aspek | API Langsung | API Aggregator |
| Integrasi awal | Terpisah untuk setiap provider | Satu antarmuka untuk beberapa provider |
| Fitur khusus | Biasanya tersedia paling lengkap | Bergantung pada cakupan aggregator |
| Pergantian model | Memerlukan adaptasi kode dan pengujian | Umumnya lebih sederhana melalui lapisan abstraksi |
| Kredensial | Banyak API key dan kebijakan akses | Dapat dikelola melalui satu lapisan |
| Tagihan | Terpisah menurut provider dan mata uang | Berpotensi dikonsolidasikan |
| Observability | Perlu disatukan oleh tim sendiri | Dapat tersedia secara terpusat |
| Reliability | Tim membangun fallback sendiri | Dapat mendukung routing atau fallback terkelola |
| Kontrol teknis | Sangat rinci pada satu provider | Lebih konsisten lintas provider |
Apa Itu API Langsung
API langsung adalah koneksi yang dibuat aplikasi ke endpoint resmi milik satu provider AI. Tim membuat akun pada provider tersebut, memperoleh API key, mempelajari dokumentasinya, memilih model, lalu mengirim request sesuai format yang ditentukan. Respons, error code, mekanisme streaming, batas penggunaan, dan fitur tambahan mengikuti kontrak API provider itu.
Pendekatan ini memberi akses paling dekat ke kemampuan provider. Ketika provider merilis parameter baru, modality baru, tool calling, batch processing, atau fitur optimasi tertentu, integrasi langsung biasanya menjadi jalur pertama yang mendukungnya. Tim juga dapat menyesuaikan timeout, retry, caching, dan konfigurasi model berdasarkan karakter API yang digunakan.
Konsekuensinya, setiap provider menjadi satu integrasi yang harus dikelola. Jika aplikasi menggunakan tiga provider, tim mungkin perlu memelihara tiga SDK, tiga format request, tiga skema error, beberapa API key, serta tiga sumber dokumentasi. Beban ini mungkin kecil pada tahap awal, tetapi bertambah ketika jumlah model, aplikasi, lingkungan deployment, dan pengguna internal meningkat.
Apa Itu API Aggregator
API aggregator adalah lapisan perantara yang menyediakan satu jalur akses ke model dari beberapa provider. Aplikasi mengirim request ke endpoint aggregator, lalu lapisan tersebut meneruskan request ke model yang dipilih. Agar pengalaman integrasi lebih konsisten, aggregator biasanya menyelaraskan sebagian format request, autentikasi, respons, error, dan pencatatan penggunaan.
Lapisan ini dapat memisahkan aplikasi dari detail implementasi provider. Developer masih menentukan model dan parameter yang dibutuhkan, tetapi tidak perlu membangun konektor dasar dari awal untuk setiap penyedia. Model baru dapat ditambahkan melalui antarmuka yang sama selama kapabilitasnya didukung oleh aggregator.
API aggregator sering berjalan bersama fungsi AI API gateway, seperti autentikasi, routing, pencatatan konsumsi, pembatasan akses, dan fallback. Namun, istilah aggregator menekankan penggabungan akses ke banyak provider, sedangkan gateway menekankan lapisan kontrol yang memproses dan mengatur lalu lintas API.
Perbedaan Utama API Aggregator dan API Langsung
Perbandingan yang berguna perlu melihat seluruh siklus hidup integrasi. Biaya implementasi tidak berhenti ketika request pertama berhasil. Sistem harus dipantau, diperbarui, diamankan, diuji ulang, dan disesuaikan ketika provider mengubah model atau kontrak API.
Kecepatan Integrasi dan Pemeliharaan
Pada API langsung, developer mengikuti dokumentasi, SDK, dan pola autentikasi masing-masing provider. Integrasi pertama dapat terasa sederhana, tetapi model kedua dan ketiga menambah cabang kode. Tim perlu membuat adapter, menyamakan format respons, menerjemahkan error, dan menjaga versi library tetap kompatibel.
Aggregator mengurangi variasi itu melalui satu kontrak integrasi. Jika lapisan abstraksinya dirancang dengan baik, aplikasi dapat berpindah model dengan mengubah konfigurasi atau identifier model. Penghematan terbesar bukan pada jumlah baris kode awal, melainkan pada berkurangnya pekerjaan berulang saat menambah model, memperbarui SDK, dan melakukan pengujian regresi.
Meski demikian, developer tetap perlu memahami perbedaan kemampuan model. Parameter yang serupa belum tentu menghasilkan perilaku identik. Integrasi yang konsisten menyederhanakan transport dan autentikasi, tetapi tidak menghapus kebutuhan untuk menguji kualitas, latency, batas konteks, dan pola error setiap model.
Akses Model dan Fleksibilitas Pemilihan
API langsung cocok ketika produk sudah menetapkan satu provider sebagai fondasi utama. Tim dapat mengoptimalkan prompt, tool, dan format output terhadap model tertentu. Namun, perubahan provider biasanya memerlukan adapter baru serta pengujian ulang pada seluruh alur aplikasi.
Aggregator mendukung eksperimen lintas model dengan friksi lebih rendah. Tim dapat membandingkan model untuk tugas yang berbeda, misalnya ekstraksi dokumen, percakapan pelanggan, coding, klasifikasi, atau pembuatan konten. Fleksibilitas tersebut berguna karena model yang terbaik untuk satu tugas belum tentu memberikan biaya, kecepatan, dan akurasi terbaik pada tugas lain.
Biaya Total dan Administrasi
Harga token tetap penting, tetapi angka tersebut hanya satu komponen biaya. Integrasi langsung dapat menambah biaya engineering untuk membangun konektor, menyatukan log, memelihara fallback, dan menyesuaikan perubahan API. Tim keuangan juga perlu menangani akun, metode pembayaran, invoice, kurs, dan rekonsiliasi dari beberapa provider.
Aggregator dapat menambahkan markup atau struktur harga tersendiri. Biaya tersebut perlu dibandingkan dengan pekerjaan yang dihilangkan, seperti pemeliharaan integrasi, pengelolaan kredensial, observability, dan konsolidasi administrasi. Analisis yang adil memakai total cost of ownership selama periode tertentu, bukan sekadar membandingkan harga unit pada satu halaman pricing.
Perusahaan juga perlu memperhitungkan biaya kegagalan. Jika satu provider mengalami gangguan dan aplikasi tidak memiliki jalur alternatif, dampaknya dapat berupa transaksi tertunda, layanan pelanggan terhenti, atau tim operasional melakukan penanganan manual. Nilai fallback menjadi lebih besar ketika workload AI sudah masuk ke proses bisnis yang sensitif terhadap waktu.
Kontrol Penggunaan dan Tata Kelola
Integrasi langsung memberi kontrol teknis yang kuat, tetapi kontrol organisasi harus dibangun sendiri. Perusahaan perlu menetapkan siapa yang boleh membuat API key, model apa yang dapat digunakan, bagaimana penggunaan dipisahkan per tim, dan di mana log disimpan. Tanpa standar bersama, setiap divisi dapat membangun pola pengelolaan yang berbeda.
Aggregator dengan fungsi gateway dapat menyediakan titik kontrol terpusat. Organisasi dapat menerapkan kebijakan akses, melihat konsumsi lintas model, dan menghubungkan penggunaan dengan aplikasi atau unit bisnis. Prinsip ini sejalan dengan pendekatan manajemen risiko AI yang menempatkan governance sebagai fungsi lintas siklus hidup, bukan kegiatan yang dilakukan setelah sistem selesai dibuat.
Reliability dan Risiko Ketergantungan
API langsung tidak otomatis berarti aplikasi bergantung penuh pada satu provider. Tim dapat membangun adapter internal dan menghubungkan beberapa provider secara langsung. Namun, kemampuan tersebut membutuhkan desain routing, health check, retry policy, fallback, serta pengujian skenario kegagalan.
Aggregator dapat menyediakan jalur pengalihan yang lebih cepat, tetapi perusahaan perlu memeriksa cara fallback diterapkan. Model pengganti harus kompatibel dengan format input, kebutuhan tool, batas konteks, dan struktur output aplikasi. Fallback yang hanya mengganti endpoint tanpa validasi kualitas dapat menjaga request tetap berjalan tetapi menghasilkan respons yang tidak sesuai kebutuhan bisnis.
Ketergantungan juga dapat berpindah dari provider model ke provider aggregator. Karena itu, aplikasi sebaiknya memiliki lapisan adapter internal, konfigurasi model yang tidak tersebar di banyak bagian kode, serta rencana keluar jika layanan aggregator tidak lagi sesuai. Portabilitas tetap menjadi tanggung jawab arsitektur perusahaan.
Latency dan Kontrol Performa
Koneksi langsung secara teori memiliki jalur jaringan lebih pendek karena request tidak melewati layanan tambahan. Pada workload yang sangat sensitif terhadap latency, perbedaan kecil dapat berarti. Namun, performa aktual dipengaruhi lokasi server, antrean provider, ukuran input, model yang dipilih, streaming, dan pola retry.
Aggregator menambahkan satu lapisan pemrosesan, tetapi dapat mengimbanginya melalui routing, koneksi yang sudah dioptimalkan, observability, atau pemilihan model yang lebih cepat. Pengujian perlu dilakukan dari lingkungan deployment yang sebenarnya. Ukur latency persentil, tingkat error, waktu respons pertama, dan kestabilan pada beban tinggi, bukan hanya satu request percobaan.
Keamanan Data dan Batas Tanggung Jawab
Setiap integrasi pihak ketiga menambah hubungan kepercayaan baru. Pada API langsung, data dikirim dari aplikasi ke provider model. Pada aggregator, data melewati lapisan aggregator sebelum diteruskan. Perusahaan perlu memahami aliran data, retensi log, lokasi pemrosesan, enkripsi, kontrol akses, serta ketentuan penggunaan dari setiap pihak yang terlibat.
OWASP memasukkan broken authentication, unrestricted resource consumption, improper inventory management, dan unsafe consumption of APIs ke dalam daftar risiko API Security 2023. Risiko tersebut relevan untuk kedua pendekatan. Aggregator dapat membantu memusatkan kontrol, tetapi tidak menggantikan validasi input, pembatasan hak akses, pengamanan secret, pencatatan audit, dan pengujian keamanan pada aplikasi sendiri.
Untuk data sensitif, tim legal, keamanan, dan pemilik proses bisnis perlu menentukan klasifikasi data yang boleh dikirim. Kebijakan ini harus diterapkan pada level aplikasi dan akses pengguna. Pilihan koneksi tidak dapat memperbaiki praktik data yang sejak awal tidak memiliki batas yang jelas.
Kapan API Langsung Lebih Tepat
API langsung layak diprioritaskan ketika satu provider menjadi bagian penting dari diferensiasi produk. Contohnya, aplikasi memakai fitur khusus yang belum tersedia melalui lapisan lain, membutuhkan parameter eksperimental, atau memiliki kontrak enterprise yang mencakup dukungan dan ketentuan data tertentu.
Pendekatan ini juga masuk akal ketika volume penggunaan sangat besar dan relatif stabil. Pada skala tersebut, perusahaan dapat menilai optimasi biaya, kapasitas, dan kontrak secara khusus. Tim platform yang matang biasanya mampu membangun observability, keamanan, rate limiting, dan fallback tanpa bergantung pada layanan tambahan.
API langsung cenderung sesuai bila beberapa kondisi berikut terpenuhi:
- Produk hanya membutuhkan satu atau dua model dalam jangka menengah.
- Fitur eksklusif provider menjadi bagian penting dari pengalaman produk.
- Tim engineering siap memelihara SDK, adapter, logging, dan mekanisme retry sendiri.
- Perusahaan memiliki kontrak dan kontrol data langsung dengan provider.
- Kebutuhan latency sudah diuji dan jalur langsung memberikan manfaat yang terukur.
Kapan API Aggregator Lebih Tepat
API aggregator lebih menarik ketika perusahaan sedang mengevaluasi banyak model atau membangun beberapa use case secara paralel. Satu tim mungkin membutuhkan model untuk customer service, sementara tim lain membutuhkan analisis dokumen atau coding. Jika setiap use case membuat integrasi dan akun sendiri, kompleksitas tumbuh lebih cepat daripada jumlah proyek.
Aggregator juga membantu ketika perusahaan ingin memisahkan keputusan aplikasi dari keputusan provider. Aplikasi tetap memakai kontrak internal yang konsisten, sedangkan model dapat diganti melalui konfigurasi dan pengujian. Cara ini mempercepat eksperimen serta mengurangi perubahan pada kode bisnis.
API aggregator cenderung sesuai bila organisasi menghadapi kondisi berikut:
- Beberapa tim membutuhkan model AI yang berbeda.
- Perusahaan ingin menguji model baru tanpa membangun integrasi dari awal.
- Pengelolaan banyak API key, akun, dan tagihan mulai membebani operasi.
- Visibilitas penggunaan lintas model dibutuhkan oleh engineering, keamanan, atau finance.
- Aplikasi memerlukan opsi routing dan fallback yang dapat dikelola secara terpusat.
Strategi Hybrid untuk Menjaga Fleksibilitas
Perusahaan tidak harus memilih satu pendekatan untuk seluruh workload. Strategi hybrid memakai API langsung untuk workload yang stabil dan sangat bergantung pada fitur khusus provider, lalu memakai aggregator untuk eksperimen, workload yang mudah dipindahkan, atau kebutuhan yang memerlukan banyak model.
Agar hybrid tidak menghasilkan dua arsitektur yang terpisah, aplikasi sebaiknya memanggil service internal atau adapter yang sama. Lapisan internal tersebut menyimpan konfigurasi model, timeout, kebijakan retry, dan skema output. Di belakangnya, tim dapat menentukan apakah request diteruskan ke koneksi langsung atau aggregator.
Pendekatan ini menjaga pilihan teknis tetap terbuka, tetapi memerlukan disiplin. Tim harus menentukan model default, aturan eskalasi, data yang boleh melewati setiap jalur, dan indikator kapan koneksi perlu dipindahkan. Tanpa aturan tersebut, hybrid hanya menambah jumlah integrasi yang harus dikelola.
Kerangka Memilih Arsitektur yang Tepat
Gunakan pertanyaan berikut untuk menilai kebutuhan secara sistematis. Jawab berdasarkan workload yang nyata dan proyeksi penggunaan, bukan berdasarkan demo satu model.
- Berapa banyak provider dan model yang benar-benar akan digunakan dalam 12 bulan ke depan? Jika hanya satu model yang stabil, integrasi langsung mungkin cukup. Jika jumlahnya bertambah, nilai lapisan agregasi meningkat.
- Apakah aplikasi membutuhkan fitur khusus provider? Catat fitur yang tidak dapat digantikan, lalu pastikan aggregator mendukungnya sebelum membuat keputusan.
- Seberapa sering tim perlu mengganti atau membandingkan model? Eksperimen yang rutin membutuhkan abstraksi, evaluasi, dan konfigurasi yang mudah diubah.
- Siapa yang akan mengelola API key, akses, log, anggaran, dan invoice? Masukkan waktu tim engineering, security, procurement, dan finance ke dalam perhitungan biaya.
- Apa dampak jika provider tidak tersedia? Tentukan recovery objective, model pengganti, serta batas penurunan kualitas yang masih dapat diterima.
- Data apa yang dikirim dan pihak mana yang memprosesnya? Tinjau klasifikasi data, retensi, lokasi pemrosesan, kontrak, dan kontrol audit.
- Bagaimana perusahaan dapat berpindah arsitektur nanti? Gunakan adapter internal, konfigurasi terpusat, dan pengujian portabilitas agar keputusan hari ini tidak mengunci kode aplikasi.
Cara Menghitung Efisiensi Secara Realistis
Buat estimasi untuk periode 12 bulan dan pisahkan biaya menjadi empat kelompok: konsumsi model, engineering, operasi, dan administrasi. Konsumsi model mencakup token atau unit pemrosesan. Engineering mencakup pembangunan adapter, pengujian, dan pemeliharaan. Operasi mencakup monitoring, incident response, fallback, dan keamanan. Administrasi mencakup procurement, invoice, kurs, dan rekonsiliasi.
Bandingkan skenario langsung, aggregator, dan hybrid dengan asumsi workload yang sama. Jangan menghitung waktu pengembangan sebagai biaya satu kali jika integrasi akan sering berubah. Gunakan rentang rendah, tengah, dan tinggi untuk volume request, jumlah model, serta frekuensi perubahan agar keputusan tidak bergantung pada satu proyeksi yang terlalu optimistis.
Efisiensi juga harus diukur setelah implementasi. Pantau biaya per use case, latency persentil, error rate, waktu penanganan insiden, jumlah perubahan integrasi, dan waktu rekonsiliasi tagihan. Jika metrik aktual berbeda jauh dari asumsi, arsitektur dapat disesuaikan tanpa menunggu kontrak atau kode menjadi terlalu sulit dipindahkan.
Langkah Implementasi yang Mengurangi Risiko
Petakan Workload dan Persyaratannya
Mulai dari daftar use case, jenis data, volume, kebutuhan latency, format output, serta toleransi kegagalan. Pemetaan ini mencegah tim memilih arsitektur hanya karena satu API mudah digunakan dalam demo. Workload customer service real-time, analisis dokumen batch, dan bantuan coding dapat membutuhkan model serta pola reliability yang berbeda.
Bangun Kontrak Internal yang Stabil
Definisikan format request dan response yang digunakan aplikasi sendiri. Adapter kemudian menerjemahkan kontrak internal tersebut ke API langsung atau aggregator. Dengan cara ini, perubahan provider tidak menyebar ke seluruh kode bisnis. Simpan pemilihan model dan parameter utama dalam konfigurasi yang dapat diaudit.
Kelola Kredensial di Sisi Server
Jangan menanam API key di browser, aplikasi mobile, repositori, atau dokumen bersama. Simpan secret di secret manager atau environment server dengan akses minimum. Pisahkan kredensial untuk development, staging, dan production, lalu rotasi secara berkala dan ketika ada indikasi kebocoran.
Siapkan Observability Sebelum Production
Catat model, use case, latency, status request, estimasi konsumsi, dan versi konfigurasi tanpa menyimpan data sensitif secara berlebihan. Dashboard perlu membantu tim menjawab tiga pertanyaan: apa yang gagal, siapa yang terdampak, dan berapa biaya yang timbul. Google Cloud menjelaskan bahwa gateway dapat membantu autentikasi, monitoring, traffic management, dan pelacakan penggunaan, tetapi implementasi metrik bisnis tetap perlu disesuaikan oleh pemilik aplikasi.
Uji Fallback dan Portabilitas
Simulasikan timeout, rate limit, perubahan format, respons kosong, dan penurunan kualitas. Uji apakah model alternatif menghasilkan struktur output yang tetap dapat diproses aplikasi. Lakukan pengujian portabilitas secara berkala agar jalur cadangan tidak hanya terlihat benar pada diagram, tetapi benar-benar dapat digunakan ketika terjadi gangguan.
Peran TokenKuai dalam Arsitektur Multi Model
TokenKu.ai dirancang sebagai managed AI marketplace yang membantu bisnis mengakses berbagai model melalui satu gateway. Pendekatan ini relevan bagi organisasi yang ingin mengurangi jumlah integrasi terpisah, menyederhanakan pengelolaan penggunaan, dan memperoleh visibilitas yang lebih terpusat.
Bagi bisnis Indonesia, penagihan dalam Rupiah dan pengelolaan akses melalui satu platform dapat mengurangi pekerjaan administratif dibandingkan mengelola banyak akun provider secara mandiri. Tim tetap perlu menilai dukungan model, kebutuhan data, performa, serta fungsi teknis yang dibutuhkan oleh aplikasi sebelum memindahkan workload production.
Jika Anda masih memetakan fondasinya, baca panduan API AI Indonesia dan penjelasan tentang fungsi AI API gateway. Kedua artikel tersebut membantu memisahkan konsep akses model, gateway, dan strategi integrasi sebelum perusahaan membandingkan opsi implementasi.
Pertanyaan Umum
Apakah API Aggregator Selalu Lebih Murah
Tidak. Aggregator dapat mengurangi biaya integrasi, pemeliharaan, dan administrasi, tetapi mungkin memiliki struktur harga atau markup tersendiri. Bandingkan total biaya kepemilikan berdasarkan volume, jumlah model, waktu engineering, kebutuhan reliability, dan pekerjaan finance.
Apakah API Langsung Selalu Lebih Cepat
Tidak selalu. Jalur langsung memang memiliki lebih sedikit perantara, tetapi latency aktual dipengaruhi model, lokasi server, antrean, ukuran input, streaming, dan retry. Uji kedua opsi dari lingkungan deployment dengan workload yang sama.
Bisakah Aplikasi Menggunakan API Langsung dan Aggregator Sekaligus
Bisa. Strategi hybrid dapat memakai koneksi langsung untuk workload yang memerlukan fitur khusus dan aggregator untuk eksperimen atau routing multi-model. Gunakan adapter internal agar pilihan jalur tidak tersebar di seluruh kode aplikasi.
Apakah Aggregator Menghilangkan Risiko Vendor Lock In
Aggregator dapat mengurangi ketergantungan pada satu provider model, tetapi perusahaan dapat menjadi bergantung pada kontrak dan format aggregator. Portabilitas tetap membutuhkan kontrak internal, konfigurasi terpusat, dokumentasi, dan pengujian jalur keluar.
Apakah Data Menjadi Lebih Berisiko Saat Menggunakan Aggregator
Aggregator menambah satu pihak dalam aliran data, sehingga due diligence perlu mencakup retensi, enkripsi, lokasi pemrosesan, kontrol akses, subprocessor, serta ketentuan kontrak. Risiko tidak dapat disimpulkan hanya dari jenis koneksi. Evaluasi kebijakan dan arsitektur setiap layanan.
Apa Indikator Bahwa Bisnis Membutuhkan API Aggregator
Indikator yang umum adalah bertambahnya provider, duplikasi adapter, API key yang tersebar, log yang sulit disatukan, invoice yang terfragmentasi, dan kebutuhan fallback lintas model. Jika beban pengelolaan tersebut mulai memperlambat tim, lapisan agregasi layak dievaluasi.
Menentukan Arsitektur Berdasarkan Kebutuhan Bisnis
API langsung memberikan kedalaman kontrol pada provider tertentu. API aggregator memberikan konsistensi dan fleksibilitas ketika perusahaan memakai banyak model. Pilihan yang efisien adalah pilihan yang menekan total pekerjaan dan risiko untuk workload yang nyata, bukan pilihan dengan diagram paling sederhana atau harga unit paling rendah.
Mulailah dengan satu atau dua use case, ukur performa dan biaya, lalu dokumentasikan batas keputusan. Jika kebutuhan berubah, adapter internal dan observability yang baik memungkinkan perusahaan memperluas koneksi langsung, memakai aggregator, atau menggabungkan keduanya tanpa menulis ulang seluruh aplikasi.