Laravel web
application development
in Cambridge

A growing Laravel application soon needs to tell someone about something. An invoice was paid. A job finished. A comment arrived. The instinct is to send an email from inside the controller that handles the event, then move on. That code works for a while. Then it quietly multiplies. Every feature ends up with its own message text, its own queue decision, its own retry logic scattered through the codebase.

A notification class collects the message and its destinations in one place. It can define what the payload looks like for mail, for a database row, and for a chat webhook. No wording gets written three separate times. The receiving model decides, through its own stored preferences, which of those channels actually fire for a given event.

The mail channel benefits most from a template built with reusable components rather than raw markup. A heading, a button and a footer then stay visually consistent across dozens of notification types. Queuing the mail send matters here. A slow outgoing mail server should never make a person wait on a page that has nothing to do with email.

A database channel stores each notification as a row with a type and a small structured payload. That table is what powers the bell icon and the short list of recent events a person opens after logging in. This is a separate concern from an audit log. The notifications table is meant to be trimmed and marked read, not kept forever as a compliance record.

A chat channel, wired to an internal webhook, turns backend events into something a team actually watches. A failed payment. A queue that stopped processing. An integration that started rejecting requests. These messages are written for a different audience than the ones sent to an end user, so a shared notification class needs a way to format its body differently for each destination.

Sending the same notification to a wide list of recipients deserves batching. Every subscriber of a plan change, for example. A blunt loop that fires one notification per recipient inside a single request will eventually time out. Pushing the whole batch onto the queue, and letting background workers spread the load, keeps the original request fast.

Preferences complicate the picture quickly. A person who muted email but kept the in-app feed still needs the event recorded somewhere. So the notification class has to check a preference table before deciding which channels to call, rather than assuming every channel is always wanted by everyone.

Testing this layer is straightforward once the notification classes stay small. A fake notification sender lets a test assert that a particular class was queued for a particular recipient. No actual message leaves the system during the run. Skipping that step tends to mean the first real proof a notification works is a support message asking why it never arrived.

None of this needs to be built before it is needed. But sketching the channel map early, mail for a record, a feed for a glance, chat for an alert, saves a rewrite once the second and third channel get requested by different parts of the business.

At some point a Laravel backend stops being used only by its own front end. A partner wants to pull data through an endpoint. A mobile client needs to authenticate without a browser session. An internal script has to run on a schedule against the same API. Each caller needs a way to prove who it is that has nothing to do with a login form.

A personal access token tied to a specific caller is the starting point, rather than a shared secret copied between systems. Every token can carry its own label. Every token has its own creation date. A token that stops being needed, or turns out to have leaked, can be revoked on its own without touching any other integration.

Scoping the token matters as much as issuing it. A reporting tool that only ever reads order totals should hold a token that can read orders and nothing else. Not the same access as an internal dashboard. Abilities attached to a token let an endpoint check, before running a query, whether the caller was ever meant to reach it.

Expiry is easy to forget and expensive to fix later. A token with no expiry, issued long ago for a project that has since changed hands, is a door nobody remembers exists. Setting a sensible lifetime, with a process for renewing it, turns token management into routine maintenance. Not an emergency audit.

Rate limiting sits next to authentication rather than replacing it. A valid token still needs a ceiling on how often it can call an endpoint. Partly to protect the database from a caller with a bug in its polling loop. Partly to make a stolen token less useful if that ever happens. Throttle rules can differ per token type, tighter for a public integration than for an internal service.

Logging which token performed which action turns a vague complaint, the data came back wrong, into a traceable event. A timestamp and a token identifier attached to each request is usually enough to reconstruct what happened. No need to keep the full request body around longer than necessary.

A separate concern is the shape of the response handed to an external caller versus an internal one. A resource built for a partner should hide fields that only make sense inside the product. Pricing internals. Staff notes. Half finished records. Hidden, all of them, even when the underlying model exposes them everywhere else in the codebase.

Rotating a token that a partner already depends on is a coordination problem more than a technical one. Issue the new token first. Then revoke the old one. Give the other side a window to switch. That avoids a hard cutover that breaks a working integration at a moment nobody was watching for it.

A short document listing every active token, who holds it, and what it can reach changes the picture completely. It turns this from something only one developer remembers into something the rest of the team can check, before a request for a wider integration gets approved without anyone noticing the risk involved.

Some pages need to know something changed while a person is still looking at them. An order moved to the next stage. A colleague joined the same document. A long running import finished. Polling the server every few seconds for this kind of update is simple to write and expensive to run at any real scale.

Broadcasting an event from the backend the moment something changes turns this problem around, rather than waiting for the next request. The server pushes a message onto a channel the moment the underlying action happens. Any browser subscribed to that channel receives it within a moment. No polling loop is required on either side.

Channels need a boundary that matches who is allowed to see the update. A private channel tied to a single account keeps one account from listening in on another. A channel scoped to a shared resource, a document, a project, an order, lets everyone working on that resource hear about it together.

Authorizing a channel is a small piece of code. It still deserves the same care as any other access check. Skipping the authorization callback because it seemed to work fine during testing tends to surface later as a private update arriving somewhere it should never have reached.

Not every change belongs on a broadcast channel. A minor field edit that nobody is watching for adds noise and cost for no benefit. A state change that a person is actively waiting on, a payment clearing, a file finishing processing, is exactly the kind of event worth pushing. Choosing which events broadcast is a product decision as much as a technical one.

The browser side of this needs a plan for the moment a connection drops. A laptop goes to sleep. A network switches from wifi to a phone signal. A client that silently stops receiving updates after a disconnect looks, to the person using it, like the feature quietly stopped working, rather than like a dropped connection that reconnected without telling anyone.

Queued broadcast events share infrastructure with other background jobs, so a slow queue affects how quickly a live update actually arrives. A dashboard that promises an instant update but sits behind a backlog of unrelated jobs will feel slow. That kind of slowness is hard to diagnose without looking at the queue itself.

Testing broadcast logic without standing up a full socket server during a test run is possible. Fake the broadcast layer. Assert that the right event was dispatched with the right payload. Leave the transport itself to a separate, smaller check run against a real environment.

Once a page depends on a live channel, it needs a fallback for the case where the connection never opens at all. A strict network. A blocked port. An old browser. Falling back to a manual refresh option keeps the page usable even for the visitor whose environment quietly rejects the live connection.