DEV Community: omaxtech

How to Add LiveKit Video Calling to a Next.js App

omaxtech — Tue, 13 Oct 2026 15:51:00 +0000

Building Embedded Video & Audio Calling with LiveKit Cloud, Next.js, and Laravel

We needed video and audio calls directly inside the product—not another third-party Zoom link. This is how we compared LiveKit with Twilio, Daily, Agora, and Zoom, and then wired LiveKit Cloud into a Next.js client and a Laravel API.

Most products do not have a video problem. They have a meeting-link problem.

A customer books a session in your app. You paste a Zoom or Google Meet URL into an email. They leave your product, wait in someone else’s lobby, and when the call ends, you still do not own the recording, the attendance data, or the next click. That is fine for an internal standup. It is a leak if calling is part of the core product.

We closed that leak with LiveKit Cloud: a Next.js client for the call UI, our existing Laravel API for users and permissions, and LiveKit for the media layer. This post covers both the architectural decision and a working map of the integration—enough for another developer to follow the same shape in their own stack.

"A third-party meeting link is a meeting in someone else’s product. Embedded video is a feature of yours."

What This Post Covers

Why product teams embed video calling instead of sending users to Zoom or Meet.

How LiveKit compares with Daily, Agora, Twilio, Vonage, Amazon Chime, Zoom, and self-hosted SFUs.

Cloud vs. self-hosted LiveKit and why we started on Cloud.

The core code terms you will encounter: SFU, adaptive streaming, dynacast, rooms, and tokens.

The architecture and actual code snippets used to join a call, handle audio vs. video, support guests, and manage recordings.

How LiveKit bills participant-minutes (e.g., a 1-minute call with 5 people equals 5 WebRTC minutes).

Why Embed Video Calling Instead of a Zoom Link?
The fastest way to ship "video" is a third-party URL. Users already know Zoom, Meet, and Teams, and support teams know how to troubleshoot them. However, the hidden cost of that convenience shows up later:

You lose the session: Notes, files, billing, and the next user action now live in another app under another brand.

You lose access control: Your API already knows who paid, who is the host, and who is a guest. A shared meeting link does not.

You lose the recording: It sits in the vendor’s history instead of next to the customer’s record in your database.

You lose conversion: Opening Zoom, signing in, and waiting for the host introduces friction and drop-offs.

An embedded video and audio call keeps the user inside the product. They are already logged in, the UI matches the rest of the app, and when the call ends, they remain on your page.

Building that from raw WebRTC requires managing media servers, TURN relays, reconnects, and recordings. We didn't want to become a telecom company. We wanted native calling in Next.js, with our existing backend maintaining strict control over who can join. That is the exact gap a platform like LiveKit fills—and it is the kind of robust feature our custom software development services are built for.

LiveKit vs Zoom, Twilio, Daily, Agora, and the Rest

The 2026 shortlist for putting video calling into an app is straightforward. We scored platforms based on escape hatches, developer experience, cost shapes for 1:1 and small groups, and whether recordings could land in storage we already own.

Daily.co: A pleasure to integrate, billing roughly $0.004 per participant-minute after a free bucket. If the goal is a call on screen by lunch, it wins. It is a weaker escape hatch if you later want the media server under your own roof.

Agora: Features a serious global mesh, especially in APAC. Audio looks cheap, but HD and Full-HD rates climb quickly. The stack is proprietary—fine if you are buying coverage, less fine if you want an open protocol.

Twilio Video & Vonage Video: The familiar CPaaS path. Video is a separate product and a separate bill. Vonage (the old TokBox lineage) is a closer enterprise drop-in at around $0.0041 per minute. Both are closed SFUs.

Amazon Chime SDK: Attractive if everything else is already on AWS at roughly $0.0017 per attendee-minute with one invoice and a clearer HIPAA story, though developer experience lags specialists.

Zoom Video SDK:
Embeds Zoom directly. Fine if you want Zoom's brand and large-session muscle, but you are building on their product rather than an open protocol.

mediasoup, Janus, or Jitsi: Puts you directly in the media-server business. A valid choice if you want to run an SRE rotation for one-way audio at 2 a.m., but not what we needed this quarter.

Why LiveKit Won

We picked LiveKit because its trade-offs matched a product team rather than a telecom team:

Cloud and self-hosted speak the same protocol: We could ship on *.livekit.cloud without a vendor-only client API. If data residency or unit economics later demand it, the same Next.js code can point at a server we operate.

The React kit is a starting point, not a prison: Stock components got a conference on screen quickly, allowing us to replace the chrome without rewriting WebRTC.

Grants matched the product: An audio call is a publish-source list. Guests are a different identity, but hosts and guests join the same room cleanly.

Recordings land in our bucket: Cloud egress writes a grid layout straight to the S3 bucket we already use.

The cost shape fits 1:1 and small groups: Connection minutes range between $0.0004–$0.0005 plus bandwidth as long as HD send and recording are monitored.

Cloud LiveKit vs. Running Your Own Server

