Fasti Laravel Package

Technical Evaluation

Architecture Fit

• Precision Scheduling: Fasti excels at one-time, calendar-based task scheduling (e.g., time-sensitive notifications, event-triggered jobs), complementing Laravel’s built-in schedule:run (which is cron-based and lacks granularity for ad-hoc future execution).
• Job Integration: Seamlessly integrates with Laravel’s job system (queues, commands, or direct execution), leveraging existing ShouldQueue/Handle interfaces.
• Alternative to External Services: Reduces dependency on third-party schedulers (e.g., AWS EventBridge, BullMQ) for simple time-based workflows, lowering operational overhead.
• Limitation: Not designed for recurring tasks (use Laravel’s schedule:table instead) or event-driven triggers (e.g., webhooks).

Integration Feasibility

• Low Friction: Requires minimal setup (composer install, service provider binding) and aligns with Laravel’s conventions.
• Database Dependency: Stores scheduled jobs in a table (fasti_jobs), requiring migrations. Assumes a relational DB (MySQL, PostgreSQL, etc.).
• Queue Backend: Relies on Laravel’s queue system (e.g., Redis, database, SQS) for async execution. Performance depends on the queue’s reliability.
• Time Synchronization: Assumes server time accuracy; timezones must be configured explicitly in jobs.

Technical Risk

• Job Persistence: If the database fails between scheduling and execution, jobs may be lost. Mitigate with backups or transactional writes.
• Race Conditions: Concurrent schedule() calls for the same job could lead to duplicates. Requires idempotency checks in jobs.
• Testing Complexity: Time-based tests (e.g., verifying a job runs at 2024-12-31) need mocking or manual verification.
• Queue Bottlenecks: High-volume scheduling could overwhelm the queue. Monitor fasti_jobs table growth and queue lag.

Key Questions

1. Use Case Alignment:
   • Are tasks one-time, time-sensitive (e.g., "send email at 3 PM") or recurring (use Laravel’s scheduler)?
   • Does the team need event-based triggers (e.g., "run when X happens") or strict time-based execution?
2. Queue Reliability:
   • What’s the backup plan if the queue fails (e.g., dead-letter queue, retries)?
3. Scalability:
   • How many concurrent jobs will be scheduled? Will the fasti_jobs table scale?
4. Timezone Handling:
   • Are jobs scheduled in UTC or user-local time? How will this be managed?
5. Monitoring:
   • How will failed/successful executions be logged or alerted (e.g., Laravel Horizon, custom metrics)?

Integration Approach

Stack Fit

• Laravel Ecosystem: Native support for Laravel 10/11, jobs, queues, and service containers. No polyfills needed.
• Database: Requires a supported DB (MySQL, PostgreSQL, SQLite). Avoids NoSQL for job persistence.
• Queue Systems: Works with any Laravel-supported queue (Redis, database, SQS, etc.). Async execution depends on queue reliability.
• Testing: Compatible with Laravel’s testing tools (e.g., ScheduleTestCase for cron jobs, but Fasti needs custom assertions for time-based jobs).

Migration Path

1. Pilot Phase:
   • Replace ad-hoc cron jobs or manual sleep() delays with Fasti for time-sensitive tasks.
   • Example: Replace a script that runs sleep(3600) before sending an email with Fasti::schedule($job, now()->addHour()).
2. Incremental Adoption:
   • Start with non-critical jobs (e.g., notifications) to validate reliability.
   • Gradually migrate from external schedulers (e.g., AWS CloudWatch) for cost savings.
3. Legacy Systems:
   • For monolithic apps, use Fasti’s synchronous execution mode for jobs that can’t use queues.

Compatibility

• Laravel Versions: Tested on Laravel 10/11. May require minor adjustments for older versions.
• Job Classes: Must implement Laravel’s Job interface (e.g., ShouldQueue, Handle). Custom jobs work if they follow conventions.
• Time Libraries: Uses Carbon for dates; no external dependencies beyond Laravel’s core.
• Permissions: No special permissions needed beyond Laravel’s queue worker access.

Sequencing

1. Installation:
   • composer require a-bashtannik/fasti
   • Publish config/migrations: php artisan vendor:publish --provider="Bashtannik\Fasti\FastiServiceProvider"
   • Run migrations: php artisan migrate
2. Configuration:
   • Bind the Fasti facade in config/app.php (or use dependency injection).
   • Set default timezone in config/fasti.php (e.g., timezone = 'UTC').
3. Job Scheduling:
   • Schedule jobs via Fasti::schedule($job, $datetime) in controllers, commands, or events.
4. Execution:
   • Run the Fasti worker alongside Laravel’s queue worker:

     php artisan fasti:run
     

   • For production, use a process manager (Supervisor) to ensure uptime.
5. Monitoring:
   • Add logging for scheduled/canceled jobs (extend FastiServiceProvider).
   • Integrate with Laravel Horizon or a custom dashboard to track pending jobs.

Operational Impact

Maintenance

• Package Updates: MIT-licensed; updates are straightforward (composer update). Monitor for breaking changes in minor releases.
• Customization:
  • Extend job repositories (e.g., add soft deletes, custom fields) by overriding FastiJob model.
  • Modify the worker logic (e.g., add rate limiting) by publishing and extending the worker class.
• Documentation: Lightweight README; may need internal docs for team onboarding (e.g., "How to schedule a job for a user’s birthday").

Support

• Debugging:
  • Use php artisan fasti:list to inspect pending jobs.
  • Check fasti_jobs table for stuck/canceled jobs.
  • Log job execution context (e.g., user ID, scheduled time) for traceability.
• Common Issues:
  • Jobs not running: Verify the Fasti worker is running and the queue connection is healthy.
  • Timezone mismatches: Ensure all scheduled times are in the expected timezone.
  • Duplicate jobs: Add unique constraints or idempotency checks in jobs.
• Vendor Support: Community-driven; issues should be raised on GitHub. No SLAs.

Scaling

• Horizontal Scaling:
  • The fasti_jobs table is the bottleneck. Partition by scheduled_at for large-scale deployments.
  • Distribute the Fasti worker across multiple servers (use a shared DB or queue for coordination).
• Performance:
  • Worker Load: Each worker instance processes jobs sequentially. Scale workers linearly with job volume.
  • Database Load: Batch inserts for bulk scheduling (e.g., Fasti::scheduleMany()).
  • Queue Backpressure: Monitor queue depth to avoid worker starvation.
• High Availability:
  • Ensure the database and queue are HA (e.g., Redis Cluster, PostgreSQL streaming replication).
  • Use a process manager (Supervisor/Cron) to restart workers on failure.

Failure Modes

Ramp-Up

• Developer Onboarding:
  • 1–2 hours: Install, configure, and schedule a test job.
  • 1 day: Integrate with existing job classes and test edge cases (e.g., canceled jobs, timezone offsets).
• Team Training:
  • Document when to use Fasti vs. Laravel’s scheduler (e.g., "Use Fasti for ‘send email at 3 PM’, use scheduler for ‘daily at 3 PM’").
  • Train on debugging tools (fasti:list, logs, queue monitoring).
• Release Strategy:
  • Canary Release: Start with a subset of non-critical jobs.
  • Rollback Plan: If issues arise, revert to manual scheduling or external tools.