Nuxt development services

Nuxt is the web client. Customer portals, staff tools, and the public pages around them are Vue applications rendered with Nuxt, and they communicate with a Laravel API. It covers both authenticated screens and public pages that need a stable URL, a title, and markup suitable for search and sharing.

This site is a Nuxt application. We use the same framework when the interface is the product, rather than a marketing site alone.

Start a conversation about a Nuxt frontend, or read Project initiation.

At a glance

When we use it

• Customer and staff portals, including catalogues, orders, accounts, and administration
• Authenticated applications that should remain responsive after the first load, without a separate technology stack for each feature
• Public pages that belong to the product, such as a catalogue, a status page, or a landing route, and should be rendered for search and sharing
• A web client alongside a Flutter application, both using one API

A single marketing page with no application behind it is a poor fit for this work. That is consistent with the services described on the homepage.

What we rely on

• File-based routes, so the URL structure is visible in the project
• Server and client rendering chosen per route: public pages rendered for readers and search engines, and authenticated routes treated as an application
• A typed client for the Laravel API, so a changed field is visible in review
• Tailwind CSS and a component set for screens that recur
• Data fetching with a loading state, an empty state, and an error state

Why it fits the work

• First load and later navigation. Public routes can be rendered before they reach the browser. Inside the portal, navigation stays in the application rather than rebuilding each page from scratch.
• One frontend as the product grows. New areas of the portal are added as routes and components, rather than as a separate site.
• A smaller amount of sensitive logic in the browser. Tokens, permissions, and business rules stay on the API. The frontend displays what the API allows. It does not become a second implementation of those rules.
• A conventional Vue codebase. A developer who knows Nuxt can continue the work. The interface is styled with Tailwind CSS, which is widely used, rather than a private styling system.

How we build with it

The engagement follows Project initiation. On a Nuxt project, that work includes the following.

• Architecture. Which routes are public, which require a session, and what the API must return. The frontend is designed against that contract.
• Development. Components for screens that recur, and a single API client. Type checking and linting in continuous integration make contract changes visible in review.
• Hardening. Authentication redirects, no secrets in client code, and forms that report errors clearly. Caching headers are set for Cloudflare, not only for a local preview.
• Release and support. The frontend can be deployed separately from the API when that separation is useful, and each remains releasable on its own. After launch, additional workflow is added as routes.

How it sits in the stack

Nuxt is the web client. Laravel is the API and the system of record. Tailwind CSS provides the styling. Cloudflare terminates TLS and caches responses that are safe to cache. AWS is where the API runs. The browser does not connect to MySQL.

A Flutter application, where one is required, uses that same API.

In practice

dCommerce is the reference: a customer portal and administration interface in front of a Laravel platform, including catalogue, pricing, and order flows. This marketing site is a smaller Nuxt application in the same framework family. Client portals follow that division of responsibilities, scoped to their process.

Questions

Is Nuxt a good fit for a large portal, or only for content sites?

It is a good fit for a portal. Content rendering is one mode. Authenticated application routes are the other, and they are the larger part of the work we do. Using one rendering strategy for every screen is usually the wrong choice.

Should the frontend and the API be one repository?

It depends on how the work is released. Separate repositories are easier when the API also serves Flutter, or when different people release the two parts. One repository is easier when the same team owns both and the contract changes frequently. The choice follows the release process.

Can you rebuild a frontend without replacing the backend?

Yes, when the backend already exposes a stable API. If the current interface contains the business rules, those rules need to move before the new screens reproduce them.

Next step

For a portal, a stalled frontend, or a public site that has to sit on an application, start a conversation.

Related: Laravel, Tailwind CSS, Cloudflare, Technology.