LiveKit is an open-source realtime media server with client SDKs for web and mobile. You can run it in two ways:

Self-hosted: You operate livekit-server on Kubernetes or VMs, plus TURN for firewalls. At very high volume, this beats any vendor invoice. If you already scale infrastructure this way, our DevOps services run Kubernetes workloads day-to-day.

LiveKit Cloud

: A managed project WebSocket URL, API keys, a global edge network, and dashboards. You pay a monthly plan plus usage and skip managing the SFU yourself.

How LiveKit Works: SFU, Adaptive Streaming, and Dynacast

What is an SFU? A Selective Forwarding Unit is a media server in the middle of a call. Instead of every participant uploading multiple streams in a group call, each person uploads once, and the server forwards streams to everyone else.

What is adaptive streaming? The client matches video quality to the size of the video tile on screen. Small thumbnails do not request 720p, saving significant bandwidth.

What is dynacast

: The publisher and SFU stop encoding quality layers that no active subscriber is watching.

Turn both options on in your room options; they are the difference between a clean demo and an unmanageable bandwidth bill.

The Architecture

: Next.js, Your API, and LiveKit Cloud
The product creates a session and a unique room name (e.g., call-{uuid}).

When a participant is authorized, the API signs a JWT and returns { token, server_url, room_name, identity }.

Next.js passes the token and URL into LiveKit’s LiveKitRoom component.

WebRTC handles media over wss://...livekit.cloud. Audio and video never transit your application servers.

Integration Code Snippets

1. Install the SDKs

JSON
"@livekit/components-react": "^2.9.21",
"@livekit/components-styles": "^1.2.0",
"livekit-client": "^2.19.2"
2. Keep Credentials on the Server (config/livekit.php)
PHP
return [
    'url'        => env('LIVEKIT_URL'),
    'api_key'    => env('LIVEKIT_API_KEY'),
    'api_secret' => env('LIVEKIT_API_SECRET'),
    'token_ttl'  => (int) env('LIVEKIT_TOKEN_TTL', 3600),
];
3. Fetch Token on the Client (app/services/calls.ts)
TypeScript
export type LiveKitTokenResponse = {
  token: string;
  server_url: string;
  room_name: string;
  identity: string;
};

export async function fetchCallToken(callId: string) {
  const response = await apiClient.get<{
    success: boolean;
    data: LiveKitTokenResponse;
  }>(`calls/${callId}/token`);
  return response.data.data;
}

4. Create Room and Mint Token (CallService.php)

PHP
$roomName = 'call-' . Str::uuid()->toString();
$call = VideoCall::query()->create([
    'room_name' => $roomName,
    'status'    => CallStatus::Ringing,
    'mode'      => $mode, // video | audio
]);

$identity = 'user-' . $actor->id;
$videoGrants = [];
if ($call->mode === CallMode::Audio) {
    $videoGrants['canPublishSources'] = [
        'microphone', 'screen_share', 'screen_share_audio',
    ];
}

$token = $this->liveKitTokenService->createToken(
    $call->room_name,
    $identity,
    $actor->name ?? 'Participant',
    $videoGrants
);
5. Connect the Next.js Room (VideoSession.tsx)
TypeScript
const roomKey = callId ?? token.slice(0, 12);

<LiveKitRoom
  key={roomKey}
  token={token}
  serverUrl={serverUrl}
  connect
  video={false}
  audio={false}
  connectOptions={{ autoSubscribe: true }}
  options={{ adaptiveStream: true, dynacast: true }}
  onDisconnected={onDisconnected}
  data-lk-theme="default"
>
  <PublishLocalTracks mode={callMode} />
  <CallConference onEndCall={endCall} />
</LiveKitRoom>

What LiveKit Cloud Costs

LiveKit bills by participant-minutes (one person connected for one minute). For instance, a 1-minute call with 5 people accounts for 5 WebRTC minutes.

Build ($0/mo): Development tier, no card required.

Ship (from $50/mo): Production use, email support, includes ~150,000 WebRTC minutes (then ~$0.0005/min).

Scale (from $500/mo): Region pinning, HIPAA BAA, includes ~1.5 million minutes (then ~$0.0004/min).

Bandwidth:

Billed separately around $0.10–$0.12 per GB after your included bucket.

Closing

Embedded video calling is not a quick widget you drop in after lunch, but it shouldn't require running a dedicated media cluster yourself. LiveKit Cloud strikes the ideal middle ground: managed WebRTC infrastructure, secure JWT tokens minted via your API, and fully customizable React components.
Originally posted by Omax Tech

AI Writes the Code • Stop Blindly Shipping It Without Reviewing the Engineering

omaxtech — Mon, 12 Oct 2026 14:02:41 +0000

The Problem: AI Makes Coding Faster, Not Engineering Automatic
AI has changed how quickly we can write software.

Give an AI coding tool a requirement, describe the expected behavior, and within seconds you can have a working implementation. Functions are generated, APIs are connected, database queries are written, tests are suggested, and sometimes an entire feature can be scaffolded before you have finished your coffee.

