DEV Community: Roberto Luna

Upgrading to Next 15: End-to-End Tests and CVE Fixes

Roberto Luna — Mon, 13 Jul 2026 17:04:07 +0000

Upgrading to Next 15: End-to-End Tests and CVE Fixes

TL;DR: I upgraded the VibeCoding project to Next 15, resolving several CVEs and enhancing end-to-end tests. This technical deep-dive explores the changes made and lessons learned.

The Problem

The project was running on an older version of Next.js, which had several known vulnerabilities (CVEs) that needed to be addressed. Specifically, the project was using version 14.x, and there were several high-severity CVEs reported for this version. Additionally, the end-to-end tests were not comprehensive, and there was a need to improve test coverage.

What I Tried First

Initially, I attempted to upgrade to Next 15 using the automated upgrade tool provided by Next.js. However, this process encountered several issues, including conflicts with custom plugins and outdated dependencies.

npm install next@latest

This command updated the package.json file, but several manual changes were required to complete the upgrade.

The Implementation

The upgrade involved several key steps:

Step 1: Update `package.json` and Lockfiles

I updated the package.json file to reflect the new version of Next.js and ran npm install to update the lockfiles.

// package.json
"dependencies": {
  "next": "^15.0.0",
  // ...
}

Step 2: Resolve CVEs

I identified and addressed several CVEs reported for the previous version of Next.js. This involved updating dependencies and modifying code to prevent exploitation.

// content/2026/07/11/VS/changelog.md
## 2026-07-11 VS

### Changed
- Bumped version to 1.7.0 in `package.json`, `apps/api/package.json`, and updated lockfiles:
  - `package-lock.json` (version updated from 1.6.1 to 1.7.0)

Step 3: Enhance End-to-End Tests

I added new end-to-end tests to ensure better coverage of the application's functionality. This involved using a testing framework like Cypress to write and run tests.

// cypress/integration/dashboard.spec.js
describe('Dashboard', () => {
  it('renders successfully', () => {
    cy.visit('/dashboard');
    cy.get('h1').should('contain', 'VibeCoding Dashboard');
  });
});

Key Takeaway

The key takeaway from this experience is the importance of regularly updating dependencies and addressing known vulnerabilities. This not only improves the security of the application but also ensures compatibility with the latest features and fixes.

What's Next

The next step is to continue improving the test coverage and exploring new features in Next 15. This includes leveraging new APIs and components to enhance the application's functionality and user experience.

npm run test:e2e

By following these steps and taking a proactive approach to maintenance and testing, I can ensure the VibeCoding project remains secure, efficient, and scalable.

vibecoding #buildinpublic #nextjs #security

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-07-12

#playadev #buildinpublic

Updating Dependency Lockfiles for a Monorepo Project

Roberto Luna — Sun, 12 Jul 2026 15:48:54 +0000

Updating Dependency Lockfiles for a Monorepo Project

TL;DR: I updated the dependency lockfiles for the VibeCoding monorepo project to reflect the new version 1.7.0. This change involved modifying multiple package-lock.json files and updating the package.json files accordingly.

The Problem

When working on a monorepo project, it's essential to keep the dependency lockfiles up-to-date to ensure that all packages are using the correct versions of their dependencies. In our case, we had version 1.6.1, and we needed to bump it to 1.7.0. The error messages or symptoms weren't particularly alarming, but we knew that not updating the lockfiles could lead to inconsistencies and potential issues down the line.

What I Tried First

Before making any changes, I reviewed the current state of our monorepo project and identified the files that needed to be updated. I checked the package.json and package-lock.json files in each package directory (apps/api, apps/web, and the root directory). I also verified that our CI/CD pipeline was configured to handle the updates correctly.

The Implementation

To update the dependency lockfiles, I made the following changes:

Update `apps/api/package.json` and `apps/api/package-lock.json`

I updated the version field in apps/api/package.json to "1.7.0":

{
  "name": "@playamxcrm/api",
  "version": "1.7.0",
  // ...
}

Then, I ran npm install to regenerate the package-lock.json file:

{
  "name": "@playamxcrm/api",
  "version": "1.7.0",
  "lockfileVersion": 3,
  "requires": true,
  "packages": {
    // ...
  }
}

The diff for apps/api/package-lock.json showed the following changes:

-  "version": "1.6.1",
+  "version": "1.7.0",

Update `apps/web/package-lock.json`

Similarly, I updated the version field in apps/web/package-lock.json to "1.7.0":

{
  "name": "@playamxcrm/web",
  "version": "1.7.0",
  "lockfileVersion": 3,
  "requires": true,
  "packages": {
    // ...
  }
}

The diff for apps/web/package-lock.json showed significant changes due to the updated dependencies:

-  "version": "1.6.1",
+  "version": "1.7.0",
+  // many more lines added or removed

Update Root `package-lock.json`

Finally, I updated the root package-lock.json file to reflect the new version:

{
  "name": "playamxcrm",
  "version": "1.7.0",
  "lockfileVersion": 3,
  "requires": true,
  "packages": {
    // ...
  }
}

The diff for the root package-lock.json showed the following changes:

-  "version": "1.6.1",
+  "version": "1.7.0",

Key Takeaway

When working on a monorepo project, it's crucial to keep the dependency lockfiles up-to-date to ensure consistency across all packages. By updating the package-lock.json files and regenerating them using npm install, we can ensure that our project uses the correct versions of its dependencies.

What's Next

In the next article, I'll dive into the details of our CI/CD pipeline and how it's configured to handle dependency updates and deployments. Stay tuned for more insights into the VibeCoding monorepo project!

vibecoding #buildinpublic #monorepo #dependency-management

Part of my Build in Public series — sharing the real process of building Building PlayaMXCRM from Playa del Carmen, México.

Repo: zaerohell/VS · 2026-07-11

#playadev #buildinpublic

Enhancing CI/CD and E2E Testing with Sentry Integration in tvview

Roberto Luna — Sun, 12 Jul 2026 15:48:12 +0000

Enhancing CI/CD and E2E Testing with Sentry Integration in tvview

TL;DR: I integrated Sentry for error tracking and improved End-to-End (E2E) testing in the tvview project, enhancing the CI/CD pipeline. This resulted in a score increase from 85 to 95+.

The Problem

The tvview project lacked comprehensive error tracking and E2E testing, making it difficult to identify and resolve issues in production. The existing CI/CD pipeline needed improvement to ensure smoother deployments and better code quality.

What I Tried First

Initially, I focused on setting up E2E tests using Vitest, but encountered issues with the test configuration. I also attempted to integrate Sentry, but faced challenges with the DSN (Data Source Name) configuration.

The Implementation

Step 1: Configuring Sentry

To integrate Sentry, I created separate configuration files for the client, edge runtime, and server:

// sentry.client.config.ts
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: "https://385038c88b6eb6ddac52d05a144ab8c1@o4511628189630464.ingest.us.sent",
  // Additional configuration options
});

// sentry.edge.config.ts
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: "https://385038c88b6eb6ddac52d05a144ab8c1@o4511628189630464.ingest.us.sent",
  // Additional configuration options
});

// sentry.server.config.ts
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: "https://385038c88b6eb6ddac52d05a144ab8c1@o4511628189630464.ingest.us.sentry.io",
  // Additional configuration options
});

Step 2: Enhancing CI/CD Pipeline

I updated the .github/workflows/ci-e2e.yml file to include Sentry configuration and E2E testing:

name: 📺 CI + E2E — TVView

on:
  push:
    branches: [main]
  workflow_dispatch: {}
  schedule:
    - cron: "35 6 * * *"

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Install dependencies
        run: npm install

      - name: Generate Prisma client
        env:
          DATABASE_URL: "postgresql://dummy:dummy@localhost:5432/dummy"
        run: npm run db:generate

      - name: Run E2E tests
        run: npm run test:e2e

Step 3: Updating next.config.ts

I modified next.config.ts to include Sentry configuration:

import type { NextConfig } from "next";
import { withSentryConfig } from "@sentry/nextjs";

const nextConfig: NextConfig = {
  // Existing configuration options
};

export default withSentryConfig(nextConfig);

Key Takeaway

The integration of Sentry and E2E testing significantly improved the project's error tracking and code quality. A well-configured CI/CD pipeline is crucial for ensuring smooth deployments and reliable code.

What's Next

In the next iteration, I plan to focus on optimizing the E2E tests and exploring additional Sentry features to further enhance error tracking and debugging.

vibecoding #buildinpublic #Sentry #E2Etesting #CI/CD

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/tvview · 2026-07-11

#playadev #buildinpublic

Enhancing CI/CD and E2E Testing with Sentry Integration in GreenView

Roberto Luna — Sun, 12 Jul 2026 15:47:25 +0000

Enhancing CI/CD and E2E Testing with Sentry Integration in GreenView

TL;DR: This article details the technical implementation of Sentry for error tracking and end-to-end (E2E) testing enhancements in the GreenView project, focusing on the CI/CD pipeline improvements. Key changes include integrating Sentry for better error monitoring and updating the CI workflow for more robust E2E tests.

The Problem

The GreenView project faced challenges with error tracking and monitoring in production. Although the existing testing suite was comprehensive, there was a need for more integrated and proactive error tracking. Additionally, the CI/CD pipeline required optimizations to ensure smoother and more reliable E2E testing.

What I Tried First

Initially, I focused on enhancing the existing test suite by adding more test cases. However, it became clear that a more integrated solution was needed to capture errors in production effectively. I explored various error tracking tools and chose Sentry due to its seamless integration with Next.js and comprehensive error monitoring capabilities.

The Implementation

Sentry Integration

To integrate Sentry, I initialized it in three main areas: client-side, edge runtime, and server-side. This involved creating configuration files for each:

// sentry.client.config.ts
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  // Additional configuration options
});

