Sendportal Core Laravel Package

Getting Started

This release (v2.0.5) is a performance patch focused on two hot paths: dashboard loading and message queueing. There are no documented breaking changes, so existing integrations should continue to work. Start by confirming your installed version and clearing any cached config/views so the improvements actually take effect.

composer show <vendor>/<package>
php artisan config:clear
php artisan view:clear
php artisan cache:clear

Where to look first:

1. Dashboard performance — check the package config for dashboard-related caching, pagination, and polling settings. If the dashboard previously felt slow, re-test it after this release before adding your own caching layer.
2. Queue path — inspect how the package dispatches messages (job class, queue connection, queue name). Confirm your workers are running against the same connection/queue the package uses.
3. Upgrade sanity check — run your test suite and manually exercise the dashboard and a message send after upgrading.

First use case: open the dashboard with realistic data volume and send a small batch of messages through the queue. Compare timing against your previous version. This gives you a baseline for whether the release improves your specific workload.

Implementation Patterns

Let the package own its performance path. Since v2.0.5 improves dashboard loading and queueing speed internally, avoid layering heavy custom caching or custom queue logic on top before measuring. Add your own optimizations only where profiling shows a remaining bottleneck.

Dashboard access pattern. Put dashboard routes behind your existing auth/authorization middleware. If the dashboard supports polling or auto-refresh, tune the interval in config rather than patching views. For large datasets, prefer the package's pagination/filtering over loading everything and filtering client-side.

Queue configuration. Explicitly set the queue connection and queue name in config so dashboard-triggered sends and application-triggered sends land on the same queue:

// config/<package>.php
'queue' => [
    'connection' => env('QUEUE_CONNECTION', 'redis'),
    'name' => env('PACKAGE_QUEUE', 'messages'),
],

Run dedicated workers for that queue so message sending is not starved by unrelated jobs:

php artisan queue:work redis --queue=messages --tries=3 --timeout=60

Batch sends. When dispatching many messages, use batching or chunking where the package exposes it. This reduces per-message overhead and pairs well with the faster queueing in this release.

Observability. Instrument both paths so future upgrades are measurable:

• Time dashboard load with Laravel Debugbar or Telescope.
• Track queue latency and throughput with Horizon (Redis) or your queue backend's metrics.
• Log job failures and retries for the package's message jobs.

Integration tip. If the dashboard reads from the same tables your app writes to, ensure indexes exist on the columns used for filtering, sorting, and status lookups. Performance improvements in the package will not compensate for missing database indexes.

Gotchas and Tips

• Restart workers after upgrading. Queue workers hold loaded code in memory. Always run php artisan queue:restart after deploying v2.0.5, or the queueing improvements may not apply to long-running workers.
• Clear caches after config changes. Dashboard and queue behavior are often config-driven. Stale config or route caches can mask the new behavior. Use config:clear, route:clear, and view:clear in non-production environments, and rebuild caches deliberately in production.
• Do not assume the dashboard is faster for every dataset. The release improves loading, but your slow queries, missing indexes, or oversized result sets can still dominate. Profile before and after.
• Queue connection mismatch is the most common silent failure. Messages may appear "queued" but never process if the dashboard dispatches to a different connection or queue than your workers consume. Verify config and worker flags together.
• Watch for duplicate sends during retries. Faster queueing does not change retry semantics. Ensure message jobs are idempotent or use unique job constraints where duplicate delivery is unacceptable.
• Polling can hide or create load. If the dashboard auto-refreshes, a short interval can generate steady database load. Tune the interval and consider disabling auto-refresh in low-resource environments.
• Extension points. Prefer the package's published config, events, and job customization hooks over editing vendor files. If you need to alter dashboard queries or queue behavior, check for published views, config, and container bindings first.
• Upgrade discipline. Even for a patch release, run migrations check (php artisan migrate --pretend) and your test suite. Performance patches occasionally include internal query or job changes that surface in edge cases.