PHP Tanpa Laravel: Bisakah Aplikasi Kompleks Dibangun Tanpa Framework Besar?
Website BisnisApakah PHP custom tanpa Laravel bisa tangani membership dan payment? Assessment arsitektur mendalam, kapan harus upgrade, dan roadmap pengembangan praktisnya.
Pertanyaan ini sering muncul ketika sebuah aplikasi PHP yang dibangun secara custom mulai berkembang dan kebutuhan fitur semakin kompleks. Apakah selamanya harus berpindah ke Laravel untuk menangani kompleksitas? Atau apakah aplikasi saat ini bisa dikembangkan untuk memenuhi kebutuhan tersebut?
Laravel Bukan Syarat Wajib untuk Aplikasi Kompleks
Framework seperti Laravel populer bukan karena dia satu-satunya cara membangun aplikasi kompleks, melainkan karena dia menyediakan pola-pola arsitektur yang dibutuhkan secara built-in. Yang sebenarnya menentukan kemampuan aplikasi menangani kompleksitas adalah arsitektur dan pattern, bukan nama frameworknya.
Bukti nyata: Wikipedia masih berjalan di atas PHP custom hingga sekarang. Etsy dan Slack (awal) juga menggunakan PHP custom. WordPress sendiri adalah prosedural PHP dengan OOP custom — bukan Laravel. Semua ini membuktikan bahwa framework bukan penentu, arsitektur yang menentukan.
Perbandingan: Apa yang Disediakan Laravel vs Apa yang Bisa Dibangun Sendiri
| Yang Diperlukan | Laravel Menyediakan | Status Custom |
|---|---|---|
| Separation of concerns | MVC + Service Provider | Repository + Service sudah ada |
| Database abstraction | Eloquent ORM | Raw mysqli — perlu peningkatan |
| Transaction safety | DB::transaction() | Manual, belum konsisten |
| Auth & permission | Guards, Gates, Policies | Custom — perlu diperkuat |
| Dependency management | Composer autoload | Sudah pakai Composer |
| Schema migration | Laravel Migrations | Tidak ada — perlu dibangun |
Kapan Sebaiknya Pindah ke Laravel?
Migrasi ke Laravel worth it dalam kondisi berikut:
- Tim berkembang lebih dari 3 developer — onboarding lebih mudah karena Laravel sudah dikenal luas
- Butuh ekosistem package yang luas, seperti Laravel Cashier untuk subscription, Horizon untuk queue, atau Sanctum untuk API token
- Target jangka panjang adalah API-first, mobile app, atau multi-tenant yang kompleks
Sebaliknya, tetap di sistem saat ini worth it jika tim kecil (1–2 orang), tidak ada rencana ekspos API publik, ingin move fast tanpa learning curve, dan menginginkan kontrol penuh atas setiap layer.
Menilai Kesiapan Aplikasi PHP Custom untuk Kompleksitas
Sebelum memutuskan apakah perlu migrasi, penting untuk menilai kondisi arsitektur aplikasi yang ada. Berikut adalah aspek-aspek kritis yang menentukan kesiapan:
Fondasi yang Sudah Solid
- IoC Container — Dependency injection tersedia, memungkinkan decoupling antar komponen
- Repository + Service Pattern — Separation of concerns yang jelas antara data access dan business logic
- Permission System Granular — Role-based access control dengan permission spesifik per modul
- Multi-site Architecture — Semua query ter-isolasi per site_id, siap untuk multi-tenant
- Audit Logging — Jejak aktivitas tersedia untuk semua operasi penting
- Error Monitoring — Sistem pencatatan error terintegrasi di seluruh handler
Gap Kritis yang Harus Diisi
Ada beberapa gap yang menjadi risiko tinggi jika tidak ditangani sebelum menambah fitur kompleks seperti membership dan payment:
1. Tidak Ada Transaction Wrapper yang Konsisten
Operasi keuangan seperti penyimpanan data pembayaran dan update status order harus bersifat atomic — berhasil semua atau gagal semua. Tanpa begin_transaction() dan rollback() yang konsisten, ada risiko data inconsistency: pembayaran tercatat tapi status membership tidak terupdate.
2. Schema Migration Tidak Terstruktur
Runtime ALTER TABLE di dalam constructor class adalah praktik berbahaya di production. Tidak ada cara untuk melacak versi database, rollback jika ada kesalahan, atau mendokumentasikan perubahan skema secara terstruktur.
3. Auth Hanya Berbasis Session
Untuk member portal yang diakses dari browser maupun mobile, diperlukan token-based authentication. Session PHP tidak bisa digunakan lintas domain atau untuk REST API.
4. Tidak Ada Queue/Job System
Fitur membership memerlukan proses background: pengiriman email konfirmasi, reminder expiry keanggotaan, dan webhook dari payment gateway. Semua proses ini harus asynchronous agar tidak memblokir request utama.
Roadmap Pengembangan: Tiga Fase
Fase 1 — Perkuat Fondasi
Sebelum membangun fitur membership, perkuat infrastruktur yang ada:
- Buat
DbTransactionwrapper — semua operasi keuangan wajib atomic - Buat
MigrationRunnersederhana — minimal tracker versi skema via tabel_migrations - Audit semua payment dan order service untuk menggunakan wrapper tersebut
Fase 2 — Membership Core
Setelah fondasi kuat, bangun layer membership:
- Desain tabel:
member_tiers,member_subscriptions,member_payments,member_invoices - Extend permission registry untuk member roles
- Tambah
MemberAuthTokenuntuk akses API member area
Fase 3 — Payment Gateway & Background Jobs
- Integrasi Midtrans atau Stripe via Composer package resmi
- Bangun
SimpleQueueberbasis database — bisa upgrade ke Redis nanti - Webhook handler untuk konfirmasi pembayaran otomatis
Kesimpulan
Aplikasi PHP custom yang dibangun dengan pola arsitektur yang benar — Repository, Service, IoC Container, dan Permission System — sepenuhnya mampu menangani kompleksitas setingkat aplikasi berbasis framework. Yang membedakan bukan framework-nya, melainkan keberadaan pattern dan infrastruktur yang tepat.
Pendekatan yang paling realistis adalah hybrid: perkuat fondasi yang sudah ada, isi gap kritis satu per satu, dan evaluasi kembali kebutuhan migrasi ke framework besar hanya setelah fitur baru terbukti viable dan traffic tumbuh signifikan. Migrasi tergesa-gesa justru menambah risiko tanpa nilai tambah yang proporsional.
Dengan fondasi yang tepat, PHP custom bukan sekadar pilihan kedua — melainkan pilihan strategis yang memberikan kontrol penuh dan fleksibilitas maksimal bagi tim kecil yang ingin bergerak cepat.