// sentry.edge.config.ts
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  // Additional configuration options
});

// sentry.server.config.ts
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  // Additional configuration options
});

CI/CD and E2E Testing Enhancements

The CI workflow was updated to include Sentry and improved E2E testing. Key changes included adding a dummy DATABASE_URL for Prisma generation and enhancing the workflow to support E2E tests:

# .github/workflows/ci-e2e.yml
name: 🌿 CI + E2E — GreenView

on:
  push:
    branches: [main]
  workflow_dispatch: {}
  schedule:
    - cron:  "30 6 * * *"

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Install dependencies
        run: npm install

      - name: Generate Prisma client
        env:
          DATABASE_URL: "postgresql://dummy:dummy@localhost:5432/dummy"
        run: npm run db:generate

      - name: Run E2E tests
        run: npm run test:e2e

Next.js Configuration

The next.config.ts file was updated to include Sentry configuration:

// next.config.ts
import type { NextConfig } from "next";
import { withSentryConfig } from "@sentry/nextjs";

const nextConfig: NextConfig = {
  // Configuration options
};

export default withSentryConfig(nextConfig);

Key Takeaway

The integration of Sentry for error tracking and the enhancements to the CI/CD pipeline have significantly improved the reliability and maintainability of the GreenView project. A key takeaway is the importance of proactive error monitoring and the value of integrating such tools early in the development process.

What's Next

Future enhancements will focus on optimizing the E2E tests further and exploring additional Sentry features for more granular error analysis. Additionally, I plan to monitor the impact of these changes on the project's overall performance and adjust configurations as needed.

vibecoding #buildinpublic #Sentry #E2ETesting #CICD #Nextjs #GreenView

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/greenview · 2026-07-11

#playadev #buildinpublic

Enhancing CraveView's CI/CD Pipeline with Sentry and E2E Tests

Roberto Luna — Sun, 12 Jul 2026 15:46:44 +0000

Enhancing CraveView's CI/CD Pipeline with Sentry and E2E Tests

TL;DR: I upgraded CraveView's CI/CD pipeline by integrating Sentry for error tracking and implementing End-to-End (E2E) tests, boosting the score from 85 to 95+. This technical deep-dive explores the architecture decisions, code changes, and lessons learned.

The Problem

The initial problem wasn't a single error message but a series of inefficiencies in the CI/CD pipeline. The existing setup lacked comprehensive error tracking and test coverage, leading to potential issues in production. Specifically, the pipeline didn't have:

Robust Error Tracking: No integrated system for capturing and analyzing errors.
End-to-End Tests: Limited test coverage, which could lead to undetected issues in production.

What I Tried First

Initially, I focused on enhancing the test suite. I explored various testing frameworks but decided to implement E2E tests using Vitest, given its compatibility with the existing tech stack.

The first approach involved setting up a basic E2E test framework. However, I encountered issues with the test environment configuration, particularly with database connectivity. The tests required a realistic database setup, which wasn't properly simulated.

The Implementation

Step 1: Configuring Sentry

To integrate Sentry, I created configuration files for client, edge, and server initialization:

sentry.client.config.ts

import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: "https://385038c88b6eb6ddac52d05a144ab8c1@o4511628189630464.ingest.us.sentry.io/4511629",
  // Additional config options
});

sentry.edge.config.ts and sentry.server.config.ts follow a similar structure, adjusted for their respective environments.

Step 2: Implementing E2E Tests

I added a new test file e2e-production.test.ts in src/__tests__:

import { test, expect } from '@playwright/test';

test('should render the homepage', async ({ page }) => {
  await page.goto('https://craveview.vercel.app');
  await expect(page.locator('h1')).toContainText('CraveView');
});

This test ensures the homepage loads correctly and contains the expected text.

Step 3: Updating CI/CD Workflow

The .github/workflows/ci-e2e.yml file was modified to include Sentry configuration and E2E tests:

name: 🍽️ CI + E2E — CraveView

on:
  push:
    branches: [main]
  workflow_dispatch: {}
  schedule:
    - cron: "40 6 * * *"

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Install dependencies
        run: npm install

      - name: Generate Prisma client
        env:
          DATABASE_URL: "postgresql://dummy:dummy@localhost:5432/dummy"
        run: npm run db:generate

      - name: Run E2E tests
        run: npm run test:e2e

Step 4: Updating next.config.ts

To integrate Sentry with Next.js, I updated next.config.ts:

import type { NextConfig } from "next";
import { withSentryConfig } from "@sentry/nextjs";

const nextConfig: NextConfig = {
  // Existing config options
};

export default withSentryConfig(nextConfig);

Key Takeaway

The integration of Sentry and E2E tests significantly improved the robustness of CraveView's CI/CD pipeline. Key takeaways:

Error Tracking: Sentry provides comprehensive error tracking, helping identify and resolve issues quickly.
Test Coverage: E2E tests ensure the application behaves as expected in a real-world scenario.

What's Next

