80 lines
3.8 KiB
Markdown
80 lines
3.8 KiB
Markdown
# Strategy: Scaling BukidBountyApp for Multiple Companies
|
|
|
|
This document outlines the recommended approach for deploying BukidBountyApp across different companies while maintaining efficiency and code quality.
|
|
|
|
## Comparison of Approaches
|
|
|
|
| Feature | Option 1: Split Repositories | Option 2: Single Codebase (Multi-Instance) |
|
|
| :--- | :--- | :--- |
|
|
| **Maintenance** | **High Overhead**. A bug fix in one repo must be manually copied to others. | **Low Overhead**. One fix in the main repo benefits all instances. |
|
|
| **Consistency** | **Low**. Repos will drift apart over time, making cross-support difficult. | **High**. All companies run the same version of the platform. |
|
|
| **Customization** | **Easy**. Just edit the code for that one company. | **Config-Driven**. Use environment variables or flags to toggle features. |
|
|
| **Data Privacy** | **Physical Isolation**. Separate repos usually mean separate DBs. | **Physical Isolation**. Each instance connects to its own database. |
|
|
| **Scalability** | **Poor**. Adding a 4th company requires another repo and more maintenance. | **Excellent**. Just add a new deployment in Dokploy. |
|
|
|
|
---
|
|
|
|
## Proposed Plan: Single Codebase, Multi-Instance
|
|
I propose a **Single Codebase** approach using **Environment-Based Deployments**. This is the standard "Best Practice" for SaaS-like applications.
|
|
|
|
### 1. Repository Management
|
|
* Keep **one single repository** for all core logic.
|
|
* Use branches (`production`, `staging`) to manage release cycles.
|
|
* Every company pulls from the same codebase.
|
|
|
|
### 2. Deployment Architecture (Dokploy)
|
|
Instead of one Dokploy project, you create multiple deployments pointing to the same repository:
|
|
* **Instance A**: `company-a.bukid.app`
|
|
* **Instance B**: `company-b.bukid.app`
|
|
* **Instance C**: `company-c.bukid.app`
|
|
|
|
### 3. Environment Variables (.env) for Customization
|
|
Use the `.env` file for each instance to differentiate the identity and behavior:
|
|
```bash
|
|
# Instance A .env
|
|
APP_NAME="Company A Bounty"
|
|
APP_URL="https://company-a.bukid.app"
|
|
PRIMARY_COLOR="#4CAF50"
|
|
DB_DATABASE="bukid_company_a"
|
|
ENABLE_MODULE_FARMER=true
|
|
```
|
|
|
|
```bash
|
|
# Instance B .env
|
|
APP_NAME="Company B Marketplace"
|
|
APP_URL="https://company-b.bukid.app"
|
|
PRIMARY_COLOR="#2196F3"
|
|
DB_DATABASE="bukid_company_b"
|
|
ENABLE_MODULE_FARMER=false
|
|
```
|
|
|
|
### 4. Code Adjustments for Customization
|
|
To make the UI "dynamic" based on the company:
|
|
* **Identity**: Use `{{ config('app.name') }}` in the frontend (passed via Inertia or API).
|
|
* **Theming**: In `app.js` or `index.css`, use CSS variables that can be injected based on environment.
|
|
* **Features**: Wrap specific modules (like Farmer Management) in Feature Flags:
|
|
```php
|
|
// In a Controller or Vue component
|
|
if (config('features.farmer_module')) {
|
|
// Show farmer features
|
|
}
|
|
```
|
|
|
|
### 5. Database Isolation
|
|
Since each instance has its own `DB_DATABASE` env variable, the data is physically isolated. This ensures that:
|
|
- Company A cannot see Company B's data.
|
|
- Migrations are run per instance.
|
|
- You can backup/restore Company A without affecting others.
|
|
|
|
---
|
|
|
|
## Migration Steps (Advice)
|
|
|
|
1. **Audit hardcoded strings**: Scan the code for "BukidBounty" and replace them with `config('app.name')`.
|
|
2. **Move Colors to variables**: If you have hardcoded colors in CSS, move them to `:root` variables in `index.css` and allow them to be overridden or controlled by the app name.
|
|
3. **Setup Dokploy Multi-Project**: Create a second project in Dokploy, use the same SSH key/Repo URL, and configure a second database.
|
|
4. **Feature Toggles**: Create a `config/features.php` file that reads from `env()` to enable/disable specific modules for specific companies.
|
|
|
|
## Conclusion
|
|
**Option 2 (Single Codebase)** is the significantly better long-term choice. It prevents "Maintenance Hell" and ensures that as you improve the app for one company, you are improving it for everyone.
|