Webinar Laravel Package

Technical Evaluation

Architecture fit. EscolaLMS/Webinar is a modular Laravel package belonging to the EscolaLMS (Wellms) LMS suite. It follows the ecosystem's conventions: a service provider for registration, publishable config and migrations, Eloquent models with repository/contract bindings, API resources, and permission gating via the shared auth/roles layer. It is designed to be dropped into an existing EscolaLMS application rather than run standalone, so it fits well only if the surrounding LMS platform (users, courses, notifications, payments) is already in place or planned.

Integration feasibility. Installable via Composer with config/migration publishing; requires a video-conferencing provider (Zoom/Jitsi-style) credentials plus webhook/callback routes, queued jobs for reminders and lifecycle transitions, and scheduler entries. Release 0.1.44 ("Added order by", PR #83) is an additive change to query/sort behaviour on listing endpoints — no contract removal, no migration or config signature change signalled. Integration effort is dominated by provider setup and permission/role wiring, not by this release.

Technical risk.

• Pre-1.0 stability: the package is on 0.1.x with frequent patch releases; no SemVer guarantee, so patch bumps can carry behavioural change. Pin exact versions.
• Sorting surface (new in 0.1.44): user-supplied order by on list endpoints is a classic injection/performance vector. Verify the implementation whitelists sortable columns and validates direction before it reaches ORDER BY; unbounded sort columns can also force filesorts on large attendance tables.
• External dependency: the video provider's API, OAuth token lifecycle, and rate limits are the dominant runtime risk, not the PHP code.
• Ecosystem coupling: loose constraints against EscolaLMS core packages can produce resolution conflicts; maintainer concentration and unknown test coverage raise bus-factor risk.

Key questions.

1. Which video provider(s) are supported, and is a sandbox/test tenant available?
2. Does 0.1.44 restrict order by to an allow-list of columns, and how does it interact with pagination and existing filters?
3. What are the exact PHP/Laravel/core-package version constraints, and is there a supported upgrade path from earlier 0.1.x?
4. Are webhook handlers idempotent (duplicate/replayed provider callbacks)?
5. What is CI/test coverage, and is there a published changelog/breaking-change policy?
6. Which permissions/policies ship by default, and how do they map to existing roles?

Integration Approach

Stack fit. Assumes Laravel (9/10-class) on PHP 8.x, MySQL/Postgres, Redis-backed queues, and the Laravel scheduler. Operationally it needs queue workers for reminders/notifications and a publicly reachable endpoint for provider callbacks. It slots into an EscolaLMS monolith or a modular service alongside Courses, Users, and Notifications.

Migration path. Two distinct paths:

• Greenfield EscolaLMS app: add the package, publish config and migrations, run migrations, seed the package's permissions, assign them to roles, configure provider credentials and callback URLs.
• Existing LMS: integrate as an additive module behind the existing auth guard and user model; map webinar entities to courses/trainings if a linkage is expected; backfill is not required since the package owns its own tables.

Compatibility. 0.1.44 is a drop-in for ^0.1 consumers — a composer update suffices, with no data migration. The compatibility work is horizontal: align core EscolaLMS package versions and confirm the new sort parameters don't conflict with existing front-end query strings or cached list responses.

Sequencing.

1. Pin the package and its core dependencies; capture licence and maintenance signals.
2. Staging install with provider sandbox credentials; verify callback reachability.
3. Auth/permission mapping and role seeding; smoke-test CRUD as each role.
4. API contract tests, explicitly covering the new sorting parameters (valid, invalid, injection-shaped, unindexed columns).
5. Add DB indexes for the newly sortable columns before exposing them in UI.
6. Front-end adoption of sort controls; verify pagination totals remain stable.
7. Load test sorted list endpoints at expected attendance volume.
8. Production rollout behind a feature flag with a rollback to the previous pinned version.

Operational Impact

Maintenance. Low effort per release given the narrow scope, but high attention: 0.1.x ships frequently and patch-level changes can alter behaviour. Establish a monthly upgrade cadence, read each changelog, and upgrade staging first. Budget for occasional dependency-resolution work when core packages move.

Support. Requires a runbook covering provider outages, expired or revoked OAuth tokens, webhook failures and replays, and manual webinar state correction (cancel/reschedule) when automated transitions misfire. Support staff need admin visibility into webinar-to-provider session mapping; without it, every attendee issue escalates to engineering.

Scaling. The main pressure points are attendee/registration tables and list endpoints. Sorting added in 0.1.44 makes index coverage a prerequisite, not an afterthought — unindexed sort columns will degrade as attendance rows grow. Watch for N+1 queries when hydrating attendees and presenters, push reminders and notifications onto dedicated queues, and consider archiving past webinar attendance rather than retaining indefinitely.

Failure modes.

• Provider API rate limiting or timeout during bulk registration/reminder bursts.
• Webhook duplication producing double attendance records or duplicate notifications (idempotency keys required).
• Queue backlog during deploys causing missed reminder windows.
• Scheduler not running in a containerised deploy, silently skipping lifecycle transitions.
• Slow list queries after sort parameters are exposed without supporting indexes.
• Composer constraint drift breaking a routine composer update on a patch bump.

Ramp-up. A competent Laravel developer reaches productivity in roughly one to two days on the package itself; the longer curve is domain literacy — LMS entity relationships, permission model, and provider semantics — plus reading the EscolaLMS conventions. Because documentation for the wider suite is uneven, plan for source-reading time and designate one engineer as the package owner for upgrade triage and provider troubleshooting.