Future enhancements include:

Expanding Test Coverage: Adding more E2E tests to cover additional features.
Optimizing Performance: Monitoring and optimizing the performance impact of Sentry and E2E tests.

By documenting these changes, I aim to share practical insights and code snippets that can help others enhance their CI/CD pipelines.

vibecoding #buildinpublic #DevOps #Sentry #E2ETesting #CI/CD

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/craveview · 2026-07-11

#playadev #buildinpublic

Upgrading CI Workflows: From Node 20 to Node 22 and Actions v5/v6

Roberto Luna — Sun, 12 Jul 2026 15:46:02 +0000

Upgrading CI Workflows: From Node 20 to Node 22 and Actions v5/v6

TL;DR: I upgraded the CI workflows for the content-automation repository from Node 20 to Node 22 and Actions v5/v6, addressing compatibility issues and improving performance. Key changes included updating upload-artifact from v5 to v7 and implementing retry with backoff.

The Problem

The CI workflows for the content-automation repository were using Node 20 internally, despite the configuration specifying Node 20. This discrepancy caused compatibility issues with newer versions of the GitHub Actions. Specifically, the upload-artifact action was still on version 5, which was internally targeting Node 20.

What I Tried First

Initially, I attempted to update the upload-artifact action to version 7, which supports Node 22. However, this change alone did not resolve the issue, as other actions like checkout and setup-python were still on older versions.

The Implementation

To address the compatibility issues, I updated the following actions:

upload-artifact from v5 to v7
checkout to v5
setup-python to v6

Here are the specific code changes:

// .github/workflows/main.yml
steps:
  - name: Checkout code
    uses: actions/checkout@v5
  - name: Setup Python
    uses: actions/setup-python@v6
  - name: Upload artifact
    uses: actions/upload-artifact@v7

Additionally, I implemented a retry mechanism with backoff for the CI workflows:

// .github/workflows/main.yml
steps:
  - name: Retry with backoff
    run: |
      for i in {1..3}; do
        if ./script.sh; then
          break
        else
          echo "Retry $i failed, backing off..."
          sleep $((i * 2))
        fi
      done

Key Takeaway

The key takeaway from this experience is the importance of keeping CI workflows up-to-date with the latest versions of GitHub Actions. This not only ensures compatibility but also improves performance and reliability.

What's Next

Next, I plan to monitor the CI workflows for any issues and continue to optimize the retry mechanism for better performance. I will also explore other ways to improve the reliability and efficiency of the content-automation repository.

vibecoding #buildinpublic #devops #ci-cd

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-07-11

#playadev #buildinpublic

Implementing a Live 'TVs without MAC' List on the /tv Dashboard

Roberto Luna — Sat, 11 Jul 2026 15:44:49 +0000

Implementing a Live 'TVs without MAC' List on the /tv Dashboard

TL;DR: I added a live 'TVs without MAC' list next to the recent activity section on the /tv dashboard. This feature involves modifying the dashboard API, updating the TV dashboard component, and adding a new service function.

The Problem

The /tv dashboard previously only displayed recent activity and device counts. However, there's a need to also show a list of TVs currently missing a valid MAC address for easier identification and management. The error message or symptom wasn't a specific error, but rather a missing feature.

What I Tried First

Initially, I considered adding a new endpoint to fetch the list of devices without MAC addresses. However, I decided to integrate this functionality into the existing dashboard API to minimize the number of requests made to the server.

The Implementation

To implement this feature, I made changes to three files:

src/app/api/dashboard/route.ts

import { NextResponse } from "next/server";
import {
  getLastSync,
  getDeviceCounts,
  getRecentChanges,
  getNoMacDevices,
} from "@/services/dashboard.service";

export async function GET(request: Request) {
  const lastSync = await getLastSync();
  const deviceCounts = await getDeviceCounts();
  const recentChanges = await getRecentChanges();
  const noMacDevices = await getNoMacDevices();

  return NextResponse.json({
    lastSync,
    deviceCounts,
    recentChanges,
    noMacDevices,
  });
}

src/features/tv/TVDashboard.tsx

interface DashboardData {
  newDevices: ChangeEntry[];
  removedDevices: ChangeEntry[];
  noMacDevices: { id: string; room: string; location: string; terminalAddress: string }[];
}

const TVDashboard = () => {
  const { data, error, isLoading } = useQuery<DashboardData>('/api/dashboard');

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return (
    <div>
      <h2>Recent Activity</h2>
      <ul>
        {data.recentChanges.map((change) => (
          <li key={change.id}>{change.message}</li>
        ))}
      </ul>
      <h2>TVs without MAC</h2>
      <ul>
        {data.noMacDevices.map((device) => (
          <li key={device.id}>
            {device.room} - {device.location} ({device.terminalAddress})
          </li>
        ))}
      </ul>
    </div>
  );
};

src/services/dashboard.service.ts

