Refactor Supabase services in docker-compose.yml for better organization and testing
- Commented out all Supabase services to facilitate testing with Supabase CLI. - Updated README to include Supabase directory in project structure. - Adjusted documentation for migration paths in Supabase Docker Compose guide. - Enhanced docker-compose-reset.sh to explicitly remove Supabase volumes and wait for migrations to complete.
This commit is contained in:
93
docs/SUPABASE_MIGRATION.md
Normal file
93
docs/SUPABASE_MIGRATION.md
Normal file
@@ -0,0 +1,93 @@
|
||||
# Supabase Directory Migration
|
||||
|
||||
## What Changed
|
||||
|
||||
The Supabase configuration has been moved from `management-dashboard-web-app/supabase/` to the project root `supabase/` directory.
|
||||
|
||||
## Why This Change?
|
||||
|
||||
1. **Better Architecture**: Supabase is shared infrastructure, not specific to the web app
|
||||
2. **Monorepo Best Practice**: Infrastructure concerns should be at the root level
|
||||
3. **Easier Access**: Other services (APIs, scripts) can now easily reference the database
|
||||
4. **Clearer Ownership**: Makes it obvious that Supabase is a project-wide resource
|
||||
|
||||
## Migration Steps
|
||||
|
||||
### For Docker Compose Users
|
||||
|
||||
No action needed! The `docker-compose.yml` has been updated to use the new paths. Just restart your containers:
|
||||
|
||||
```bash
|
||||
docker compose down
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
### For Supabase CLI Users
|
||||
|
||||
**Before** (old way):
|
||||
```bash
|
||||
cd management-dashboard-web-app
|
||||
supabase start
|
||||
supabase db reset
|
||||
```
|
||||
|
||||
**After** (new way):
|
||||
```bash
|
||||
# From project root - no need to cd!
|
||||
supabase start
|
||||
supabase db reset
|
||||
```
|
||||
|
||||
The Supabase CLI automatically looks for the `supabase/` directory in the current working directory, so you can now run all Supabase commands from the project root.
|
||||
|
||||
### Updating Your Workflow
|
||||
|
||||
If you have scripts or documentation that reference the old path, update them:
|
||||
|
||||
- ❌ `management-dashboard-web-app/supabase/migrations/`
|
||||
- ✅ `supabase/migrations/`
|
||||
|
||||
- ❌ `management-dashboard-web-app/supabase/config.toml`
|
||||
- ✅ `supabase/config.toml`
|
||||
|
||||
## Backward Compatibility
|
||||
|
||||
The old directory (`management-dashboard-web-app/supabase/`) can be kept for reference, but it's no longer used by docker-compose or the Supabase CLI. You can safely remove it after verifying everything works:
|
||||
|
||||
```bash
|
||||
# After verifying everything works with the new location
|
||||
rm -rf management-dashboard-web-app/supabase
|
||||
```
|
||||
|
||||
## Verification
|
||||
|
||||
To verify the migration worked:
|
||||
|
||||
1. **Check docker-compose paths**:
|
||||
```bash
|
||||
grep -r "supabase" docker-compose.yml
|
||||
# Should show: ./supabase/ (not ./management-dashboard-web-app/supabase/)
|
||||
```
|
||||
|
||||
2. **Test Supabase CLI**:
|
||||
```bash
|
||||
# From project root
|
||||
supabase status
|
||||
# Should work without needing to cd into management-dashboard-web-app
|
||||
```
|
||||
|
||||
3. **Test migrations**:
|
||||
```bash
|
||||
docker compose up -d
|
||||
docker compose logs supabase-migrate
|
||||
# Should show migrations running successfully
|
||||
```
|
||||
|
||||
## Benefits
|
||||
|
||||
✅ Run Supabase commands from project root
|
||||
✅ Clearer project structure
|
||||
✅ Easier to share database across services
|
||||
✅ Better alignment with monorepo best practices
|
||||
✅ Infrastructure separated from application code
|
||||
|
||||
Reference in New Issue
Block a user