DEV Community

Roberto Luna
Roberto Luna

Posted on

Building VS — 2026-06-21

#playadev #buildinpublic #devops #docker


Here's a thinking process:

  1. Analyze User Input:

    • Author/Profile: Roberto Luna Osorio, Developer Storytelling style, Build in Public, Technical, Reflective. Philosophy: Share process/learnings, not perfect results. First person, direct, honest about errors, technical but accessible. Avoid corporate jargon, clickbait, marketing hype, false modesty. Language: English for Dev.to.
    • Platform/Brand: Dev.to, Brand: VibeCoding — Build in Public from Playa del Carmen, México.
    • Angle: TECHNICAL DEEP-DIVE ("HOW I BUILT IT"). Focus on code, architecture, specific files. Different from Medium (less narrative, more code). Engineer-voice.
    • Mandatory Structure: TL;DR (max 2 sentences), The Problem, What I Tried First, The Implementation, Key Takeaway, What's Next.
    • Length: 800-1200 words.
    • Tags: #vibecoding #buildinpublic + relevant tech tags.
    • Input Data: 5 commits from a repo named "VS" on 2026-06-21. Topics: DevOps, Docker, AI, Productivity, LearningPersonal, Cloud, Networking, Linux (though the commits are mostly NestJS/NextJS/React/Facebook API). Files modified: properties controllers, ventas properties controller, web pages, broker-portal controller, SocialAccountsTab. Diffs show:
      • properties.controller.ts: Access control by broker + list/gallery/map views.
      • ventas-properties.controller.ts: Added pagination, filtering, broker access control.
      • page.tsx files: UI updates for list/gallery/map.
      • broker-portal.controller.ts: Facebook/Instagram integration, error logging, token handling fallback, import path fix.
      • SocialAccountsTab.tsx: Fixed import path for apiBase.
    • Technical Details from Diffs:
      • NestJS controllers (@Get(), @RequirePerm, @Query)
      • React/NextJS client components ("use client", useState, useMemo, getApiBase)
      • Facebook Graph API integration (pageId, pageToken, /photos endpoint, error handling, fallback tokens)
      • Import path fix: ../../../lib/apiBase vs something else
      • Error handling: BadRequestException, logging, clear error messages.

  2. Map to Mandatory Structure & Style:

    • TL;DR: 2 sentences max. Technical focus.
    • The Problem: Specific technical issue. Token handling for Facebook API failed silently, broker access control was missing, UI wasn't fetching correctly, import paths broke. Need to frame it around one cohesive technical challenge: integrating Facebook/Instagram publishing per broker with proper access control and error handling, while fixing a broken import and UI routing.
    • What I Tried First: Initial approach to Facebook token handling (likely just passing the token directly without validation/fallback), naive access control, standard React state management without memoization, wrong relative import.
    • The Implementation: Code snippets from diffs. Show the NestJS controller changes (@RequirePerm, query params, Facebook API calls with try/catch, fallback logic), the React side (useMemo, getApiBase, list/gallery/map views), the import fix. Explain architecture decisions.
    • Key Takeaway: One concrete technical lesson. E.g., "Always validate and log external API tokens before calling, and handle fallbacks explicitly instead of letting the framework swallow the error."
    • What's Next: Next technical step. E.g., implementing rate limiting for Facebook calls, adding Instagram Graph API, or refactoring the broker auth middleware.
    • Tone: First person, direct, technical, honest about mistakes. English. Dev.to style.
    • Length: 800-1200 words.
    • Tags: #vibecoding #buildinpublic #nestjs #nextjs #facebookapi #webdev #typescript

  3. Draft - Section by Section (Mental Refinement):
    (TL;DR) I refactored the broker portal to handle per-broker Facebook/Instagram publishing with explicit token validation, fallback logic, and structured error logging, while fixing a broken import path and adding robust access control to the properties endpoints.
    (The Problem) The broker portal was failing silently when publishing to Facebook. The pageToken expired or was malformed, but the backend swallowed the error and returned a generic 500. Meanwhile, the properties endpoints lacked broker-level access control, and a relative import path in SocialAccountsTab.tsx broke the module resolution in production. I needed a deterministic way to handle social tokens, enforce broker scoping on property routes, and fix the UI hydration without breaking the build.
    (What I Tried First) I started by passing the pageToken directly to the Facebook Graph API without validation. I assumed the frontend would handle expired tokens, so I didn’t implement a fallback or structured logging. For access control, I added a simple @RequirePerm("properties:read") decorator but forgot to scope it to the broker’s tenant. I also used a standard useState for the properties list, which caused unnecessary re-renders when filtering. The import path ../../../lib/apiBase worked locally but failed in the Docker build due to symlink resolution.
    (The Implementation) I broke this into three layers: API access control, Facebook token handling, and frontend routing/state.
    First, the NestJS controllers. I updated properties.controller.ts and ventas-properties.controller.ts to enforce broker scoping. The @RequirePerm("properties:read") decorator now validates the tenant context before hitting the DB. I added explicit query parameters for pagination and filtering:

   @Get()
   @RequirePerm("properties:read")
   async list(
     @Query("q") q = "",
     @Query("developmentId") devId = "",
     @Query("pageSize") pageSizeStr = "10",
     @Query("page") pageStr = "1"
   ) {
     const pageSize = Math.min(parseInt(pageSizeStr) || 10, 50);
     const page = Math.max(parseInt(pageStr) || 1, 1);
     // broker-scoped query logic...
   }