/** Live list of TVs currently missing a valid MAC — for the /tv wallboard. */
export async function getNoMacDevices() {
  // Assuming a database query or API call to fetch devices without MAC
  const response = await fetch('/api/devices?filter=noMac');
  const devices = await response.json();
  return devices;
}

Key Takeaway

The key takeaway from this implementation is the importance of integrating new features into existing APIs and services to minimize the complexity and overhead of additional requests. By adding a new function to the dashboard.service.ts file and modifying the existing API endpoint, I was able to easily add the 'TVs without MAC' list feature to the /tv dashboard.

What's Next

Next, I plan to implement filtering and sorting functionality for the 'TVs without MAC' list to make it easier to manage and identify specific devices. This will involve adding additional parameters to the getNoMacDevices function and modifying the API endpoint to handle these new parameters.

vibecoding #buildinpublic #typescript #react #dashboard #api #services

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/tvview · 2026-07-10

#playadev #buildinpublic

Synchronizing Offline Device Counts in Real-Time

Roberto Luna — Sat, 11 Jul 2026 15:44:03 +0000

Synchronizing Offline Device Counts in Real-Time

TL;DR: I fixed the discrepancy between the 'Equipos offline' count and the live offline count by implementing a unified data source and updating the dashboard components to reflect real-time changes. This involved modifying dashboard.service.ts, whats-changed.tsx, and TVDashboard.tsx.

The Problem

The 'Equipos offline' count on the dashboard was not matching the live offline count. This discrepancy was causing confusion and undermining the reliability of the dashboard. The error message or symptom was not explicitly recorded, but the issue was clear: the counts were not aligning.

What I Tried First

Initially, I suspected that the issue might be related to the way data was being fetched or processed in the dashboard.service.ts file. I reviewed the code and noticed that there were separate functions for fetching device counts and recent changes. I thought that perhaps the issue was due to the asynchronous nature of these functions and the potential for data to become outdated.

// Initial code snippet from dashboard.service.ts
export async function getDeviceCounts() {
  // ...
}

export async function getRecentChanges(limit = 50) {
  // ...
}

The Implementation

To resolve the issue, I decided to unify the data source for both the 'Equipos offline' count and the live offline count. I modified the dashboard.service.ts file to include a new function that would fetch the offline devices and update the counts accordingly.

// Updated code snippet from dashboard.service.ts
export async function getOfflineDevices() {
  const response = await fetch('/api/offline-devices');
  const offlineDevices = await response.json();
  return offlineDevices;
}

export async function getDeviceCounts() {
  const offlineDevices = await getOfflineDevices();
  // Update counts based on offline devices
  // ...
}

Next, I updated the whats-changed.tsx and TVDashboard.tsx components to use the new unified data source. I added a new interface OfflineEntry to represent the offline devices and updated the code to reflect the real-time changes.

// Updated code snippet from whats-changed.tsx
interface OfflineEntry {
  id: string;
  deviceName: string;
  site: string | null;
  updatedAt: string;
}

const WhatsChanged = () => {
  const { offlineDevices } = useDashboardData();
  // ...
};

// Updated code snippet from TVDashboard.tsx
interface OfflineEntry {
  id: string;
  deviceName: string;
  site: string | null;
  updatedAt: string;
}

const TVDashboard = () => {
  const { offlineDevices } = useDashboardData();
  // ...
};

Key Takeaway

The key takeaway from this experience is the importance of unifying data sources when dealing with real-time data. By doing so, we can ensure that our application reflects the most up-to-date information and avoid discrepancies that can lead to confusion.

What's Next

The next step is to implement a similar unified data source for other device statuses, such as 'online' and 'maintenance'. This will further enhance the reliability and accuracy of the dashboard.

vibecoding #buildinpublic #typescript #react #real-time-data

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/greenview · 2026-07-10

#playadev #buildinpublic

Building CraveView: A Technical Deep-Dive into the Crave T3 Tablet Inventory Dashboard

Roberto Luna — Sat, 11 Jul 2026 15:43:22 +0000

Building CraveView: A Technical Deep-Dive into the Crave T3 Tablet Inventory Dashboard

TL;DR

I built CraveView, a tablet inventory dashboard, using Next.js 15, TypeScript, and Tailwind v4, with a Prisma schema for data modeling. This technical deep-dive explores the architecture decisions, code changes, and lessons learned during development.

The Problem

The goal was to create a dashboard for managing Crave T3 tablet inventory. The initial problem was setting up a robust tech stack for handling data synchronization from Google Sheets (CSV export) to a database, and then to the dashboard.

What I Tried First

Initially, I scaffolded the project using create-next-app with TypeScript and Tailwind CSS. I then focused on setting up Prisma for data modeling and database connection. The first challenge was configuring Prisma to work with a Neon database.

The Implementation

The implementation involved several key steps:

Setting Up the Database and Prisma

First, I added the database URL to .env.example:

# --- Database (Neon) ---
DATABASE_URL="postgresql://user:password@ep-xxxx-pooler.region.aws.neon.tech/craveview?sslmode=require"
DATABASE_URL_UNPOOLED="postgresql://user:password@ep-xxxx-pooler.region.aws.neon.tech/craveview?sslmode=require"

