Discussion

This final page collects the questions that come up after the first project works. They are discussion prompts rather than rules; the right answer depends on the team, the traffic, and the lifetime of the application.

How much structure does a small application need?

Laravel works with thin controllers and Eloquent models for a long time. Service classes, actions, and repositories become useful when logic is reused, tested in isolation, or spread across entry points. Adding those layers before the need appears makes a small codebase harder to navigate.

When should logic leave the controller?

Move logic when a controller action no longer fits on one screen, when the same operation is triggered by a command or a job, or when it needs focused tests. A form request handles validation and authorization; a job handles slow work; a policy handles permission; everything else can stay in the controller until it grows.

Eloquent or the query builder?

Use Eloquent for domain records with behavior and relationships. Use the query builder for reports, bulk updates, and queries that would produce awkward model hydration. Mixing both is normal; consistency within a feature matters more than a global rule.

How should errors be presented?

Validation errors belong next to fields. Authorization failures should look like a missing page or a clear permission message. Unexpected failures need a generic page plus a logged request identifier. Avoid exposing exception messages, SQL, or stack traces to visitors.

What belongs in a test?

• Feature tests for routes, validation, authorization, and redirects.
• Unit tests for calculations, policies, and value objects.
• One or two tests for each critical business rule, not every getter.
• A smoke test for the pages that generate revenue or hold customer data.

How do you keep dependencies healthy?

Commit the lock file, review updates in a branch, run the suite, and deploy to staging. Watch for abandoned packages and security advisories. A dependency that is no longer maintained is a future incident even if it works today.

What does production readiness mean?

• APP_DEBUG=false, a stable APP_KEY, and correct APP_URL.
• Cached configuration, routes, and views after deployment.
• Queue workers and the scheduler running under a process supervisor.
• Backups for the database and uploaded files, with a tested restore.
• HTTPS, secure cookies, rate limits on authentication, and least-privilege database credentials.
• Logs and error alerts that a person actually monitors.

Where to go after this course

Build a complete application, then read the framework source for the features you use most. Contribute a fix to a package you depend on. Teach a topic to a colleague; explaining a concept exposes the gaps that reading alone leaves behind.