That sounds like a huge win. And it is. But there is a problem.

We are getting very good at generating code, while becoming dangerously comfortable with not reviewing the engineering behind that code.

A feature can work perfectly in development and still be badly engineered. It can pass tests and still create unnecessary database queries. It can produce the correct response and still introduce duplicated business logic. It can solve today's requirement and make the next requirement significantly harder to implement.

This is where the conversation around AI-generated code needs to change.

The question shouldn't simply be:

"Does the AI-generated code work?"

The better question is:

"Is this the right engineering solution?"

AI Is Extremely Good at Producing Code
Modern AI coding tools are surprisingly capable. They can understand existing files, follow patterns, generate functions, refactor components, write SQL, create API endpoints, and even make changes across multiple parts of an application.

For developers, this can remove a lot of repetitive work. Instead of spending 30 minutes writing boilerplate, you can describe what you need and have a starting point almost immediately.

That part is great. The danger begins when developers treat generated code as a finished engineering solution simply because it compiles and produces the expected result.

Compilation is not architecture.
Passing tests is not scalability.
Working code is not automatically good code.

AI is optimizing for the implementation it believes satisfies the request. It doesn't automatically understand every architectural decision your application has accumulated over years of development. Even when it understands the codebase, it may still choose a solution that is locally correct but globally expensive.

The "It Works" Trap
One of the easiest traps with AI-generated code is the phrase: “It works.”

Imagine you ask AI to implement a feature that needs to process 1,000 employees. The generated implementation may:

Fetch employees

Loop through them

Make another database query for each employee

Perform additional API calls inside the loop

Transform the data

Save the results individually

With a small development dataset, everything looks fine. The feature works. The tests pass. The ticket can be marked complete.

Then production gets real data. Suddenly, a process that worked perfectly for 20 employees becomes painfully slow for 20,000.

The problem wasn't necessarily that the AI generated invalid code. The problem was that nobody reviewed the engineering implications of the generated solution.

Engineering Questions Developers Must Ask:
Can this query be optimized?

Am I creating an N+1 query problem?

Can these records be processed in batches?

Can I reduce the number of API calls?

Should this operation be asynchronous?

What happens when the dataset becomes 10× larger?

What happens when multiple users trigger this simultaneously?

These are engineering questions. And they cannot always be answered by simply checking whether the generated code produces the expected output.

AI Can Write More Code Than You Actually Need
Another common problem is unnecessary complexity.

Ask AI to implement a relatively simple requirement, and you may receive a solution containing multiple helper functions, abstractions, configuration objects, defensive checks, wrappers, and layers of logic that weren’t actually necessary.

Individually, every piece may look reasonable. Together, they can create a system that is harder to understand than the original problem.

This is especially dangerous because generated code often looks professional: good naming, clean formatting, type definitions, comments, and reusable functions. Everything appears polished. But clean-looking code can still be over-engineered.

Sometimes the best engineering solution is not another abstraction. Sometimes it is simply a small function that does one thing clearly.

The Real Test Is Often Production
Development environments are forgiving. Datasets are smaller. Traffic is lower. Fewer users are performing operations simultaneously.

Production is where engineering decisions become visible. A solution that looks perfectly reasonable during development can behave very differently when:

Thousands of records are processed simultaneously

Database traffic spikes unpredictably

External APIs become slow or rate-limited

Memory usage grows unexpectedly

Background jobs overlap and cause race conditions

This is why AI-generated code deserves the same engineering review as code written by another developer. In fact, it deserves more scrutiny because it can be produced so quickly that the temptation to merge it without deeply understanding it is much higher.

AI Should Accelerate Engineering • Not Replace It
The goal shouldn't be to stop using AI. Quite the opposite. We should use it aggressively where it provides value.

Let AI handle repetitive implementation, generate boilerplate, suggest approaches, write initial drafts, investigate bugs, generate tests, and explain unfamiliar code.

But when the code is generated, the engineer still owns the decision:

Why is this implemented this way?
Does this fit our architecture?
Will this scale?
Are we introducing duplication?
Are we making the next change harder?
What happens when this fails?
What happens when the data grows?
AI doesn't eliminate the need for engineering judgment. It makes it more critical.

The Developer's Role Is Changing
AI doesn't make developers less important; it changes where their value is applied.

When writing every line manually was the bottleneck, programming skill was heavily associated with syntax speed. With AI, producing those lines is becoming cheap.

Higher-level skills are now paramount: understanding systems, making architectural decisions, recognizing trade-offs, reviewing code, thinking about failure modes, and knowing when the simplest solution is the better solution.

AI Writes the Code, Engineering Still Owns the Decision.

When the code writes itself, engineering teams must focus on architectural ownership, performance tuning, and scalable design. If you're looking to scale your engineering team with senior architecture oversight, feel free to explore Omax Tech for specialized engineering and custom software development solutions.

Originally posted by Omax Tech