Then, I defined the Prisma schema in prisma/schema.prisma:

model CraveDevice {
  id       String   @id @default(cuid())
  clientId String   @unique
  // Additional fields...
}

Configuring Next.js and Tailwind

I updated next.config.ts to include Tailwind CSS:

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  // Config options...
};

export default nextConfig;

In eslint.config.mjs, I added ESLint configuration:

import { dirname } from "path";
import { fileURLToPath } from "url";
import { FlatCompat } from "@eslint/eslintrc";

const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);

const compat = new FlatCompat(__dirname, {
  // Compat options...
});

// ESLint rules...

Building the Dashboard

The dashboard page is located at src/app/(dashboard)/inventory/page.tsx:

import { useState, useEffect } from 'react';

const InventoryPage = () => {
  const [devices, setDevices] = useState([]);

  useEffect(() => {
    // Fetch devices from API or database...
  }, []);

  return (
    <div>
      <h1>Inventory Dashboard</h1>
      <ul>
        {devices.map((device) => (
          <li key={device.id}>{device.clientId}</li>
        ))}
      </ul>
    </div>
  );
};

export default InventoryPage;

Key Takeaway

One key lesson learned was the importance of configuring lint-staged and Husky for automated code quality checks. I added .husky/pre-commit with:

npx lint-staged

And configured .lintstagedrc.json:

{
  "*.{ts,tsx,js,jsx}": ["eslint --fix", "prettier --write"],
  "*.{json,css,md}": ["prettier --write"]
}

What's Next

The next step is to implement data synchronization from Google Sheets to the dashboard. I plan to create an API endpoint for handling CSV uploads and integrating it with the Prisma schema.

vibecoding #buildinpublic #Nextjs #TypeScript #TailwindCSS #Prisma

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/craveview · 2026-07-10

#playadev #buildinpublic

Automating Content Generation: A Technical Deep Dive into JSON and Metadata Updates

Roberto Luna — Sat, 11 Jul 2026 15:42:41 +0000

Automating Content Generation: A Technical Deep Dive into JSON and Metadata Updates

TL;DR: I automated content generation for July 9th, updating JSON files and metadata, and fixed a minor bug in the changelog. This involved modifying multiple files, including bluesky_en.json, metadata.json, and changelog.md.

The Problem

While working on automating content generation, I encountered an issue with inconsistent metadata across different platforms. Specifically, the bluesky_en.json and bluesky_es.json files were not being updated correctly, leading to discrepancies in the published content. The error message I encountered was related to a missing newline character at the end of the file.

What I Tried First

Initially, I attempted to update the content-automation/changelog.md file to reflect the changes made on July 9th. However, I realized that I needed to modify the bluesky_en.json and bluesky_es.json files to include the new content. I also updated the metadata.json file to ensure consistency across platforms.

The Implementation

To resolve the issue, I made the following changes:

Updating `bluesky_en.json` and `bluesky_es.json`

// bluesky_en.json
[
  {
    "type": "progress",
    "text": "Just automated some content generation for July 9th. Fixed a minor bug in `content-automation/changelog.md`"
  }
]

// bluesky_es.json
[
  {
    "type": "avance",
    "text": "Finalmente actualicé los metadatos de los artículos en varios idiomas, resolviendo un pequeño conflicto en los archivos JSON"
  }
]

Updating `metadata.json`

{
  "pull_requests": 0,
  "releases": 0,
  "closed_issues": 0,
  "generated_content": true
}

Updating `changelog.md`

## [2026-07-09] content-automation

### Changed
- Auto-generación de contenido para el 2026-07-09 en varios formatos:
  * Se actualizó `content/2026/07/09/VS/changelog.md` con información adicional

Key Takeaway

The key takeaway from this experience is the importance of consistency in metadata across different platforms. By automating content generation and updating JSON files and metadata, I was able to ensure that the published content was accurate and consistent.

What's Next

In the next iteration, I plan to focus on automating the generation of content for multiple languages and platforms. This will involve exploring new tools and technologies to streamline the process and ensure that the content is accurate and consistent across all platforms.

vibecoding #buildinpublic #contentautomation #json #metadata

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-07-10

#playadev #buildinpublic

Implementing Google Sheets Integration for Device Management in tvview

Roberto Luna — Fri, 10 Jul 2026 16:51:20 +0000

Implementing Google Sheets Integration for Device Management in tvview

TL;DR: I integrated Google Sheets with the tvview app, enabling edits to be written back to a sheet for MAC, Model, and Lineup. This involved setting up Google API credentials, modifying the device service, and adding a SheetsWriter provider.

The Problem

The initial problem was to enhance the device management capabilities in the tvview application by integrating Google Sheets. This would allow for seamless editing and synchronization of device information, specifically MAC, Model, and Lineup, directly to a Google Sheet.

What I Tried First

