A customer portal can need the feel of an interactive application without needing a separately maintained API for its own frontend. Inertia connects those two requirements: a JavaScript interface with Laravel continuing to handle server-side routing and application logic.1
Inertia 2’s December 2024 release expands that approach with asynchronous requests, deferred props, prefetching and polling. The business decision is whether those capabilities fit the portal and the team that will maintain it.
Building a separate API for one tightly connected interface can feel like installing a customs checkpoint between two desks. There may be a very good reason for the boundary. It’s worth knowing what that reason is before ordering the uniforms.
Choose Inertia when the portal is one connected product
Consider a fictional wholesale portal where customers submit purchase orders and check their status. The application needs forms, validation, account permissions and views that update as work progresses.
Inertia can let a team build that interface in React, Vue or another supported frontend framework while retaining Laravel’s server-led application structure.2 The frontend still needs proper engineering; the connection simply avoids having to design a separate API product solely to deliver its pages.
Load the important part first
A purchase-order screen might need the order’s status immediately, while a detailed activity history can arrive afterward. Inertia 2’s deferred props support that distinction.
The design still needs to define what is essential. A customer shouldn’t be invited to approve an order while the price information required for that decision is still loading.
An unavailable secondary section also needs an honest error state. “The page appeared quickly” is not much consolation if the one figure everyone needs has quietly opted out.
We design and build custom web portals and dashboards for exactly this kind of work.
Update deliberately rather than constantly
Polling can refresh a status at an interval. Prefetching can fetch likely next-page data before navigation. Both can make interactions feel more responsive when used selectively.
They also create work. A portal that repeatedly refreshes every panel for every user may increase backend load without helping anyone make a decision.
For our example, refresh an order while it is actively progressing, show when the displayed information was updated and define when polling should stop. Prefetch the next screen only where the likely benefit justifies the request. Enthusiasm is not a cache policy.
Keep a separate API when it serves a real boundary
The equation changes if the same capabilities must support mobile apps, independent partner systems or several frontends with different release schedules.
Then a deliberate API can provide a stable contract beyond the web portal. It needs authentication, versioning, documentation, error behavior and ongoing ownership. Those are worthwhile responsibilities when several consumers depend on them.
An Inertia application can still expose APIs for outside integrations. Choosing Inertia for the portal does not mean every other system has to communicate through its pages.
It also doesn’t automatically create a reusable public API. The data sent to a page should be designed for that page and filtered for the current user’s permissions. Sending an entire record because the interface might eventually need it is a poor substitute for deciding what the customer may see.
Pairs well with The customer portal is where the service becomes real.
Keep simpler pages simple
A server-rendered Laravel interface may be enough when the work consists of ordinary pages and straightforward forms.3 Adding a JavaScript framework introduces its own skills, dependencies and testing needs.
The comparison should include the actual interactions and the team’s comfort maintaining them. A modest portal with a reliable, understandable implementation can be a better business asset than a more sophisticated design nobody wants to touch.
| Fits when | Takes on | |
|---|---|---|
| Inertia | One connected web portal with forms, validation and live status | Frontend engineering skills, plus deliberate polling and prefetching |
| A separate API | Mobile apps, partners or several frontends need a stable contract | Authentication, versioning, documentation and ongoing ownership |
| Server-rendered pages | The work is ordinary pages and straightforward forms | No JavaScript framework to maintain |
Zulu Shack recommends writing down the demanding interactions before choosing the frontend architecture. Identify which screens genuinely need richer behavior, which data must update and which outside consumers need a stable integration contract.
For the fictional wholesale portal, Inertia is a strong candidate if those needs center on one web application. A separate API earns its place when independent consumers need it. Basic server-rendered pages remain a good choice where they do the job.
The middle ground is useful because it gives the team a choice. We can build the portal people need without making the architecture audition for a much larger company.