# Shinecode Architecture

## Architecture Decision
Shinecode utilizes a hybrid architecture: an independently deployed Next.js frontend platform handles discovery and SEO, while Laravel serves as the authoritative backend and directly renders the transactional booking wizard via Blade templates. 

This architecture is intentional because Shinecode requires:
- Independent frontend evolution for public discovery
- Ultra-low friction, server-rendered transactional flows
- Sophisticated public SEO
- Strict boundary separation for decoupled sub-modules

## High-Level Architecture
```text
                         INTERNET
                             |
                        Cloudflare
                       CDN / WAF / DNS
                             |
             +---------------+---------------+
             |                               |
    www.shinecode.ae                 booking.shinecode.ae
        (Next.js/PM2)                  (Laravel Blade)
             |                               |
             +---------------+---------------+
                             |
                    api.shinecode.ae
                      (Laravel API)
                             |
                 +-----------+-----------+
                 |                       |
              MySQL 8                 Redis
```

## Directory Structure & Boundary Isolation
To accommodate future decoupled sub-modules and clear team boundaries, the repository structure is strictly segregated:

```text
/sc/
├── shinecode_core/          # Backend frameworks (Laravel, API, Admin, Database)
│   ├── app/
│   ├── routes/
│   ├── resources/views/     # Blade templates (Booking Wizard)
│   └── ...
│
└── shinecode_frontend/      # Frontend applications (Next.js, Public UI)
    ├── web/
    ├── app/
    └── packages/
```

## Responsibility Boundary
**Next.js owns:**
- Public rendering and routing
- Presentation for SEO and Discovery surfaces
- Frontend caching
- Public content composition

**Laravel owns:**
- Business logic
- Authentication and Authorization
- The Booking Wizard rendering (via Blade)
- Data integrity and Database access
- Payments, Booking rules, and Availability rules

## Source of Truth
Laravel is authoritative for all business logic. Next.js must never become the authoritative source for business rules. 

## Rendering Strategy
Use the least expensive rendering strategy that satisfies the requirement.
Preferred order:
1. Static (Next.js)
2. Cached server rendering (Next.js)
3. Direct server-rendered Blade templates (Laravel - for booking flows)
4. Incrementally regenerated content (Next.js)
5. Dynamic server rendering (Next.js)
6. Client rendering only where interaction strictly requires it