Initially, I focused on setting up the Google API credentials and installing the necessary googleapis package. I added the googleapis package to the project by running:

npm install googleapis

"googleapis": "^173.0.0"

in package.json.

The Implementation

Environment Variables and Dependencies

First, I updated .env.example to include Google API credentials:

# --- Google Sheets ---
GOOGLE_SERVICE_ACCOUNT_EMAIL="your-service-account-email@your-project-id.iam.gserviceaccount.com"
GOOGLE_PRIVATE_KEY="your-private-key"
GOOGLE_SPREADSHEET_ID="your-spreadsheet-id"

I also updated package-lock.json and package.json to include the googleapis dependency:

"googleapis": "^173.0.0",

Google Sheets Writer Provider

Next, I created a SheetsWriter.ts provider to handle writing to Google Sheets:

// src/providers/googleSheets/SheetsWriter.ts
import { google } from "googleapis";

export interface SheetWriteResult {
  ok: boolean;
  message?: string;
}

function getAuth() {
  const email = process.env.GOOGLE_SERVICE_ACCOUNT_EMAIL;
  const privateKey = process.env.GOOGLE_PRIVATE_KEY;
  const spreadsheetId = process.env.GOOGLE_SPREADSHEET_ID;

  // Auth logic here
}

export async function writeDeviceFieldsToSheet(deviceId: string, fields: any) {
  // Write logic here
}

Device Service Updates

I then updated device.service.ts to integrate with the new SheetsWriter:

// src/services/device.service.ts
import { prisma } from "@/lib/prisma";
import { isValidMac } from "@/lib/mac";
import { writeDeviceFieldsToSheet } from "@/providers/googleSheets/SheetsWriter";

export async function updateDevice(deviceId: string, fields: any) {
  // Update logic here
  await writeDeviceFieldsToSheet(deviceId, fields);
}

API Route Updates

The API route for device updates was also modified:

// src/app/api/devices/[id]/route.ts
import { NextResponse } from "next/server";
import { updateDevice } from "@/services/device.service";

export async function PATCH(req: Request, { params }: { params: { id: string } }) {
  const { id } = params;
  const { body } = await req.json();

  // Update logic here
  await updateDevice(id, body);

  return NextResponse.json({ message: "Device updated successfully" });
}

Key Takeaway

The key takeaway from this implementation is the importance of properly handling authentication and authorization when integrating with external services like Google Sheets. Ensuring that sensitive credentials are stored securely and used correctly is crucial.

What's Next

Next, I plan to enhance the error handling and logging for the Google Sheets integration. This will involve implementing retries for failed writes and adding more detailed logging to diagnose issues.

vibecoding #buildinpublic #GoogleSheets #DeviceManagement

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/tvview · 2026-07-09

#playadev #buildinpublic

Implementing Unpooled Connections for Prisma CLI and Adding Change Log to Settings

Roberto Luna — Fri, 10 Jul 2026 16:50:32 +0000

Implementing Unpooled Connections for Prisma CLI and Adding Change Log to Settings

TL;DR:

I updated the Prisma configuration to use unpooled connections for the Prisma CLI, enhancing performance during migrations and db pushes. Additionally, I implemented a change log feature in the Settings dashboard, enabling users to track synchronization history.

The Problem

When running Prisma CLI commands like migrate and db push, I noticed that the pooled connection was causing delays. The Prisma documentation suggests using unpooled connections for these operations to improve performance. Furthermore, I wanted to enhance the Settings dashboard by adding a change log feature that displays the synchronization history.

What I Tried First

Initially, I attempted to configure Prisma to use a pooled connection for all operations, but this didn't yield the desired performance for CLI commands. I then explored using an unpooled connection specifically for migrations and db pushes.

The Implementation

Using Unpooled Connections for Prisma CLI

To implement unpooled connections for Prisma CLI commands, I modified the prisma.config.ts file:

// prisma.config.ts
import { defineConfig } from "prisma/config";

export default defineConfig({
  // ... other configurations ...
  datasource: {
    url: process.env.DATABASE_URL,
    // Use unpooled connection for CLI commands
    connect: {
      pool: false,
    },
  },
});

This change ensures that Prisma CLI commands use a direct, unpooled connection, improving performance.

Adding Change Log to Settings

To add the change log feature to the Settings dashboard, I made the following changes:

Updating Prisma Schema

// prisma/schema.prisma
model SyncLog {
  id        String   @id @default(cuid())
  startedAt DateTime @default(now())
  duration  Int?
  message   String?

  changes   DeviceHistory[]
}

model DeviceHistory {
  id        String   @id @default(cuid())
  deviceId  String
  // ... other fields ...
}

Implementing Sync History Log Component

// src/features/sync/SyncHistoryLog.tsx
"use client";

import { useState } from "react";
import { ChevronDown, ChevronRight } from "lucide-react";
import { Card, CardContent, CardHeader, CardTitle } from "@/components/ui/card";