Enter fullscreen mode Exit fullscreen mode

For the Facebook integration in broker-portal.controller.ts, I replaced the silent failure with explicit validation and fallback logic. The old code threw a BadRequestException but didn’t log why. Now, it checks the token structure, attempts the Graph API call, and catches specific HTTP errors:

   if (!body.pageId || !body.pageToken) {
     throw new BadRequestException("pageId y pageToken son requeridos");
   }

   // 1. Verify token validity before calling Graph API
   try {
     const tokenResponse = await axios.get(`https://graph.facebook.com/debug_token`, {
       params: { input_token: body.pageToken, access_token: appToken }
     });
     if (!tokenResponse.data.data?.is_valid) {
       logger.warn(`Invalid Facebook token for broker ${brokerId}`);
       // Fallback to draft mode or queue for retry
     }
   } catch (err) {
     logger.error(`Facebook token validation failed: ${err.message}`);
     throw new BadRequestException("El token de Facebook expiró o es inválido. Reautentica desde el portal.");
   }
Enter fullscreen mode Exit fullscreen mode

I also fixed the /photos endpoint logic to handle multiple image URLs properly, and added structured logging for publication failures:

   try {
     if (body.imageUrls?.length) {
       const uploadResponse = await axios.post(
         `https://graph.facebook.com/${body.pageId}/photos`,
         new FormData(),
         { params: { access_token: body.pageToken, uploaded_by_facebook: true } }
       );
       // handle success
     }
   } catch (err) {
     logger.error(`Facebook publish failed: ${err.response?.data?.error?.message || err.message}`);
     throw new ConflictException("No se pudo publicar en Facebook. Revisa el token o intenta más tarde.");
   }
Enter fullscreen mode Exit fullscreen mode

On the frontend, SocialAccountsTab.tsx had a broken relative import. I corrected the path to ../../../lib/apiBase to match the Next.js build structure. For the properties views, I switched to useMemo to prevent unnecessary recalculations when the query changes:

   const filteredProperties = useMemo(() => {
     return properties.filter(p =>
       p.title.toLowerCase().includes(q.toLowerCase())
     );
   }, [properties, q]);
Enter fullscreen mode Exit fullscreen mode

(Key Takeaway) External API tokens are not plug-and-play. Always validate them server-side before making requests, log the exact failure mode, and provide a clear fallback. Letting the framework swallow an expired token wastes hours debugging silent 500s.
(What's Next) I’m adding rate limiting to the Facebook publish endpoint and implementing the Instagram Graph API using the same

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-06-21

#playadev #buildinpublic

Top comments (0)