const SyncHistoryLog = () => {
  const [expanded, setExpanded] = useState(false);

  const handleToggle = () => {
    setExpanded(!expanded);
  };

  return (
    <Card>
      <CardHeader>
        <CardTitle>Sync History Log</CardTitle>
        <button onClick={handleToggle}>
          {expanded ? <ChevronDown /> : <ChevronRight />}
        </button>
      </CardHeader>
      {expanded && (
        <CardContent>
          {/* Render sync history log details */}
        </CardContent>
      )}
    </Card>
  );
};

export default SyncHistoryLog;

Updating Settings Page

// src/app/(dashboard)/settings/page.tsx
import { Card, CardContent, CardHeader, CardTitle } from "@/components/ui/card";
import { SyncPanel } from "@/features/sync/SyncPanel";
import { SyncHistoryLog } from "@/features/sync/SyncHistoryLog";

const SettingsPage = () => {
  return (
    <div>
      <Card>
        <CardHeader>
          <CardTitle>Settings</CardTitle>
        </CardHeader>
        <CardContent>
          <SyncPanel />
          <SyncHistoryLog />
        </CardContent>
      </Card>
    </div>
  );
};

export default SettingsPage;

Key Takeaway

When optimizing database interactions, consider using unpooled connections for CLI operations to improve performance. Additionally, implementing a change log feature can enhance user experience by providing transparency into synchronization history.

What's Next

In the next iteration, I plan to integrate the change log feature with the Google Sheets sync functionality to provide a more comprehensive view of synchronization history.

vibecoding #buildinpublic #prisma #unpooledconnections #change log #settingsdashboard

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/greenview · 2026-07-09

#playadev #buildinpublic

DEV Community: Roberto Luna

Upgrading to Next 15: End-to-End Tests and CVE Fixes

Upgrading to Next 15: End-to-End Tests and CVE Fixes

The Problem

What I Tried First

The Implementation

Step 1: Update package.json and Lockfiles

Step 2: Resolve CVEs

Step 3: Enhance End-to-End Tests

Key Takeaway

What's Next

vibecoding #buildinpublic #nextjs #security

Updating Dependency Lockfiles for a Monorepo Project

Updating Dependency Lockfiles for a Monorepo Project

The Problem

What I Tried First

The Implementation

Update apps/api/package.json and apps/api/package-lock.json

Update apps/web/package-lock.json

Update Root package-lock.json

Key Takeaway

What's Next

vibecoding #buildinpublic #monorepo #dependency-management

Enhancing CI/CD and E2E Testing with Sentry Integration in tvview

Enhancing CI/CD and E2E Testing with Sentry Integration in tvview

The Problem

What I Tried First

The Implementation

Step 1: Configuring Sentry

Step 2: Enhancing CI/CD Pipeline

Step 3: Updating next.config.ts

Key Takeaway

What's Next

vibecoding #buildinpublic #Sentry #E2Etesting #CI/CD

Enhancing CI/CD and E2E Testing with Sentry Integration in GreenView

Enhancing CI/CD and E2E Testing with Sentry Integration in GreenView

The Problem

What I Tried First

The Implementation

Sentry Integration

CI/CD and E2E Testing Enhancements

Next.js Configuration

Key Takeaway

What's Next

vibecoding #buildinpublic #Sentry #E2ETesting #CICD #Nextjs #GreenView

Enhancing CraveView's CI/CD Pipeline with Sentry and E2E Tests

Enhancing CraveView's CI/CD Pipeline with Sentry and E2E Tests

The Problem

What I Tried First

The Implementation

Step 1: Configuring Sentry

Step 2: Implementing E2E Tests

Step 3: Updating CI/CD Workflow

Step 4: Updating next.config.ts

Key Takeaway

What's Next

vibecoding #buildinpublic #DevOps #Sentry #E2ETesting #CI/CD

Upgrading CI Workflows: From Node 20 to Node 22 and Actions v5/v6

Upgrading CI Workflows: From Node 20 to Node 22 and Actions v5/v6

The Problem

What I Tried First

The Implementation

Key Takeaway

What's Next

vibecoding #buildinpublic #devops #ci-cd

Implementing a Live 'TVs without MAC' List on the /tv Dashboard

Implementing a Live 'TVs without MAC' List on the /tv Dashboard

The Problem

What I Tried First

The Implementation

src/app/api/dashboard/route.ts

src/features/tv/TVDashboard.tsx

src/services/dashboard.service.ts

Key Takeaway

What's Next

vibecoding #buildinpublic #typescript #react #dashboard #api #services

Synchronizing Offline Device Counts in Real-Time

Synchronizing Offline Device Counts in Real-Time

The Problem

What I Tried First

Step 1: Update `package.json` and Lockfiles

Update `apps/api/package.json` and `apps/api/package-lock.json`

Update `apps/web/package-lock.json`

Update Root `package-lock.json`

Updating `bluesky_en.json` and `bluesky_es.json`

Updating `metadata.json`

Updating `changelog.md`