Fran Moreno | Blog

Workers AI no compite con OpenAI: compite por un sitio en tu arquitectura

Wed, 29 Apr 2026 00:00:00 GMT

Cada vez que aparece una comparativa de "Cloudflare Workers AI vs OpenAI" en mi feed, la abro con curiosidad y la cierro a los dos minutos. Casi todas cometen el mismo error de marco: tratar a Workers AI como si fuera un sustituto del último modelo frontier de turno. Comparan Llama 3.1 8B con GPT-4 o Claude Opus, concluyen que pierde por goleada, y dan por zanjada la decisión.

Llevo un tiempo construyendo aplicaciones que combinan Workers AI con APIs de Anthropic y OpenAI, mi conclusión: Workers AI no viene a ocupar el sitio de Claude o GPT en tu arquitectura. Viene a ocupar uno distinto. Este post es el resultado de pelearme con esa pregunta en proyectos reales y entender qué hace bien, qué hace mal, y dónde tiene sentido meterlo.

Qué es Workers AI arquitectónicamente

Antes de entrar en modelos y precios, conviene fijar el modelo mental, porque es lo que hace que toda la decisión cuadre.

Workers AI es inferencia serverless sobre GPUs distribuidas en la red global de Cloudflare. No es un endpoint REST que vive en un único datacenter de Virginia al que tú llamas desde la otra punta del mundo. Es el mismo principio que ya describí cuando hablé de Cloudflare Workers: tu código se ejecuta cerca del usuario. Solo que aquí lo que ejecutas es un modelo de IA.

Desde dentro de un Worker, llamar al modelo es literalmente esto:

const respuesta = await env.AI.run('@cf/meta/llama-3.1-8b-instruct', {
  prompt: 'Tu prompt aquí'
})

Ni claves de terceros, ni gestión de endpoints, ni SDKs externos, ni preocupación por desde qué región sale la petición. Está integrado en el runtime que ya estás usando.

La unidad de facturación tiene su propia jerga: Neurons. Workers AI cuesta 0,011 dólares por cada 1.000 Neurons, con una asignación gratuita de 10.000 Neurons al día. Cada modelo consume Neurons a una tasa distinta según su coste computacional, y Cloudflare publica equivalencias por modelo en tokens y en imágenes, así que en la práctica puedes razonar en las unidades a las que estás acostumbrado y el sistema hace la conversión por detrás.

Lo importante: el coste se mide en GPU compute, no en tokens directamente. Esto es coherente con el hecho de que están hospedando los modelos en su infraestructura, no revendiendo tokens de un proveedor externo.

El catálogo es más amplio de lo que parece

Otro malentendido frecuente es asumir que Workers AI son "tres Llamas y poco más". El catálogo lleva tiempo creciendo y conviene mirarlo por tipo de tarea, no por proveedor:

LLMs generalistas: Llama 3.1, Mistral, Qwen 1.5, Hermes 2 Pro, Starling. Y un detalle interesante: están los modelos open-weight de OpenAI (gpt-oss-20b) y Kimi K2.5 con 256k de contexto, multi-turn tool calling y vision. Los catálogos open-weight ya no son lo que eran hace un año.
Embeddings y reranking: la familia bge (incluyendo bge-reranker-base). Aquí Workers AI es brutalmente competitivo en precio.
Audio: Whisper para STT, Aura para TTS context-aware.
Imagen: FLUX.2 (klein y dev) de Black Forest Labs, Lucid Origin y Phoenix de Leonardo.
Guardrails: Llama Guard 3 8B, integrado además directamente con AI Gateway.
Especializados: traducción multilingüe (m2m100, IndicTrans2), clasificación con DistilBERT, captioning visual con UForm-Gen.

El mensaje aquí es importante: el catálogo está pensado para componer aplicaciones de IA, no solo para hacer chat. Esto cambia bastante la conversación.

El ecosistema es la verdadera ventaja

Si Workers AI fuera solo un endpoint donde llamar a Llama, el caso de uso sería estrecho. Lo que lo hace interesante es lo que tiene alrededor.

AI Gateway es la pieza central. Te permite poner un proxy delante de cualquier proveedor de IA (Workers AI, OpenAI, Anthropic, Mistral, Google) con caching, rate limiting, observabilidad, retries, fallback entre proveedores y métricas unificadas. La novedad de 2026 es la facturación unificada: puedes pagar el consumo de OpenAI o Anthropic dentro de tu factura de Cloudflare, sumándole una pequeña comisión. No es un cambio enorme, pero simplifica la vida del que tiene varios proveedores facturando por separado.

Vectorize es la base de datos vectorial nativa de Cloudflare. Si vas a generar embeddings con Workers AI, mantenerlos en Vectorize evita salir del ecosistema.

AI Search apareció en 2026 como una capa nueva con storage, índice vectorial y crawling integrados. Está en open beta, así que su madurez es limitada todavía.

Y todo esto se compone con Workers, Durable Objects y Queues para construir agentes con estado y pipelines asíncronos. Suena obvio cuando lo escribes, pero en la práctica significa que puedes llevarte el 100% de una aplicación de IA a Cloudflare sin dependencias externas. Yo ya conté en su momento por qué he ido moviendo mis side projects a Cloudflare y este punto pesa cada vez más.

Cuándo Workers AI es la respuesta correcta

Vamos al grano con las decisiones reales. Para mí, Workers AI gana cuando se cumplen varios de estos requisitos a la vez:

La tarea es acotada: clasificar, extraer tags, generar texto corto, hacer embeddings, moderar, traducir. Cosas donde un Llama 3.1 8B o un Mistral basta y sobra.
El volumen es alto y el coste por operación importa.
La latencia importa de verdad: estás sirviendo a usuarios en tiempo real y el round trip a api.openai.com se nota.
La tolerancia a un fallo puntual es razonable: si la salida no es perfecta, el usuario corrige o el sistema reintenta.
Quieres que los datos no salgan de Cloudflare por privacidad o por reducir vendor sprawl.

Un ejemplo concreto que tengo en producción: en PokerReads, uno de mis side projects, hay una funcionalidad de notas sobre jugadores. La idea es que durante una partida puedas escribir desde el móvil una observación rápida sobre alguien ("muy loose en early position", "no defiende blinds", "siempre 3betea con AK suited") y el sistema te devuelva una versión estructurada y un conjunto de tags para categorizar a ese jugador.

Es exactamente el caso de uso que Workers AI resuelve mejor que cualquier API frontier:

Latencia: estoy en mitad de una mano, no quiero esperar segundos. Workers AI ejecutándose en el edge me da respuestas rapidísimas.
Tarea cerrada: el vocabulario de tags es relativamente acotado, la estructura de la nota también. No necesito el razonamiento de Claude Opus para esto.
Volumen: una nota por mano interesante, varias por sesión, multiplicado por usuarios. Mandarlo todo a Anthropic sería tirar dinero.
Privacidad: las notas son observaciones privadas sobre otros jugadores, prefiero que vivan dentro de Cloudflare.
Coste de error bajo: si un tag no acaba de encajar, el usuario lo corrige en dos toques.

Llamar a Claude o GPT para esto sería sobrecualificación pura. Un Llama 3.1 8B con un prompt bien afinado hace exactamente lo que necesito y a un coste residual.

Cuándo Workers AI no es la respuesta

Ahora el contrapunto, que es donde la mayoría de posts se quedan cortos.

Workers AI pierde claramente cuando:

La tarea requiere razonamiento complejo, multi-paso o tool use sofisticado. Aquí Claude y GPT siguen estando varias categorías por encima.
Necesitas vision capabilities serias sobre layouts variables o documentos complejos.
Trabajas con contexto realmente largo y necesitas buen recall dentro de él. Aunque Kimi K2.5 trae 256k de contexto, los frontier models siguen ganando en cómo aprovechan ese contexto.
El coste de un mal output es alto. Si un fallo en la extracción llega al cliente final, ahorrar unos céntimos no compensa.
Quieres lo último. Workers AI suele ir por detrás del estado del arte, lógicamente.

Aquí entra mi otro proyecto, el SaaS de gestión para hostelería del que ya he hablado en otros posts. Una de las funcionalidades clave es la extracción de datos desde documentos: facturas de proveedores, menús, listas de precios. El usuario sube un PDF o una foto y el sistema tiene que extraer items, precios, IVA, alérgenos, lo que aplique según el documento.

Aquí elegí la API de Anthropic con Claude sin pensármelo dos veces:

Vision capabilities: Claude lee documentos con layouts variables (cada proveedor factura distinto) con una precisión que los modelos disponibles en Workers AI no alcanzan.
Razonamiento sobre estructura: identificar qué es una línea de producto, qué es un total, qué es un descuento, requiere razonar sobre el documento, no solo extraer texto.
Coste de error alto: estos datos van a la contabilidad del cliente. Un campo mal extraído es una incidencia, una llamada de soporte y, potencialmente, un cliente perdido.
Volumen moderado: una factura no se procesa en cada interacción del usuario. El coste por operación pesa menos que la fiabilidad.

Si intentara hacer esto con Workers AI, me ahorraría dinero por documento procesado, pero me lo gastaría con creces en horas de soporte y en pérdida de confianza. La cuenta sale al revés.

El patrón ganador es híbrido

La conclusión práctica de todo esto es que la pregunta correcta no es "¿Workers AI o Anthropic?". Es "¿qué pieza de mi arquitectura hace cada cosa?".

El patrón que estoy viendo funcionar en proyectos reales es híbrido:

Workers AI para preprocesamiento, embeddings, clasificación, moderación, primera línea, tareas auxiliares de alto volumen.
Frontier models (Anthropic, OpenAI) para el razonamiento donde la calidad importa de verdad: extracción compleja, agentes, generación con altos estándares de calidad.
AI Gateway como capa unificada por delante de todo: caching, observabilidad, fallback, control de costes.

Resumido en mis dos proyectos:

	PokerReads	SaaS hostelería
Tarea	Estructurar notas y tagging	Extracción de datos de documentos
Modelo elegido	Workers AI (Llama 3.1)	Anthropic (Claude)
Razón principal	Latencia + volumen + coste	Precisión + razonamiento + vision
Coste de error	Bajo (el usuario corrige)	Alto (datos del cliente)
Contexto de uso	Móvil, en vivo	Backend, asíncrono

Esta tabla es más útil que cualquier benchmark, porque reproduce el tipo de decisión que tomas tú cuando arrancas un proyecto.

En un próximo post quiero entrar al detalle del patrón híbrido con código: cómo enrutar peticiones entre Workers AI y Anthropic con AI Gateway, cómo aplicar fallback cuando una llamada falla, y cómo medir si la decisión inicial era correcta o conviene cambiarla. Aviso aquí cuando esté.

Limitaciones que hay que reconocer

Para no cerrar con un tono comercial, lo que conviene tener presente antes de meterse de cabeza:

Los modelos en Workers AI van por detrás del estado del arte. No esperes encontrar Claude Opus o el último GPT aquí. Esto no va a cambiar.
Hay rate limits por modelo que pueden sorprenderte en producción. Conviene revisarlos antes de diseñar pipelines de alto volumen.
Algunos modelos están en beta y la calidad varía entre versiones. Los más nuevos pueden tener comportamientos inesperados con prompts que ya tenías afinados.
El catálogo cambia rápido. Lo que escribo hoy puede haber envejecido en seis meses. Es algo a chequear de tanto en tanto.
AI Search y otras piezas del ecosistema están todavía evolucionando. Para producción crítica, conviene tomarlas con prudencia.

Cierre

La conclusión la he ido repitiendo a propósito porque es el mensaje que quería que se llevara el lector: Workers AI no compite con Anthropic ni OpenAI. Resuelve un problema distinto: hacer inferencia barata, rápida y cerca del usuario para tareas donde no necesitas el último frontier model.

Si te lo planteas como un sustituto, sales decepcionado. Si te lo planteas como una pieza más de tu arquitectura, lo combinas con frontier models a través de AI Gateway, y eliges qué tarea va a cada sitio según latencia, coste, calidad requerida y privacidad, descubres que el stack es bastante más potente que cualquiera de las piezas por separado.

En mi caso, llevar tareas auxiliares a Workers AI y reservar Anthropic para lo que de verdad lo necesita ha bajado el coste de mis side projects significativamente sin sacrificar calidad donde importa. Y, para mantener todo el stack en un mismo proveedor, encaja con la dirección que llevo tiempo siguiendo de moverlo todo a Cloudflare.

🚀 ¿Empezando un proyecto en Cloudflare? Si quieres saltarte la parte de fontanería (auth, base de datos, CI/CD) y centrarte en construir tu producto sobre Workers/Pages, el Next.js + Cloudflare Pages Starter Kit trae Better Auth, Drizzle + Supabase y deploy automático listos. La base perfecta para sumarle Workers AI por encima.

¿Estás usando Workers AI en algún proyecto? ¿Lo combinas con OpenAI o Anthropic? Me interesa especialmente cómo estás enrutando entre proveedores y si has dado con algún patrón que te esté funcionando. Cuéntame.

Desplegando una App Next.js (App Router) con Server Actions en Cloudflare Pages (Funciones Incluidas)

Fri, 03 Oct 2025 00:00:00 GMT

Si has seguido la evolución de Next.js y has experimentado con el nuevo App Router, seguramente te has topado con las Server Actions. Son una característica potente que permite ejecutar código del servidor directamente desde componentes cliente, simplificando enormemente el manejo de formularios y mutaciones de datos.

Hasta hace poco, desplegar aplicaciones Next.js con estas características modernas en Cloudflare Pages era complicado o directamente imposible. Sin embargo, con las últimas mejoras en el soporte de Cloudflare para Next.js y las funciones serverless, ahora es posible y sorprendentemente sencillo.

En este tutorial te muestro paso a paso cómo desplegar una aplicación Next.js completa con App Router y Server Actions en Cloudflare Pages, aprovechando al máximo la infraestructura global de Cloudflare.

💡 Repositorio Demo: Puedes acceder al código completo de este tutorial en GitHub: nextjs-cloudflare-demo. El repositorio incluye toda la configuración y código necesario para seguir el tutorial.

🚀 ¿Quieres saltarte la configuración? Si prefieres empezar directamente con un proyecto listo para producción —con autenticación (Better Auth), base de datos (Drizzle + Supabase), CI/CD con GitHub Actions y deploy automático en Cloudflare Pages— echa un vistazo al Next.js + Cloudflare Pages Starter Kit. De cero a desplegado en ~30 minutos.

¿Por qué Cloudflare Pages para Next.js?

Antes de saltar al tutorial, déjame explicarte por qué considero que Cloudflare Pages es una excelente opción para alojar aplicaciones Next.js en 2025:

Ventajas de Cloudflare Pages

Red Global: Más de 275+ ubicaciones en todo el mundo significa que tu aplicación estará cerca de tus usuarios.
Funciones Serverless Incluidas: Soporte nativo para Server Actions y API Routes sin configuración adicional.
Precios Competitivos: Plan gratuito muy generoso, ideal para proyectos personales y startups.
Rendimiento Excelente: CDN integrado y optimizaciones automáticas.
Facilidad de Despliegue: Integración directa con GitHub y GitLab.

Como mencioné en mi experiencia moviendo proyectos a Cloudflare, he tenido muy buenas experiencias con su plataforma, especialmente en términos de rendimiento y costos.

Requisitos Previos

Para seguir este tutorial, necesitarás:

Node.js 18+ instalado
Una cuenta en Cloudflare
Una cuenta en GitHub (para el despliegue automático)
Conocimientos básicos de React y Next.js
Familiaridad con el App Router de Next.js

Paso 1: Creando la Aplicación Next.js de Ejemplo

Tienes dos opciones para seguir este tutorial:

Opción A: Clonar el Repositorio Demo (Recomendado)

Si quieres empezar directamente con el código completo:

git clone https://github.com/siner/nextjs-cloudflare-demo.git
cd nextjs-cloudflare-demo
npm install

Opción B: Crear la Aplicación desde Cero

Vamos a crear una aplicación Next.js desde cero que incluya tanto el App Router como Server Actions. Esta será nuestra aplicación de prueba.

npx create-next-app@latest nextjs-cloudflare-demo
cd nextjs-cloudflare-demo

Durante la instalación, asegúrate de seleccionar:

✅ TypeScript
✅ ESLint
✅ Tailwind CSS
✅ src/ directory
✅ App Router
❌ Turbopack (opcional, pero recomendado para desarrollo)

Paso 2: Configurando la Estructura del Proyecto

Vamos a crear una aplicación simple con un formulario que utilice Server Actions. Esta demostración incluirá:

Una página principal con un formulario
Server Actions para manejar el envío del formulario
Gestión de estado para mostrar mensajes de éxito/error

Creando la Página Principal

Primero, vamos a modificar src/app/page.tsx:

import { ContactForm } from '@/components/contact-form'
import { Suspense } from 'react'

export default function Home() {
  return (
    <main className="min-h-screen bg-gradient-to-br from-blue-50 to-indigo-100 py-12 px-4">
      <div className="max-w-2xl mx-auto">
        <div className="text-center mb-12">
          <h1 className="text-4xl font-bold text-gray-900 mb-4">
            Next.js + Cloudflare Pages
          </h1>
          <p className="text-xl text-gray-600">
            Demo de App Router con Server Actions desplegado en Cloudflare Pages
          </p>
        </div>

        <div className="bg-white rounded-lg shadow-lg p-8">
          <h2 className="text-2xl font-semibold text-gray-800 mb-6">
            Formulario de Contacto
          </h2>
          <Suspense fallback={<div>Cargando formulario...</div>}>
            <ContactForm />
          </Suspense>
        </div>

        <div className="mt-8 text-center">
          <p className="text-gray-500">
            Este formulario utiliza Server Actions para procesar los datos
          </p>
        </div>
      </div>
    </main>
  )
}

Creando las Server Actions

Ahora vamos a crear nuestras Server Actions. Crea el archivo src/app/actions.ts:

'use server'

import { revalidatePath } from 'next/cache'
import { redirect } from 'next/navigation'

export type FormState = {
  message: string
  type: 'success' | 'error' | null
}

export async function submitContactForm(
  prevState: FormState,
  formData: FormData
): Promise<FormState> {
  // Extraer datos del formulario
  const name = formData.get('name') as string
  const email = formData.get('email') as string
  const message = formData.get('message') as string

  // Validación básica
  if (!name || !email || !message) {
    return {
      message: 'Todos los campos son obligatorios',
      type: 'error'
    }
  }

  // Validación de email básica
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/
  if (!emailRegex.test(email)) {
    return {
      message: 'Por favor, introduce un email válido',
      type: 'error'
    }
  }

  try {
    // Simular procesamiento (aquí conectarías con tu base de datos, API externa, etc.)
    await new Promise((resolve) => setTimeout(resolve, 1000))

    // En un caso real, aquí guardarías en base de datos, enviarías email, etc.
    console.log('Datos del formulario:', { name, email, message })

    // Revalidar la página para mostrar los cambios
    revalidatePath('/')

    return {
      message: `¡Gracias ${name}! Tu mensaje ha sido enviado correctamente.`,
      type: 'success'
    }
  } catch (error) {
    console.error('Error procesando formulario:', error)
    return {
      message: 'Error interno del servidor. Inténtalo de nuevo.',
      type: 'error'
    }
  }
}

// Server Action alternativa que muestra redirect
export async function submitAndRedirect(formData: FormData) {
  const name = formData.get('name') as string

  if (!name) {
    throw new Error('Nombre es requerido')
  }

  // Procesar datos...
  await new Promise((resolve) => setTimeout(resolve, 500))

  // Redirigir a página de éxito
  redirect(`/success?name=${encodeURIComponent(name)}`)
}

Creando el Componente del Formulario

Crea src/components/contact-form.tsx:

'use client'

import { useFormState, useFormStatus } from 'react-dom'
import { submitContactForm, type FormState } from '@/app/actions/contact-form'

const initialState: FormState = {
  message: '',
  type: null
}

function SubmitButton() {
  const { pending } = useFormStatus()

  return (
    <button
      type="submit"
      disabled={pending}
      className="w-full bg-blue-600 text-white py-3 px-4 rounded-lg hover:bg-blue-700 disabled:opacity-50 disabled:cursor-not-allowed transition-colors duration-200"
    >
      {pending ? (
        <>
          <svg
            className="animate-spin -ml-1 mr-3 h-5 w-5 text-white inline"
            xmlns="http://www.w3.org/2000/svg"
            fill="none"
            viewBox="0 0 24 24"
          >
            <circle
              className="opacity-25"
              cx="12"
              cy="12"
              r="10"
              stroke="currentColor"
              strokeWidth="4"
            ></circle>
            <path
              className="opacity-75"
              fill="currentColor"
              d="M4 12a8 8 0 018-8V0C5.373 0 0 5.373 0 12h4zm2 5.291A7.962 7.962 0 014 12H0c0 3.042 1.135 5.824 3 7.938l3-2.647z"
            ></path>
          </svg>
          Enviando...
        </>
      ) : (
        'Enviar Mensaje'
      )}
    </button>
  )
}

export function ContactForm() {
  const [state, formAction] = useFormState(submitContactForm, initialState)

  return (
    <form action={formAction} className="space-y-6">
      <div>
        <label
          htmlFor="name"
          className="block text-sm font-medium text-gray-700 mb-2"
        >
          Nombre completo
        </label>
        <input
          type="text"
          id="name"
          name="name"
          required
          className="w-full px-3 py-2 border border-gray-300 rounded-lg focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
          placeholder="Tu nombre"
        />
      </div>

      <div>
        <label
          htmlFor="email"
          className="block text-sm font-medium text-gray-700 mb-2"
        >
          Email
        </label>
        <input
          type="email"
          id="email"
          name="email"
          required
          className="w-full px-3 py-2 border border-gray-300 rounded-lg focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
          placeholder="tu@email.com"
        />
      </div>

      <div>
        <label
          htmlFor="message"
          className="block text-sm font-medium text-gray-700 mb-2"
        >
          Mensaje
        </label>
        <textarea
          id="message"
          name="message"
          rows={4}
          required
          className="w-full px-3 py-2 border border-gray-300 rounded-lg focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent resize-none"
          placeholder="Escribe tu mensaje aquí..."
        />
      </div>

      <SubmitButton />

      {state.message && (
        <div
          className={`p-4 rounded-lg ${
            state.type === 'success'
              ? 'bg-green-50 text-green-800 border border-green-200'
              : 'bg-red-50 text-red-800 border border-red-200'
          }`}
        >
          <p className="text-sm font-medium">{state.message}</p>
        </div>
      )}
    </form>
  )
}

Creando la Página de Éxito (Opcional)

Crea src/app/success/page.tsx:

import Link from 'next/link'
import { Suspense } from 'react'

function SuccessContent({ searchParams }: { searchParams: { name?: string } }) {
  const name = searchParams.name || 'Usuario'

  return (
    <main className="min-h-screen bg-gradient-to-br from-green-50 to-emerald-100 py-12 px-4">
      <div className="max-w-2xl mx-auto text-center">
        <div className="bg-white rounded-lg shadow-lg p-8">
          <div className="mb-6">
            <div className="mx-auto w-16 h-16 bg-green-100 rounded-full flex items-center justify-center mb-4">
              <svg
                className="w-8 h-8 text-green-600"
                fill="none"
                stroke="currentColor"
                viewBox="0 0 24 24"
              >
                <path
                  strokeLinecap="round"
                  strokeLinejoin="round"
                  strokeWidth={2}
                  d="M5 13l4 4L19 7"
                />
              </svg>
            </div>
            <h1 className="text-3xl font-bold text-gray-900 mb-2">
              ¡Mensaje Enviado!
            </h1>
            <p className="text-xl text-gray-600">
              Gracias {decodeURIComponent(name)}, tu mensaje ha sido procesado
              correctamente.
            </p>
          </div>

          <Link
            href="/"
            className="inline-block bg-blue-600 text-white py-3 px-6 rounded-lg hover:bg-blue-700 transition-colors duration-200"
          >
            Volver al Inicio
          </Link>
        </div>
      </div>
    </main>
  )
}

export default async function SuccessPage({
  searchParams
}: {
  searchParams: Promise<{ name?: string }>
}) {
  const params = await searchParams
  return (
    <Suspense fallback={<div>Cargando...</div>}>
      <SuccessContent searchParams={params} />
    </Suspense>
  )
}

Paso 3: Configuración para Cloudflare Pages

Ahora viene la parte crucial: configurar Next.js para que funcione correctamente en Cloudflare Pages.

Instalando el Adaptador de Cloudflare

npm install @opennextjs/cloudflare

Nota: @opennextjs/cloudflare es la herramienta oficial actualizada para desplegar Next.js en Cloudflare Pages. Reemplaza al anterior @cloudflare/next-on-pages y ofrece mejor soporte para las características modernas de Next.js como Server Actions y el App Router.

Configurando next.config.js

Crea o modifica next.config.js en la raíz del proyecto:

/** @type {import('next').NextConfig} */
const nextConfig = {
  // Optimizaciones para Cloudflare
  images: {
    unoptimized: true // Cloudflare optimiza las imágenes por defecto
  },

  // Configuración adicional para mejor compatibilidad
  swcMinify: true,

  // Headers de seguridad (opcional pero recomendado)
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'X-Frame-Options',
            value: 'DENY'
          },
          {
            key: 'X-Content-Type-Options',
            value: 'nosniff'
          }
        ]
      }
    ]
  }
}

module.exports = nextConfig

Configuración de Package.json

Actualiza los scripts en tu package.json:

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint",
    "pages:build": "opennextjs-cloudflare build",
    "preview": "npm run pages:build && opennextjs-cloudflare preview",
    "deploy": "npm run pages:build && opennextjs-cloudflare deploy",
    "cf-typegen": "wrangler types --env-interface CloudflareEnv cloudflare-env.d.ts"
  }
}

Configuración de OpenNext

Crea un archivo open-next.config.ts en la raíz del proyecto:

import { defineCloudflareConfig } from '@opennextjs/cloudflare'

export default defineCloudflareConfig({
  // Configuraciones específicas para tu proyecto
})

Paso 4: Preparando el Repositorio

Estructura Final del Proyecto

Tu proyecto debería tener esta estructura:

nextjs-cloudflare-demo/
├── src/
│   ├── app/
│   │   ├── actions.ts
│   │   ├── globals.css
│   │   ├── layout.tsx
│   │   ├── page.tsx
│   │   └── success/
│   │       └── page.tsx
│   └── components/
│       └── ContactForm.tsx
├── next.config.js
├── open-next.config.ts
├── package.json
├── tailwind.config.js
└── tsconfig.json

Archivo .gitignore

Asegúrate de que tu .gitignore incluya:

# Dependencies
node_modules/

# Next.js
.next/
out/

# OpenNext y Cloudflare
.open-next/
.wrangler/

# Environment variables
.env*.local

# Logs
*.log

# Runtime data
pids
*.pid
*.seed
*.pid.lock

Commiteando el Código

git add .
git commit -m "feat: Aplicación Next.js con App Router y Server Actions para Cloudflare Pages"
git push origin main

Desarrollo y Previsualización Local

Antes de desplegar, es importante probar localmente con el runtime de Cloudflare:

Desarrollo Regular

Para desarrollo regular, usa el servidor de Next.js:

npm run dev

Previsualización con Runtime de Cloudflare

Para probar cómo funcionará en producción:

npm run preview

Este comando:

Construye tu aplicación con el adaptador de OpenNext
La sirve localmente usando el runtime de workers (mismo que usa Cloudflare)
Te permite probar Server Actions y otras características específicas de Cloudflare

Paso 5: Configurando Cloudflare Pages

Creando el Proyecto en Cloudflare Pages

Ve a Cloudflare Dashboard
Navega a Pages en el menú lateral
Haz clic en "Crear Proyecto"
Selecciona "Conectar a Git"
Autoriza a Cloudflare a acceder a tu repositorio de GitHub
Selecciona tu repositorio nextjs-cloudflare-demo

Configuración de Build

En la pantalla de configuración de build, usa estos ajustes:

Framework preset: Next.js
Build command: npm run pages:build
Build output directory: .open-next/assets (o .open-next según la configuración)
Root directory: / (raíz del proyecto)

Variables de Entorno (Opcional)

Si tu aplicación necesita variables de entorno, puedes agregarlas en la sección "Variables de Entorno":

NODE_VERSION=18
NEXT_TELEMETRY_DISABLED=1

Configuración Avanzada

En "Configuración Avanzada", puedes ajustar:

Compatibility flags: nodejs_compat (para Server Actions)
Node.js compatibility: Habilitado

Paso 6: Despliegue y Verificación

Iniciando el Despliegue

Haz clic en "Guardar y Desplegar". Cloudflare comenzará a:

Clonar tu repositorio
Instalar dependencias (npm install)
Ejecutar el build (npm run pages:build)
Desplegar a la red global de Cloudflare

Monitoreando el Progreso

Puedes seguir el progreso del despliegue en tiempo real. El proceso típicamente toma 2-5 minutos.

Verificando la Funcionalidad

Una vez completado el despliegue:

Visita tu sitio: Cloudflare te proporcionará una URL (ej: https://nextjs-cloudflare-demo.pages.dev)
Prueba el formulario: Completa y envía el formulario de contacto
Verifica las Server Actions: El formulario debería procesarse correctamente en el servidor
Revisa las funciones: En el dashboard de Cloudflare, ve a Pages > Tu Proyecto > Funciones para ver las estadísticas de uso

Paso 7: Configuración de Dominio Personalizado (Opcional)

Agregando tu Dominio

Si tienes un dominio personalizado:

Ve a Pages > Tu Proyecto > Configuración
Haz clic en "Dominios Personalizados"
Haz clic en "Configurar dominio personalizado"
Introduce tu dominio (ej: mi-app.midominio.com)
Sigue las instrucciones para configurar los registros DNS

Configurando SSL

Cloudflare proporciona SSL automáticamente. Para dominios personalizados:

Asegúrate de que tu dominio esté gestionado por Cloudflare
Habilita "SSL/TLS Encryption Mode: Full"
Activa "Always Use HTTPS"

Optimizaciones y Mejores Prácticas

Performance

Caching: Cloudflare cachea automáticamente assets estáticos
Minification: Habilitada por defecto para CSS, JS y HTML
Brotli Compression: Automática para mejor compresión

Seguridad

// next.config.js - Headers de seguridad adicionales
async headers() {
  return [
    {
      source: '/(.*)',
      headers: [
        {
          key: 'Strict-Transport-Security',
          value: 'max-age=31536000; includeSubDomains'
        },
        {
          key: 'Content-Security-Policy',
          value: "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'"
        }
      ]
    }
  ]
}

Monitoreo

Analytics: Habilita Cloudflare Web Analytics
Real User Monitoring: Para métricas de rendimiento real
Logs: Revisa logs de funciones para debugging

Troubleshooting Común

Problemas con Server Actions

Error: "Server Actions not working" Solución:

Verifica que nodejs_compat esté habilitado
Asegúrate de usar 'use server' al inicio de tus actions
Revisa los logs de funciones en Cloudflare

Build Failures

Error: "Build failed" Solución:

Verifica que @opennextjs/cloudflare esté instalado
Usa Node.js 18+
Revisa la configuración de next.config.js

Runtime Errors

Error: "Runtime errors in production" Solución:

Revisa los logs de Pages Functions
Verifica compatibilidad de dependencias con Workers Runtime
Considera usar polyfills si es necesario

Limitaciones a Considerar

Compatibilidad del Adaptador OpenNext

Compatibilidad con Windows: Actualmente, @opennextjs/cloudflare no es totalmente compatible con Windows. Se espera compatibilidad completa en la versión 1.0.
Runtime de Edge: El adaptador actualmente solo soporta el runtime de Node.js de Next.js. El soporte para Edge Runtime está planificado para la próxima versión principal.

Workers Runtime Limitations

CPU Time: Límite de 30 segundos por request en plan gratuito
Memory: Límite de memoria más restrictivo que Node.js tradicional
APIs: Algunas APIs de Node.js no están disponibles en el runtime de Workers

Next.js Features

Middleware: Soporte limitado, usa Workers en su lugar
Custom Server: No soportado, usa funciones en su lugar
Incremental Static Regeneration: Funcionalidad limitada

Conclusión

Desplegar Next.js con App Router y Server Actions en Cloudflare Pages usando @opennextjs/cloudflare es ahora más accesible y robusto que nunca. Este adaptador oficial, desarrollado por OpenNext, ofrece mejor compatibilidad y soporte para las características modernas de Next.js.

La combinación de la red global de Cloudflare, las funciones serverless integradas y el soporte mejorado para Next.js hace de esta una opción muy atractiva para aplicaciones modernas, especialmente considerando que OpenNext se ha convertido en el estándar para desplegar Next.js en entornos serverless fuera de Vercel.

Ventajas Clave

Rendimiento Global: Tu aplicación estará disponible desde +275 ubicaciones
Costo Efectivo: Plan gratuito muy generoso
Escalabilidad Automática: Sin configuración de infraestructura
Simplicidad: Despliegue automático desde Git
Funciones Incluidas: Server Actions funcionan out-of-the-box

Próximos Pasos

Conecta una base de datos (considera Supabase o PlanetScale)
Implementa autenticación con Better Auth
Agrega análisis con Cloudflare Analytics
Explora Cloudflare Workers para lógica adicional

Código Completo

Recuerda que puedes acceder al código completo de este tutorial en el repositorio de GitHub: nextjs-cloudflare-demo. Incluye:

✅ Configuración completa de OpenNext para Cloudflare
✅ Aplicación Next.js con App Router y Server Actions
✅ Formulario de contacto funcional con validación
✅ Componentes con manejo de estado y loading
✅ Configuración de despliegue optimizada
✅ Ejemplos de uso de Suspense y async components

¿Quieres ir un paso más allá?

Si este tutorial te ha servido y necesitas un punto de partida más completo —con autenticación, base de datos y CI/CD ya integrados— he empaquetado todo lo que aprendí desplegando proyectos reales en el Next.js + Cloudflare Pages Starter Kit:

🔐 Better Auth con email/password y Google OAuth
🗄️ Drizzle ORM + Supabase con esquema listo
🚀 CI/CD con GitHub Actions y deploy automático
🎨 Dashboard, sidebar y formularios listos con Tailwind
🛡️ Security headers configurados por defecto

Ver el starter en Gumroad →

¿Has probado Next.js en Cloudflare Pages? ¿Qué tal ha sido tu experiencia? ¡Me encantaría conocer tus casos de uso y cualquier truco adicional que hayas descubierto!

Si quieres explorar otras opciones de hosting o comparar con otros stacks, puedes revisar mi análisis de herramientas de desarrollo fullstack o mi experiencia personal con Next.js vs Astro.

Cómo organizo mi semana como desarrollador (y por qué he creado un kit descargable para ayudarte)

Wed, 11 Jun 2025 18:30:00 GMT

Ser desarrollador hoy en día implica muchas cosas: programar, atender reuniones, tomar decisiones, resolver bugs, documentar, ayudar a compañeros, planificar entregas... y todo esto mientras intentas mantener cierta calma mental y no olvidar nada importante.

Durante mucho tiempo, yo también iba semana a semana apagando fuegos. Tenía tareas sueltas por todas partes, proyectos a medias, ideas que nunca anotaba, y una sensación constante de que algo se me escapaba.

Todo cambió cuando empecé a aplicar GTD ("Getting Things Done") con una revisión semanal constante. Hoy te cuento por qué eso marcó la diferencia, y cómo he creado un kit para que tú también puedas aplicarlo en tu semana como desarrollador.

La revisión semanal: el ancla de mi organización

GTD es una metodología de productividad que se basa en tener un sistema fiable para capturar, organizar y revisar todo lo que tienes en la cabeza. Pero si hay un paso clave, ese es la revisión semanal.

Es el momento en que paras, tomas perspectiva y ordenas tu mundo. En 30 minutos puedes recuperar el control, decidir en qué vas a enfocar tu atención y empezar la semana con claridad mental.

Cómo hago mi revisión semanal

Cada viernes, abro mi sistema y hago lo siguiente:

Vaciar mi cabeza: anoto ideas, tareas pendientes, recordatorios...
Revisar mis proyectos: qué está en curso, qué necesita una acción.
Mirar mi calendario: compromisos, huecos reales, eventos clave.
Revisar tareas delegadas o esperando: seguimiento y control.
Organizar lo importante: etiquetar, reagrupar, eliminar lo innecesario.
Revisar lo que completé esa semana: sirve para motivarme y cerrar ciclo.

Uso herramientas como Todoist para las tareas, Notion para reflejar la revisión y un pequeño script en Node.js que me resume automáticamente mis tareas completadas por proyecto.

He creado un kit descargable con todo esto

Me lo han preguntado varias veces, así que decidí empaquetar mi sistema en un kit descargable que cualquiera pueda usar desde ya.

Revisión Pro: GTD para desarrolladores incluye:

Una guía PDF con el paso a paso que sigo cada semana
Una plantilla en Notion lista para usar y registrar tus revisiones
Un script en Node.js para generar tu resumen desde Todoist
Mis filtros y etiquetas GTD personales que puedes importar

Todo en un solo ZIP, con instrucciones y ejemplos incluidos. Ideal si eres desarrollador y quieres tener el control de tu semana sin complicarte la vida.

Puedes conseguirlo aquí

Está disponible en Gumroad por solo €19: 👉 Accede al kit aquí

Con una sola revisión semanal ya puedes notar la diferencia. Si te ayuda, me encantará recibir tu feedback. Y si hay interés, prepararé más kits y herramientas relacionadas con organización, automatización y productividad para desarrolladores.

Gracias por leer, y feliz revisión 🚀

De código a cultivo: cómo descubrí mi pasión por las plantas

Tue, 13 May 2025 00:00:00 GMT

Durante años, mi día a día ha girado en torno al código, a los proyectos y a las pantallas. Soy desarrollador web y paso muchas horas frente al ordenador, saltando entre líneas de JavaScript, reuniones y revisiones. Pero hace poco, casi sin buscarlo, encontré un nuevo espacio de calma en un rincón inesperado: las plantas.

🌿 El primer brote

Todo empezó de forma sencilla. Una planta por aquí, un regalo por allá. No tenía mucha idea de cómo cuidarlas, más allá de lo que he podido ver a otros, pero me generaban cierta curiosidad. Con el tiempo, ese rincón verde se convirtió en algo más que decoración. Empecé a leer, a observar, a entender.

La primera que me atrapó fue una planta de albahaca. Me encantaba verla crecer, oler sus hojas, y más aún, usarla para cocinar. Pronto llegaron otras: hierbabuena, tomillo, perejil... y la cosa empezó a parecerse más a un mini huerto que a un capricho pasajero.

💧 De rutina a ritual

Lo que al principio era "no olvidar regar" se transformó en un pequeño ritual diario. Revisar si necesitaban agua, quitar hojas secas, ver si alguna había brotado... Es curioso cómo algo tan simple puede convertirse en una forma de desconexión tan efectiva.

Las plantas me obligan a parar. A mirar con atención. A respetar su ritmo, que no es el mío, ni el del mundo digital. Y eso, en medio del caos del día a día, es un pequeño lujo.

🌱 Mi pequeño huerto de ventana

Ahora mismo tengo varias aromáticas en una jardinera: albahaca, perejil y tomillo. También tengo una maceta individual con hierbabuena que me viene fenomenal para hacer infusiones de té verde con hierbabuena.

Además, he empezado a usar Todoist para hacer seguimiento de sus cuidados: riego, podas, trasplantes... creando un proyecto nuevo para la gestión de las plantas, con sus tareas y notas. Si te interesa cómo organizo mis tareas y proyectos, puedes leer cómo aplico GTD con Notion y Todoist o mi flujo semanal GTD como desarrollador.

🧠 Lo que me han enseñado las plantas

Cuidar plantas me ha enseñado más de lo que imaginaba. Me ha recordado que no todo es inmediato. Que a veces hay que esperar, observar, dejar espacio. Que no todo se puede forzar. Y que hay una satisfacción muy particular en ver cómo algo crece porque tú lo cuidas.

Es curioso, pero he encontrado muchos paralelismos con el desarrollo de software: cuidar los detalles, tener paciencia, resolver problemas paso a paso… y sobre todo, disfrutar del proceso, no solo del resultado. Si te interesa cómo aplico esta filosofía en mis proyectos, puedes leer mis objetivos personales y profesionales para 2023.

🌻 ¿Y ahora qué?

Me gustaría seguir ampliando mi pequeña jungla doméstica. Estoy considerando hacer esquejes y aprender a propagar las que ya tengo.

Si estás leyendo esto y nunca has tenido una planta, te animo a probar con una fácil. No necesitas mucho espacio ni experiencia, solo ganas de cuidar y un poco de constancia. A veces, una simple maceta puede transformar más de lo que imaginas.

Mi Experiencia Real: Cuándo elijo Next.js y cuándo Astro para mis proyectos personales

Sat, 26 Apr 2025 00:00:00 GMT

Si estás metido en el mundo del desarrollo web moderno, seguro que más de una vez te has enfrentado a esta pregunta al empezar un proyecto personal: ¿Elijo Next.js o me lanzo con Astro? Ambos son frameworks fantásticos, potentes y con comunidades activas, pero... ¿cuál es el adecuado para ti y para ese proyecto concreto?

En 2025, la elección sigue siendo muy relevante. Después de haber trabajado con ambos en varios de mis side-projects, he desarrollado mi propio "marco mental" para decidir. En este artículo no voy a decirte cuál es objetivamente mejor (spoiler: ninguno lo es), sino que voy a compartir mi proceso real y mis criterios personales para elegir entre Next.js y Astro, basado en mi propia experiencia.

Para poner un poco de contexto y cómo los percibo yo:

Astro: Lo asocio inmediatamente con su concepto de "islas de interactividad", su enfoque radical en enviar el mínimo JavaScript posible por defecto (¡cero JS por defecto!) y su excelente manejo del contenido estático (Markdown, MDX). Ideal para la velocidad.
Next.js: Lo veo como el gigante versátil del ecosistema React, con capacidades full-stack muy potentes (gracias al App Router, Server Components, Server Actions...), una flexibilidad enorme en el renderizado y un ecosistema maduro para construir aplicaciones complejas.

¡Vamos al lío!

Mis Criterios de Decisión Clave

Cuando evalúo si usar Next.js o Astro para un nuevo proyecto personal, me hago principalmente estas preguntas:

1. ¿Cuánta Interactividad Necesita el Proyecto y Dónde? (El Factor JavaScript)

Esta suele ser mi primera y más importante pregunta. Define en gran medida la arquitectura y el rendimiento final.

Escenario A: Interactividad Baja o Muy Localizada

Descripción: El proyecto es principalmente contenido estático (un blog, una landing page, una web de documentación, un portfolio) con puntos específicos y aislados de interacción: un carrusel de imágenes, un botón de suscripción a newsletter, quizás un buscador simple en el cliente, comentarios bajo los posts, un botón para cambiar el tema (modo oscuro/claro)...
Mi Elección Habitual: Astro
Mis Razones (Experiencia):
- Rendimiento por Defecto Imbatible: Astro envía cero JavaScript al cliente por defecto. Esto se traduce en páginas que cargan increíblemente rápido, lo cual es crucial para webs centradas en contenido donde la velocidad inicial y el SEO son prioritarios. Es una ventaja competitiva enorme.
- Islas de Interactividad: Cuando necesito algo de JavaScript (un componente para el modo oscuro, un formulario de contacto que valide en cliente), puedo "hidratar" solo ese componente específico usando una directiva client:*. El resto de la página permanece como HTML estático, rápido y ligero. Lo mejor es que puedo usar componentes de React, Vue, Svelte, etc., solo donde los necesito, ¡una flexibilidad genial sin penalizar el rendimiento global!
- Developer Experience (DX) para Contenido: La sintaxis de los archivos .astro me resulta muy natural y productiva. Mezcla HTML con expresiones JavaScript de forma sencilla y es ideal para maquetar páginas ricas en contenido sin la complejidad de un framework SPA completo.
Ejemplo Personal: Mi propia web personal, franmoreno.com, es un claro ejemplo. Está construida con Astro. El núcleo de la web es el contenido (artículos del blog escritos en Markdown, páginas estáticas...). La interactividad es mínima y localizada (algún botón o componente específico). Astro me permite tener un rendimiento excelente y gestionar el contenido de forma muy cómoda, sin la sobrecarga de JavaScript innecesario.

Escenario B: Interactividad Alta, Compleja o Global

Descripción: Necesito una experiencia de usuario muy dinámica, más cercana a una aplicación web (SPA) o incluso una aplicación de escritorio. Hablamos de dashboards con múltiples filtros interactivos, estado que se comparte y sincroniza entre muchas partes de la UI, interfaces complejas que reaccionan en tiempo real a las acciones del usuario, gestión de usuarios (login, perfiles), lógica de negocio significativa en el frontend...
Mi Elección Habitual: Next.js
Mis Razones (Experiencia):
- Ecosistema React Maduro: Para aplicaciones complejas, el ecosistema maduro de React es una ventaja inmensa. Librerías de componentes UI (como Shadcn/UI, Material UI, Chakra UI...), herramientas robustas de gestión de estado (Zustand, Context API, Redux, Jotai)...), librerías para visualización de datos (Recharts, Nivo)...), etc., están fácilmente disponibles, bien documentadas y se integran sin fricciones.
- Gestión del Estado Sofisticada: En aplicaciones con mucha interacción, gestionar el estado de forma coherente y escalable es vital. Next.js, al estar basado en React, me permite usar patrones y herramientas probadas (Context, hooks, librerías de estado) para manejar tanto el estado local de los componentes como el estado global de la aplicación de forma eficiente.
- Capacidades Full-Stack Integradas: Con el App Router, los Server Components (RSC) y las Server Actions, puedo definir lógica de backend (acceso a bases de datos, llamadas a APIs externas, autenticación, procesamiento de formularios) directamente dentro de mi proyecto Next.js. Esto simplifica enormemente la arquitectura para muchos tipos de aplicaciones, evitando tener que gestionar un backend separado si no es estrictamente necesario.
- Flexibilidad en el Renderizado: Puedo elegir estratégicamente cómo renderizar cada parte de la aplicación (Server-Side Rendering - SSR, Static Site Generation - SSG, Incremental Static Regeneration - ISR, Client-Side Rendering - CSR) según las necesidades específicas, optimizando tanto el rendimiento como la frescura de los datos.
Ejemplo Personal: Actualmente estoy desarrollando un proyecto (aún no público) que es esencialmente una aplicación web compleja. Incluye un panel de administración, un área privada para usuarios con registro y gestión de suscripciones, dashboards con gráficas interactivas que muestran datos en tiempo real, y generación de informes. Para este tipo de proyecto, con tanta lógica de negocio, gestión de estado compleja y necesidad de interactividad rica, Next.js fue la elección clara desde el principio. Me permite aprovechar todo el ecosistema React y las capacidades full-stack integradas para construir la aplicación de manera más eficiente y estructurada.

2. ¿Cuál es la Naturaleza del Contenido y la Necesidad de Dinamismo?

El tipo de contenido y cómo/cuándo se actualiza es otro factor fundamental.

Escenario A: Contenido Mayoritariamente Estático o Generado en Build Time

Descripción: La gran mayoría del contenido se puede generar cuando construyo el sitio (en el build time) y no cambia con cada petición del usuario. Blogs, portfolios, webs de documentación, landings promocionales...
Mi Elección Habitual: Astro
Mis Razones (Experiencia):
- Content Collections: Para sitios ricos en contenido como blogs o documentación, las Content Collections de Astro son una auténtica maravilla. Te permiten organizar tus archivos Markdown o MDX en carpetas, definir un esquema (schema) para el frontmatter usando Zod (asegurando así que todos los posts tengan título, fecha, autor, etc., y con el tipo de dato correcto), y luego consultar ese contenido de forma segura y tipada en tus páginas .astro. Simplifica enormemente la gestión del contenido y evita errores tontos.
- Optimización para SSG (Static Site Generation): Astro está diseñado principalmente para generar sitios estáticos. Construye todas las páginas HTML en el momento del despliegue (o en tu máquina antes de subirlo). Esto resulta en un rendimiento excelente, gran seguridad (menos superficie de ataque al no haber servidor ejecutando código por petición) y fácil despliegue en cualquier hosting estático (Netlify, Vercel, Cloudflare Pages, GitHub Pages...). Puedes activar el modo SSR si lo necesitas, pero su fuerte es el SSG.
Ejemplo Personal: De nuevo, mi web franmoreno.com encaja perfectamente aquí. Utilizo las Content Collections para gestionar todos los artículos del blog. Defino un esquema para asegurar que cada post tenga los campos necesarios (título, descripción, fecha de publicación, imagen de portada...) y Astro me ayuda a obtener y mostrar esa información de forma segura y sencilla. La generación estática hace que el blog sea rapidísimo.

Escenario B: Contenido Dinámico, Personalizado, Rutas Protegidas o Dependiente de APIs Externas

Descripción: Necesito mostrar contenido diferente según el usuario que ha iniciado sesión, conectar a bases de datos para obtener datos actualizados en tiempo real, tener áreas privadas (rutas protegidas por login), o mostrar contenido que cambia muy frecuentemente y que proviene de fuentes externas como APIs REST o GraphQL.
Mi Elección Habitual: Next.js
Mis Razones (Experiencia):
- Fetching de Datos Flexible y Potente: Next.js (especialmente con el App Router y los Server Components) ofrece múltiples y potentes formas de obtener datos: en el servidor (durante el renderizado SSR o al construir Server Components), en el cliente (con hooks como useEffect o librerías como SWR/React Query) o de forma incremental (ISR). Esto es ideal para consumir APIs. Puedes obtener los datos en el servidor para el renderizado inicial (mejorando el SEO y el rendimiento percibido) y luego actualizarlos o revalidarlos en el cliente si es necesario.
- Server Actions / API Routes: Si necesito realizar operaciones que modifican datos (mutaciones) como enviar un formulario, actualizar datos del perfil de usuario, añadir un producto al carrito, etc., las Server Actions (en App Router) o las API Routes (en Pages Router o App Router) de Next.js me permiten crear endpoints seguros dentro del mismo proyecto. Puedo interactuar con mi base de datos o APIs externas sin exponer lógica sensible o credenciales en el navegador del cliente.
- Gestión de Autenticación Integrada: Integrar sistemas de autenticación (como NextAuth.js, Clerk, u otros proveedores) para proteger rutas y personalizar el contenido según el usuario conectado es un proceso más directo y con más recursos disponibles en Next.js, dado su enfoque de aplicación completa. Hay muchos tutoriales y ejemplos específicos.
Ejemplo Personal: He desarrollado un área de clientes para un proyecto freelance utilizando Next.js. Toda la información que se muestra (datos del usuario, historial de pedidos, facturas descargables, etc.) proviene íntegramente de una API REST externa. Next.js me facilita enormemente el trabajo: uso Server Components para hacer las llamadas a la API en el servidor al cargar las páginas (asegurando que los datos están actualizados), gestiono la autenticación del usuario con NextAuth.js para proteger el acceso, y uso Client Components con librerías como SWR para volver a validar datos o realizar actualizaciones (ej: cambiar dirección) sin recargar la página completa. Intentar replicar esto con un enfoque puramente estático como el de Astro por defecto sería mucho más complejo y requeriría soluciones más "manuales".

3. ¿Cómo Afecta a Mi Flujo de Desarrollo (Developer Experience - DX)?

Aunque a veces es secundario frente a los requisitos técnicos, cómo me siento desarrollando y cuán productivo soy también influye en mi elección, especialmente en proyectos personales donde el disfrute es importante.

Curva de Aprendizaje:

Astro: Para mí, la curva de aprendizaje de Astro es significativamente más suave, especialmente si vienes del desarrollo web más tradicional (HTML, CSS, JS) o si no tienes una base fuerte en React. Con conceptos básicos es suficiente para empezar a construir sitios eficientes rápidamente. La sintaxis de los archivos .astro es muy intuitiva. No necesitas entender conceptos complejos de React (hooks, estado global, contexto) para ser productivo desde el minuto uno en proyectos centrados en contenido.
Next.js: Si ya tienes una base sólida en React, empezar con Next.js (especialmente con el antiguo Pages Router) es bastante natural. Sin embargo, dominar las características más modernas y potentes como el App Router, los Server Components (RSC), las Server Actions y las sutilezas del renderizado mixto (SSR/SSG/ISR/Client) requiere un esfuerzo adicional y entender conceptos más avanzados. La curva se empina si quieres aprovechar todo su potencial full-stack, aunque la documentación oficial es muy buena.

Ecosistema y Herramientas:

Next.js: Aquí es donde Next.js (y por extensión, React) realmente brilla por su madurez y tamaño. La comunidad es gigantesca, lo que significa que hay una cantidad enorme de librerías, herramientas, tutoriales, artículos y soluciones a problemas comunes disponibles. Si tienes una duda o necesitas una funcionalidad específica (un componente de UI particular, una librería de animación, una solución de autenticación), es muy probable que alguien ya la haya resuelto o creado una herramienta para ello. Esto acelera mucho el desarrollo de aplicaciones complejas.
Astro: Su ecosistema está creciendo muy rápidamente y es muy activo, con integraciones oficiales muy bien cuidadas (Tailwind, MDX, Partytown, frameworks UI...). Sin embargo, es innegable que es más joven y, por tanto, más pequeño que el de React/Next.js. A veces puedes encontrar menos ejemplos o librerías específicas para casos de uso muy concretos, aunque la documentación oficial es excelente y la comunidad en Discord es muy colaborativa y dispuesta a ayudar.

4. Despliegue y Hosting

Aunque ambos frameworks son flexibles, hay matices:

Astro (Modo SSG por defecto):

Ventaja: Genera archivos estáticos (HTML, CSS, JS). Puedes desplegarlo en cualquier hosting estático, muchos de ellos gratuitos o muy económicos (Netlify, Vercel, Cloudflare Pages – sobre el que puedes leer mi experiencia moviendo proyectos aquí –, GitHub Pages, AWS S3...). Es simple y robusto.
Consideración: Si activas el modo SSR (Server-Side Rendering), necesitarás un entorno que pueda ejecutar Node.js (como Vercel, Netlify Functions, un servidor propio, etc.), similar a Next.js.

Next.js:

Ventaja: Plataformas como Vercel (los creadores de Next.js) ofrecen una integración perfecta y optimizada, aprovechando todas sus características (SSR, ISR, Server Actions, Edge Functions...).
Consideración: Si usas funcionalidades avanzadas (SSR, ISR, Server Actions), generalmente necesitarás un hosting que soporte Node.js o plataformas específicas (Vercel, Netlify, AWS Amplify...). Desplegar en hosting puramente estático es posible si solo usas SSG, pero limita el potencial del framework.

5. Comunidad y Soporte

Next.js: Tiene una de las comunidades más grandes y activas en el desarrollo web. Encontrarás respuestas en Stack Overflow, GitHub Discussions, blogs, YouTube, etc., para casi cualquier problema. El soporte de Vercel es también un punto fuerte.
Astro: Comunidad más pequeña pero muy entusiasta, amigable y en rápido crecimiento. Su servidor de Discord es especialmente activo y útil para obtener ayuda directa. La documentación oficial es de alta calidad.

Mis Proyectos Como Ejemplo

Para ilustrar mi proceso de decisión, aquí algunos ejemplos reales:

Proyecto A: Mi Web Personal (franmoreno.com) - Elegí Astro

Justificación: Sitio centrado 100% en contenido (blog en Markdown, páginas estáticas). Requisitos: máximo rendimiento posible (carga rápida, buen score en Lighthouse) y una gestión sencilla del contenido. La interactividad es mínima y aislada.
Resultado: Astro fue la elección perfecta. El sitio es increíblemente rápido, las Content Collections son una gozada para gestionar el blog, y la DX para maquetar las páginas fue muy agradable y directa. No necesitaba la complejidad ni el JavaScript de React para este caso.

Proyecto B: TorneosPokerLive.com - Elegí Next.js (¡Tras una Migración desde Astro!)

Justificación Inicial (Astro): Este proyecto empezó como una web para mostrar información estática/semi-estática de torneos de póker en vivo (contenido). Astro parecía una buena opción por su rendimiento y manejo de contenido.
La Necesidad de Migrar: Sin embargo, el plan a largo plazo siempre fue añadir funcionalidades complejas para usuarios: registro/login, seguimiento de casinos favoritos, comentarios, notificaciones, quizás incluso compra de entradas en un futuro. Me di cuenta de que para escalar hacia esas funcionalidades, necesitaría un framework con capacidades full-stack más robustas, mejor gestión de estado y un ecosistema más preparado para aplicaciones web interactivas. Además, quería practicar y profundizar en Next.js con el App Router.
Resultado (Next.js): Migré el proyecto a Next.js. Aunque supuso rehacer parte del trabajo inicial, ahora tengo una base mucho más sólida y escalable para implementar las futuras funcionalidades de usuario. Puedo usar Server Components para cargar datos dinámicos, Server Actions para las interacciones con la base de datos, integrar fácilmente autenticación y aprovechar todo el ecosistema React para construir la interfaz de usuario compleja que necesitaré. Si el proyecto se hubiera quedado solo en mostrar contenido, me habría quedado felizmente en Astro, pero la visión a futuro justificó el cambio.

Proyecto C: Aplicación SaaS Interna (No pública) - Elegí Next.js

Justificación: Una aplicación web con dashboard, gestión de usuarios, conexión a base de datos, formularios complejos, generación de reportes PDF, integración con APIs externas. Claramente un caso de uso de aplicación interactiva (SaaS) y con lógica de negocio.
Resultado: Next.js fue la elección obvia y acertada. El App Router, Server Components y Server Actions permiten una arquitectura coherente y eficiente. El ecosistema React proporciona todas las herramientas necesarias para la UI y la gestión de estado.

Conclusión: El Contexto Manda Sobre la Herramienta

Al final del día, mi filosofía es clara y creo que es la más sensata: el contexto y los requisitos específicos del proyecto mandan sobre la elección de la herramienta. No hay un "mejor" framework universal.

Para resumir mi enfoque personal en 2025:

Elijo Astro cuando:

La prioridad número uno es el rendimiento y la velocidad de carga (sitios de contenido, landings).
El contenido es el rey (blogs, documentación, portfolios).
La interactividad es mínima o muy localizada (islas de JS).
Quiero una DX sencilla y directa para maquetar y gestionar contenido.

Elijo Next.js cuando:

Necesito construir una aplicación web compleja e interactiva (dashboards, áreas de usuario, SaaS).
El dinamismo, la personalización y los datos en tiempo real son fundamentales.
Quiero aprovechar el enorme ecosistema de React (librerías de UI, estado, etc.).
Necesito capacidades full-stack integradas (Server Components, Server Actions, API Routes).
Preveo una escalabilidad futura hacia funcionalidades de aplicación complejas, incluso si empiezo con algo más simple. (¡Este punto es clave y a menudo justifica elegir Next.js desde el principio!)

Esto es lo que me funciona a mí, basado en mis experiencias y el tipo de proyectos personales que suelo abordar. ¡Puede que tu caso, tus prioridades o tu experiencia previa te lleven a conclusiones diferentes!

La mejor recomendación que puedo darte es: experimenta. Monta un proyecto pequeño con ambos frameworks si tienes dudas. Siente la Developer Experience, prueba las funcionalidades clave que necesitas para tu caso de uso y decide por ti mismo cuál se adapta mejor.

Si quieres explorar otras herramientas modernas para desarrollo full-stack, también puedes echar un vistazo a este post.

Y ahora te pregunto a ti: ¿Qué te hace decidir entre Next.js y Astro? ¿Usas criterios similares? ¿Hay algún factor clave que se me haya escapado? ¡Me encantaría leer tu experiencia y tu opinión en los comentarios!

Mi Flujo GTD Semanal como Desarrollador: Herramientas y Rutinas para Mantener a Raya Proyectos Personales y Profesionales

Sat, 19 Apr 2025 00:00:00 GMT

¿Te suena esta imagen? Lunes por la mañana. Tienes abierto Cursor/VSCode/WebStorm/etc con varios proyectos, veinte pestañas en el navegador (documentación, Stack Overflow, Jira, GitHub, ChatGPT, el build fallido de anoche...), Slack/Teams/Gather explotando con notificaciones, el email pidiendo atención y, en algún lugar de tu mente, la vaga idea de ese side-project que querías empezar o ese curso de Kubernetes que te prometiste hacer. Estás en modo bombero, apagando fuegos, respondiendo a lo urgente, pero con la constante sensación de que las cosas importantes – las que realmente te hacen avanzar profesional y personalmente – se quedan atrás. Te sientes agobiado, quizás un poco quemado, y la idea de "perder el control" no es una metáfora, es tu realidad diaria.

El problema es real: como desarrolladores, manejamos un montón de cosas complejas. Proyectos del trabajo con fechas de entrega ajustadas, bugs inesperados que echan por tierra los planes, la necesidad constante de aprender nuevas tecnologías, mantener nuestros propios proyectos o contribuciones open-source, y además, intentar tener una vida fuera del código. ¿Cómo gestionar todo esto sin que la cabeza explote? ¿Cómo asegurarnos de que dedicamos tiempo a construir el futuro y no solo a parchear el presente?

Aquí es donde entra en juego GTD (Getting Things Done). Pero no te asustes, no vengo a venderte un sistema rígido y complicado. Para mí, GTD es una caja de herramientas mentales y una filosofía con ideas clave (si quieres una introducción, puedes leer este otro post). Y una de las más potentes, la que me devuelve la cordura semana tras semana, es la Revisión Semanal.

En este artículo, quiero compartir contigo mi sistema personal y práctico de revisión semanal GTD, adaptado específicamente a los líos que tenemos como desarrolladores. Te contaré mi rutina, las herramientas concretas que uso (mi "stack" de productividad) y cómo las uno para mantenerme centrado, reducir el estrés y asegurar que tanto mi trabajo como mis proyectos personales avanzan de forma constante.

¿Por Qué una Revisión Semanal es CRUCIAL para un Desarrollador?

Antes de entrar en el "cómo", déjame convencerte del "por qué". Puede parecer una tarea más en una agenda ya llena, pero para mí, la revisión semanal es la inversión que hace que el resto de la semana vaya mejor. Estos son los beneficios principales que noto:

Ganar Perspectiva: Es mi momento para salir del código, de la tarea inmediata, del bug urgente. Me permite levantar la cabeza y ver el "cuadro completo": todos mis proyectos (trabajo, personales, de aprendizaje), mis responsabilidades y mis objetivos a medio plazo. Paso del modo "apagar fuegos" al modo "arquitecto".
Controlar el Flujo: Los desarrolladores somos como imanes para la información: emails, avisos de Slack/Teams, menciones en GitHub/GitLab, tickets en Jira/Azure DevOps, ideas para refactorizar, enlaces interesantes, notas rápidas... La revisión semanal es mi forma de "vaciar" todas esas bandejas de entrada mentales y digitales, asegurando que no se nos escape nada importante entre tanto lío.
Enfocarse en lo Importante: Es fácil que lo urgente se coma todo el tiempo. Reuniones, interrupciones, bugs críticos... pueden ocupar todo nuestro día. La revisión me ayuda a encontrar y proteger tiempo y energía para las tareas que de verdad marcan la diferencia: bloques de desarrollo concentrado (deep work), aprendizaje, planificación de un proyecto, etc.
Reducir Estrés y Ansiedad: Esa sensación molesta de "seguro que me estoy olvidando de algo" desaparece (o casi). Saber que he repasado todo, que todo está apuntado y que tengo un plan (flexible, eso sí) para la semana siguiente, me da una tranquilidad que no tiene precio.
Adaptabilidad: El desarrollo de software es cambio constante. Prioridades que cambian, requisitos que evolucionan, problemas inesperados... La revisión semanal me da el momento para pensar en estos cambios, ajustar mis planes y reordenar mis tareas con cabeza, en lugar de ir dando bandazos.

Mi Rutina: Preparando el Terreno para la Claridad

Ser constante es fundamental. Para que la revisión funcione, tiene que ser un hábito sagrado. Así es como lo hago yo:

El Momento Sagrado: Mi momento es el viernes por la tarde, normalmente al finalizar el día de trabajo. ¿Por qué? Me permite cerrar la semana con la mente clara, sabiendo lo que he hecho y lo que viene. Empiezo el fin de semana desconectado de verdad y el lunes sé por dónde empezar. Probé el domingo por la noche, pero me daba estrés pre-lunes; el viernes me va mejor para "cerrar la persiana".
El Entorno: Intento concentrarme al máximo. Eso significa:
- Notificaciones de Slack, email y móvil apagadas.
- A veces, cascos con música tranquila (¡sin letra!).
- Un buen café o té para el ritual.
Duración Estimada: Normalmente me lleva entre 30 y 60 minutos. Al principio igual tardas más, pero le pillas el truco. Si una semana voy a tope, igual se alarga un poco, pero intento no saltármela nunca, aunque sea una versión rápida.
Herramientas a Mano: Antes de empezar, me aseguro de tener todo preparado:
- El ordenador con acceso a mis herramientas.
- Mi libreta física por si apunté algo ahí.
- Mi app de tareas abierta.
- Mi calendario a la vista.

El Proceso Paso a Paso de Mi Revisión Semanal

Vale, vamos al lío. Mi proceso sigue las ideas de GTD, pero a mi manera como desarrollador. Recuerda: el objetivo es tener la mente despejada y confiar en tu sistema.

(Recordatorio GTD: Recopilar -> Procesar -> Organizar -> Revisar -> Hacer) La Revisión Semanal se centra sobre todo en Recopilar lo pendiente, Procesar lo nuevo, Organizar y Revisar todo el sistema.

1. Recopilar y Vaciar TODO:

El primer paso es sacar todo de la cabeza y de todas las "bandejas de entrada". Reviso:

Físicas: Papeles sueltos, notas en mi libreta.
Digitales:
- Email (Personal y Trabajo): Dejar la bandeja de entrada a cero.
- Notas Rápidas (Ej: Apple Notes, Google Keep, un notes.txt): Cualquier cosa apuntada rápido.
- Carpeta de Descargas: ¿Hay algo ahí que guardar o borrar?
- Mensajes Directos (Slack/Teams): ¿Alguna petición o info pendiente?
- Mi App de Tareas Principal (Ej: Notion, Todoist...): La bandeja de entrada donde apunto cosas durante la semana.
Mental: ¿Qué me preocupa? ¿Qué ideas tengo? ¿Qué tengo que recordar? ¡Todo fuera y apuntado en la bandeja de entrada digital!

2. Procesar lo Recopilado:

Ahora, miro cada cosa que he recopilado, una por una, con la lógica GTD:

¿Hay que hacer algo?
- No: Archivar como referencia (luego vemos dónde) o borrar si no sirve.
- Sí:
  - ¿Se hace en menos de 2 minutos? ¡Hazlo ya! (Responder un email corto, crear una tarea fácil).
  - ¿No es para mí? Pásalo a quien toque (y si quieres, apúntalo en tu lista "A la Espera").
  - ¿Es para un día/hora concretos? Al Calendario (reuniones, citas, recordatorios de entregas).
  - ¿Es parte de algo más grande o necesita varios pasos? Define la "Próxima Acción": el siguiente paso concreto y real que hay que dar. Añádela a tu lista de "Próximas Acciones". Si es de un proyecto, ponle una etiqueta o vincúlala a él.
  - ¿Es algo que quiero hacer, pero no ahora? A la lista "Algún día/Quizás".

3. Revisar y Poner al Día el Sistema:

Esta es la parte clave de mantenimiento. Reviso mis listas y mi calendario:

Calendario Pasado: Miro rápido la semana que acaba. ¿Qué reuniones tuve? ¿Qué tareas hice? ¿Quedó algo pendiente para reprogramar o seguir? A veces esto me recuerda cosas que olvidé apuntar.
Calendario Futuro: Miro la semana que viene (o las dos siguientes). ¿Qué citas, eventos o entregas importantes tengo? ¿Necesito preparar algo? ¿Reservar tiempo para alguna tarea gorda?
Lista de "Próximas Acciones": Reviso CADA acción de mi lista.
- ¿Sigue teniendo sentido? (Igual algo ha cambiado).
- ¿Es de verdad la siguiente cosa física y concreta que hay que hacer? (Ej: "Buscar info sobre librería X" es mejor que "Hacer login").
- ¿Está claro lo que hay que hacer? ¿Necesito más info?
- Opcional: Reviso por contextos si los uso (@ordenador, @oficina, @casa, @llamadas, @email, @dev). Ayuda a ver qué puedo hacer según dónde esté o qué tenga a mano.
Lista de "Proyectos": Reviso CADA proyecto activo (trabajo y personal). Un "proyecto" en GTD es cualquier cosa que necesite más de una acción (Ej: "Lanzar v2.1", "Aprender Go", "Preparar charla", "Planificar vacaciones"). Para cada proyecto, me aseguro de que:
- El estado es correcto (Activo, Pausado, Terminado).
- Tiene al menos una "Próxima Acción" definida en mi lista. ¡Esto es CLAVE para que los proyectos no se queden parados!
Lista "A la Espera": Reviso las cosas que he pasado a otros o que estoy esperando que me lleguen (Ej: "Esperando respuesta de Menganito al PR", "Esperando que aprueben presupuesto para licencia"). ¿Tengo que preguntar qué pasa? ¿Ha llegado ya y puedo tacharlo?
Checklists (si uso): Reviso checklists para tareas repetitivas (Ej: "Pasos para publicar post", "Checklist antes de desplegar", "Backup semanal"). ¿He hecho los pasos de esta semana?

4. Mirar Hacia Adelante y Ser Creativo:

Cuando el sistema está limpio y al día, dedico unos minutos a pensar más en grande:

Lista "Algún día/Quizás": Le echo un ojo rápido. ¿Hay alguna idea o proyecto aparcado que me apetezca empezar ahora? ¿Algo que ya no me interesa y puedo borrar?
Brainstorming Libre: Esto es opcional, pero útil. A veces dejo la mente volar: ¿Cómo podría mejorar esto? ¿Qué side-project nuevo me molaría? ¿Qué tecnología quiero mirar? Apunto cualquier idea interesante (quizás en un sitio específico de mi app de notas o tareas).
Definir Objetivos/Tareas Clave para la Semana Entrante: Viendo los proyectos y el calendario, elijo 2-3 prioridades o tareas importantes en las que quiero centrarme la semana que viene. No es un plan cerrado, es una intención.

Mis Herramientas Clave en Acción Durante la Revisión

Puedes usar GTD con cualquier herramienta, pero tener las adecuadas y saber usarlas ayuda mucho. Este es mi equipo actual:

Mi Gestor de Tareas Principal (Todoist)
- Uso en la Revisión: Todoist es mi centro de mando para las tareas. Su simplicidad y potencia con filtros y etiquetas son clave. En la revisión:
  - Vacío el Inbox procesando cada tarea como expliqué antes.
  - Uso Filtros personalizados para revisar las Próximas Acciones por contexto (@work, @personal, @dev, @email, etc.) o según prioridades y fechas. Un filtro típico podría ser (hoy | próximos 7 días | sin fecha) & !@espera.
  - Reviso la lista de Proyectos, asegurándome de que cada uno tiene al menos una próxima acción definida y está activo o archivado según corresponda. A veces uso secciones dentro de los proyectos para organizarlos mejor.
  - Reviso mi filtro o etiqueta de @espera para las tareas delegadas o pendientes de otros.
  - Reviso mi proyecto o etiqueta Algún día/Quizás.
- Estructura: Organizo todo con Proyectos (para los resultados grandes) y Etiquetas (para los contextos: @work, @personal, @email, @llamada, @dev, @espera, @someday...). Asigno Fechas de Vencimiento solo cuando son límites reales, no para todo.
Mi Calendario (Notion Calendar)
- Uso en la Revisión: Lo uso para lo que tiene fecha y hora: reuniones, citas, eventos. Y muy importante: en la revisión, reservo tiempo para tareas gordas de la semana siguiente. Por ejemplo, bloqueo 2 horas el martes por la mañana para "Deep Work: Refactorizar Módulo X" o 1 hora el jueves para "Estudiar API Y". Esto protege mi tiempo de concentración. Reviso la semana pasada y las dos siguientes al "Revisar Calendario".
Mi Sistema de Notas/Referencia (Notion)
- Uso en la Revisión: Aquí guardo el material de apoyo: notas de reuniones, trozos de código, resúmenes, ideas, checklists... En la revisión, si necesito consultar algo para una tarea o proyecto, abro Notion. Los enlaces entre notas son geniales para conectar ideas. También tengo una nota "Ideas Semanales" donde apunto lo que sale en el paso 4.
(Opcional) Integración con Herramientas de Desarrollo:
- ¿Issues de GitHub/GitLab, Tareas de Jira/Azure DevOps? Hay varias formas de manejar esto. Puedes revisar estas herramientas por separado durante tu revisión semanal, o puedes crear tareas en tu sistema principal (Notion, Todoist, etc.) que enlacen a los issues o tickets importantes que requieran una acción concreta por tu parte (más allá de "mirar el ticket"). Elige el método que mejor te funcione para no duplicar trabajo pero tampoco perder de vista tus tareas de desarrollo.

Consejos Específicos para la Rutina GTD de un Desarrollador

El GTD vale para todo, pero como desarrolladores, tenemos nuestras cosas:

Bugs e Incidencias: ¿Cómo encajan? Depende. Un bug crítico puede ser una "próxima acción" inmediata ("Investigar error 500 ya"). Uno menos urgente, una tarea dentro de su proyecto ("Corregir bug #456"). Si arreglarlo lleva varios pasos, ¡es un mini-proyecto! La clave es apuntarlo y decidir qué hacer al procesar.
Aprendizaje Continuo: ¡Vital! Trátalo como un proyecto más. Ten un proyecto "Aprender" o específicos ("Aprender GraphQL", "Dominar Docker"). Asegúrate de que siempre tengan una "próxima acción" ("Ver vídeo curso X", "Hacer tutorial Y", "Leer capítulo 3"). En la revisión, mira si le dedicas tiempo y resérvalo en el calendario si hace falta.
Cambiar de Contexto (Context Switching): Separar curro y proyectos personales es difícil. Usar contextos (@work, @personal) ayuda. En la revisión, puedes mirar primero lo del trabajo y luego lo personal. Ser consciente de los límites y proteger tiempo para cada cosa es clave. La revisión te ayuda a ver si un área se está comiendo el tiempo de la otra.
Proyectos Largos/Complejos: La revisión semanal es tu mejor amiga aquí. Al revisar cada proyecto cada semana y asegurarte de que siempre tiene una "próxima acción", evitas que se paren o te agobien. Aunque solo des un pequeño paso cada semana, el proyecto sigue vivo. Dividir el proyecto en fases más pequeñas también ayuda.

Conclusión (Cierre y Llamada a la Acción)

Hacer una revisión semanal GTD ha sido una de las mejores cosas que he hecho para mi organización como desarrollador. Me ha devuelto la sensación de control en medio del caos típico de nuestro trabajo, me ha aclarado las prioridades y ha bajado mucho mi nivel de estrés. Ya no siento que se me escapan las cosas.

Quiero que te quedes con esto: la revisión semanal no es un trámite más, es la inversión que hace que todo lo demás funcione mejor durante la semana. Es como el mantenimiento de tu sistema personal de productividad.

Por supuesto, este es mi sistema. Lo más importante es que pruebes, adaptes y encuentres lo que te funciona a ti. Prueba herramientas, cambia el momento de tu revisión, ajusta los pasos. ¡No hay una única forma correcta! Lo que importa es ser constante y seguir las ideas principales.

3 herramientas que me están ayudando a ser más productivo como desarrollador

Thu, 17 Apr 2025 00:00:00 GMT

Estos meses estoy a tope desarrollando un SaaS de gestión para hostelería y como siempre, trasteando con ideas y mejoras para mi web personal. Para no volverme loco entre contextos, clientes y código, me apoyo en algunas herramientas que me están haciendo la vida más fácil.

No son las únicas que uso, pero sí las que más están marcando la diferencia en mi flujo de trabajo actual.

🧱 1. Next.js – Productividad desde el minuto uno

Next.js se ha convertido en mi framework principal para casi todo lo que implica desarrollo fullstack. Lo uso para casi cualquier proyecto y la verdad es que me permite montar webs robustas sin perder tiempo en configuración.

Entre las rutas con app router, el sistema de APIs integrado, y la posibilidad de hacer SSR o ISR según lo que necesites tengo todo lo que necesito. Me da estructura sin limitarme.

Si quieres profundizar en por qué elijo Next.js (y cuándo prefiero Astro), puedes leer mi comparativa aquí.

Y lo mejor: puedo centrarme en el producto, no en reinventar la rueda cada vez.

🗃️ 2. Supabase – Backend sin fricciones

La segunda pata de mi stack ahora mismo es Supabase. Es la base de datos, el sistema de autenticación y la API REST de mi proyecto, todo en uno. Y además, sin necesidad de montar nada por mi cuenta, ni gestionar servidores.

Lo que más valoro es poder hacer pruebas rápidas, tener una base de datos PostgreSQL real detrás y una interfaz web decente para gestionarlo todo. Para proyectos que necesitan escalar más adelante, pero empezar ya, es ideal.

🤖 3. Cursor – Un IDE con IA que de verdad ayuda

He probado muchos editores y asistentes de IA, pero Cursor es el que más me ha convencido. Está basado en VS Code, pero mejor integrado con IA para cosas muy concretas del día a día: modificar un archivo según un prompt, generar código a partir del contexto del proyecto, revisar carpetas enteras…

Es como tener un becario superdotado que realmente entiende lo que estás haciendo, y no solo te sugiere código al azar. Incluso puedo seleccionar una función y decirle "hazlo más limpio" o "añade tests" y me saca algo útil el 90% de las veces.

Está claro que no funciona por si solo, y a veces se lía, tienes que darle pistas, pero la productividad que añade es enorme.

💬 En resumen

Lo que me importa no es tener un stack enorme, sino uno que me quite trabajo de encima. Estas tres herramientas —Next.js, Supabase y Cursor— me están ayudando justo con eso: construir más rápido, con menos fricción y sin perder calidad.

Introducción a Cloudflare Workers

Wed, 15 May 2024 14:12:53 GMT

¿Qué son los Cloudflare Workers?

Cloudflare Workers es una plataforma de computación serverless que permite a los desarrolladores ejecutar código JavaScript en los servidores de Cloudflare distribuidos globalmente. Esto significa que puedes ejecutar tu lógica de aplicación más cerca de tus usuarios finales, reduciendo significativamente la latencia y mejorando el rendimiento general de tu sitio web o aplicación.

¿Cómo Funcionan los Cloudflare Workers?

Los Cloudflare Workers se basan en el estándar de la WebAssembly (WASM), lo que les permite ejecutar código con gran eficiencia y seguridad. Aquí tienes un desglose de cómo funcionan:

Distribución Global: Cloudflare tiene una red global con más de 200 centros de datos. Cuando despliegas un Worker, tu código se replica en todos estos centros de datos. Este mismo principio es el que aprovecha Cloudflare Pages para servir sitios estáticos rápidamente.
Ejecución en el Borde: En lugar de enviar todas las solicitudes a un servidor central, los Workers procesan las solicitudes en el servidor más cercano al usuario, mejorando la velocidad de respuesta.
Escalabilidad Automática: Los Workers escalan automáticamente para manejar cualquier cantidad de tráfico sin necesidad de que te preocupes por la infraestructura.

Beneficios de Usar Cloudflare Workers

Rendimiento Mejorado: Al ejecutar código en el borde, los tiempos de respuesta se reducen drásticamente.
Seguridad: Los Workers permiten implementar lógica de seguridad como controles de acceso y validación de datos directamente en el borde.
Escalabilidad y Flexibilidad: Cloudflare se encarga de la escalabilidad, permitiéndote concentrarte en el desarrollo de tu aplicación.
Coste Reducido: Al ser una solución serverless, solo pagas por las invocaciones de tu código, eliminando los costos asociados con servidores siempre activos.

Casos de Uso Comunes

Redirección de Tráfico: Redirige a los usuarios a diferentes versiones de tu sitio web según su ubicación geográfica.
Optimización de Imágenes: Procesa y optimiza imágenes en el borde para mejorar los tiempos de carga.
Autenticación y Autorización: Implementa mecanismos de autenticación y autorización directamente en el borde para mejorar la seguridad.

Primeros Pasos con Cloudflare Workers

A continuación, los pasos que tienes que dar para empezar con Cloudflare Workers directamente desde el panel de Cloudflare:

Registro y Configuración: Regístrate en Cloudflare (si es que no lo has hecho ya...) y añade tu dominio. En el panel de control, navega hasta la sección de Workers.
Crear un Worker: Haz clic en "Crear un Worker". Cloudflare te proporcionará una interfaz para escribir y probar tu código.
Escribir Código: Utiliza JavaScript para escribir tu lógica. Por ejemplo, un Worker sencillo para responder con un mensaje "Hello World" se vería así:

addEventListener('fetch', (event) => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  return new Response('Hello World', {
    headers: { 'content-type': 'text/plain' }
  })
}

Desplegar: Una vez que estés satisfecho con tu código, puedes desplegar el Worker y comenzará a ejecutarse en la red global de Cloudflare.

Usando Wrangler para crear y desplegar workers

Paso 1: Instalación de Wrangler

Primero, necesitas instalar Wrangler. Asegúrate de tener Node.js y npm instalados en tu sistema. Luego, ejecuta el siguiente comando en tu terminal para instalar Wrangler globalmente:

npm install -g @cloudflare/wrangler

Paso 2: Configuración de Wrangler

Una vez instalado, debes configurar Wrangler con tus credenciales de Cloudflare. Ejecuta el siguiente comando para iniciar sesión:

wrangler login

Esto abrirá una ventana del navegador donde podrás iniciar sesión en tu cuenta de Cloudflare y autorizar a Wrangler.

Paso 3: Crear un Proyecto de Worker

Con Wrangler configurado, puedes crear un nuevo proyecto de Worker. Usa el siguiente comando para generar un proyecto básico:

wrangler generate my-first-worker

Este comando creará un directorio llamado my-first-worker con una plantilla básica de Worker.

Paso 4: Modificar el Código del Worker

Navega al directorio del proyecto recién creado y abre el archivo index.js en tu editor de texto favorito. Aquí es donde puedes escribir la lógica de tu Worker. Por ejemplo, para responder con un mensaje "Hello World" podemos usar el mismo código del principio del artículo.

Paso 5: Prueba Local

Wrangler permite probar tu Worker localmente antes de desplegarlo. Usa el siguiente comando para iniciar el entorno de desarrollo local:

Esto iniciará un servidor local y te proporcionará una URL donde puedes probar tu Worker en tu navegador.

Paso 6: Desplegar el Worker

Una vez que estés satisfecho con tu Worker, puedes desplegarlo a la red global de Cloudflare. Ejecuta el siguiente comando para desplegar tu Worker:

wrangler publish

Wrangler subirá tu código a Cloudflare y lo desplegará en todos sus centros de datos. Recibirás una URL donde tu Worker estará disponible.

Paso 7: Configuración Adicional

Puedes configurar más aspectos de tu Worker, como el nombre, el dominio y las variables de entorno, editando el archivo wrangler.toml generado en tu proyecto. Este archivo permite personalizar la configuración y el comportamiento de tu Worker.

Moviendo mis side projects a Cloudflare

Mon, 13 May 2024 09:24:48 GMT

Desde hace tiempo vengo usando Vercel para el despliegue de mis proyectos frontend (sigo usándolo) pero últimamente estoy migrando algunos de los proyectos en los que estoy trabajando al entorno Cloudflare, usando tanto Cloudflare Pages como Cloudflare Workers (sobre los que puedes leer una introducción aquí) y estoy muy contento.

En este artículo, exploraremos las ventajas de Cloudflare Pages respecto a Vercel.

Mayor rendimiento y velocidad

Una de las principales ventajas de Cloudflare Pages es su red de distribución de contenido (CDN) global. Al aprovechar esta red, nuestros proyectos se beneficiarán de una mayor velocidad de carga y rendimiento, ya que los archivos se servirán desde el servidor más cercano al usuario.

Escalabilidad y disponibilidad

Cloudflare Pages ofrece una infraestructura escalable y altamente disponible. Esto significa que nuestros proyectos podrán manejar un mayor volumen de tráfico sin comprometer la estabilidad o la experiencia del usuario. Además, Cloudflare cuenta con una arquitectura distribuida que garantiza la disponibilidad de nuestros proyectos en caso de fallos en un servidor o región específica.

Además de la escalabilidad y disponibilidad, Cloudflare Pages también ofrece otras características que pueden mejorar aún más nuestros proyectos. Por ejemplo, podemos aprovechar la capacidad de caché de Cloudflare para almacenar en caché el contenido estático de nuestros sitios web, lo que reduce la carga en nuestros servidores y mejora la velocidad de carga para los usuarios.

Cloudflare Pages también nos permite personalizar la configuración de DNS para nuestros proyectos, lo que nos brinda un mayor control sobre la gestión de los nombres de dominio y la resolución de DNS. Esto puede ser especialmente útil si necesitamos configurar redirecciones, subdominios o registros DNS específicos.

Integración con otros servicios de Cloudflare

Otra ventaja de migrar a Cloudflare Pages es la integración con otros servicios de Cloudflare. Podremos aprovechar características como la protección contra ataques DDoS, el firewall de aplicaciones web (WAF) y la optimización de imágenes, entre otros. Esto nos permitirá mejorar la seguridad y el rendimiento de nuestros proyectos sin tener que implementar soluciones adicionales.

Costes reducidos

Cloudflare Pages ofrece un plan gratuito generoso que incluye un alto límite de ancho de banda y almacenamiento. Esto puede resultar en costos reducidos en comparación con Vercel u otras plataformas de alojamiento. Además, Cloudflare ofrece planes de precios flexibles que se adaptan a las necesidades de nuestros proyectos a medida que crecen.

Desventajas

Obviamente, no todo puede ser perfecto, sobre todo si trabajamos con NextJS, Vercel ofrece mucho mejor soporte para este Framework (lo han desarrollado ellos...) por lo que algunas de las ventajas y novedades que ofrecen no estarán disponibles cuando despliegas un proyecto con Cloudflare Pages, pero para la mayoría de proyectos es una solución más que interesante.

🚀 ¿Migrando un Next.js a Cloudflare? La parte que más fricción me dio al mover proyectos fue la configuración inicial: @opennextjs/cloudflare, autenticación, base de datos y CI/CD. He empaquetado todo eso en el Next.js + Cloudflare Pages Starter Kit — Better Auth, Drizzle + Supabase, GitHub Actions y deploy automático. De cero a desplegado en ~30 minutos.

Objetivos personales y profesionales para 2023

Sat, 17 Dec 2022 09:30:42 GMT

Una de las cosas que empecé a hacer desde que uso GTD como mi sistema de gestión de tareas es establecer objetivos, para tener una visión de alto nivel de lo que quiero hacer en mi vida y en mi carrera profesional. Mi flujo semanal GTD me ayuda a revisar y mantener estos objetivos.

Objetivos cumplidos 2021-2022

La última vez que me planteé objetivos tecnológicos fue en 2021, en este artículo, de los cuales cumplí dos (React y Tailwind), uno lo cumplí a medias (en lugar de aprender frontity acabé montando un proyecto que atacaba a un WordPress directamente usando GraphQL desde NextJS, porque me daba más flexibilidad para trabajar a mi gusto) y finalmente no dediqué nada de tiempo a aprender InertiaJS.

Otro de los objetivos tecnológicos que me propuse fue rehacer mi web y mi blog, además de lanzar un proyecto personal basado en alguno de mis hobbies (Torneos Poker España).

También me propuse empezar a hacer más ejercicio, desde marzo de 2020 (a saber qué pasó en esa época…) dejé de hacer deporte de forma continua, hasta esa fecha jugaba semanalmente mi partido de fútbol sala, algún partido de tenis o pádel, iba andando al trabajo a diario… Desde entonces, no volví a jugar mi partido semanal, dejé de ir andando a la oficina (me mudé) y empecé a teletrabajar.

Desde septiembre de este año estoy haciendo ejercicio (Crossfit), andando una media de 30 minutos diarios y comiendo algo más sano. Con esto he conseguido, además de bajar unos kilos de peso, sentirme mejor física y mentalmente.

Objetivos profesionales

Para este año que empieza en breve tengo dos objetivos principales a nivel profesional:

Aprender a desarrollar aplicaciones con Ionic + Capacitor.
Aprender Jest y mejorar en TDD

Respecto al primero de ellos, ya he hecho alguna aplicación con Ionic, pero hasta ahora me he quedado en un nivel muy básico y quiero mejorar el proceso.

Objetivos personales

A nivel personal, tengo tres frentes a cubrir:

Mejorar mi estado físico.
Leer más
Compartir más contenido online (este blog, un podcast…)

Para conseguir el primero de los objetivos seguiré entrenando mínimo 3 días semanales y seguiré cuidando mi dieta. La lectura es un punto débil que tengo desde hace mucho tiempo, no soy muy buen lector, suelo abandonar los libros a mitad y no terminan de engancharme.

Este artículo intenta hacer posible que cumpla el tercero de ellos, compartir más contenido, ya sea en este blog o incluso volver a hacer algo relacionado con el podcasting (desde que dejamos de publicar el podcast Necesito un Arma tengo bastantes ganas de volver a las andadas)

Gestionar tu vida con Notion y la metodología GTD

Wed, 14 Dec 2022 09:29:53 GMT

Desde que tengo uso de razón me he considerado una persona más o menos organizada, que suele acordarse de las reuniones y fechas importantes, que puede llevar a cabo proyectos de medio y largo plazo sin muchos problemas y que puede gestionarse medio bien. Pero no siempre todo sale tan fácil como nos gustaría, no siempre cumplimos los plazos y no siempre tenemos todo bajo control.

En los últimos 15 años, tanto trabajando por cuenta ajena, como en Sozpic como CEO y CTO, tuve la necesidad de organizar (no siempre lo hice bien, por supuesto…)

Hubo un punto de inflexión durante los meses de marzo y abril de 2020, cuando acabamos todos encerrados en casa. Creo que no fui solo yo, que hubo más gente afectada por esto, pero me vi en la necesidad de poner orden en la forma de gestionar todo en la empresa y por extensión en mi vida.

Un sistema

Entonces entendí que lo más importante para poder organizarse bien es tener un buen sistema, un sistema robusto, que se adapte bien a ti y que pueda albergar todas tus necesidades de gestión y organización. Ahí descubrí el sistema GTD (Getting Things Done) de David Allen.

El sistema GTD tiene como objetivo liberar tu mente de tareas recurrentes que se pasean en bucle hasta que las haces, para eso se basa en 5 principios:

Recopilar: Todo lo que te pase por la cabeza en algún momento lo lanzas al sistema
Procesar: Decides qué es lo que has ido recopilado (una tarea, un proyecto, una llamada, un recordatorio…)
Organizar: Pones cada cosa en su sitio (le pones fecha si es necesario, añades información relevante, lo contextualizas, lo añades a un proyecto existente…)
Revisar: Repasas cada cierto tiempo que todo esté en orden, haces ajustes necesarios en el sistema.
Hacer: Te pones a trabajar, con todo bien organizado y cada cosa en su sitio.

Y define el proceso que debes seguir para que todo este engranaje funcione bien:

Vale, ahora tengo que poner todo esto en algún sitio

David Allen cuando explica la metodología insiste en que no depende de ninguna herramienta, es decir, podría hacerse con papel y bolígrafo. Pero estamos en el siglo XXI y ya nadie usa papel y bolígrafo…

La primera herramienta que usé para llevar todo mi sistema GTD fue Todoist, me permitía organizar bien todo el sistema mediante proyectos, etiquetas, tareas, subtareas… pero siempre he echado en falta una parte importante de documentación y recursos relativos a los proyectos y tareas de GTD, que siempre tenía que irme a otra herramienta distinta a Todoist (Google Drive, iCloud, etc…)

Notion

Notion como herramienta me permite, además de poder llevar al día mi sistema GTD (tareas, proyectos, contextos, revisiones, etc…) tener también ahí toda la documentación necesaria, archivos de referencia…

Si por ejemplo una tarea es escribir un artículo para el blog sobre GTD, que ese artículo pueda ser un documento dentro de Notion enlazado con la tarea y que queda archivado en el sistema para revisarlo en el futuro.

O por ejemplo, si una tarea consiste en preparar un documento de requisitos para un proyecto, este documento puede estar creado en Notion, enlazado con la tarea o con el proyecto, modificarlo cuando quiera, exportarlo para enviarlo por email, imprimirlo… y todo sin salir de la herramienta con la que gestiono el sistema.

Para implementar el sistema en Notion me he ayudado de una serie de vídeos de Rubén Loan (Serie de GTD y Notion) que me sirvieron para perder el miedo inicial a la herramienta (cómo empezar, cómo se crean secciones, bases de datos…)

En otro artículo (este se está alargando más de la cuenta) explicaré con más detalle todo ese proceso, por si a alguien más le puede servir. Puedes leer sobre mi flujo semanal GTD como desarrollador aquí.

Web development technologies I want to learn in 2021

Sun, 07 Mar 2021 09:31:15 GMT

Last years I've found myself reading about a lot of technologies and programming languages, understanding them, and knowing how to defend or write about them in technical proposals. But never digging into them and learning. It was ok for me with my long WordPress knowledge (more than 10 years working with WordPress, improving myself, and doing very interesting projects) and knowing Laravel at a medium level.

But I want to learn more than this, I detected that I was so far to understand new technologies, new ways of work in web development (mostly frontend) and this year is going to be the gamechanger for me.

Here is a list of web technologies and languages I want to learn (some of them I've started and built some side projects)

English

I know this is not a programming language or a technology, but it is the most important skill every developer needs to know and improve. I'm from Spain, so English is not my primary language, here in Spain is mandatory to study English in school until you go to the University, we are improving and learning more English than 20 years ago, but we still need to work on this.

I think I have a good level, I can read, I can write (I'm sure I have a lot of grammar fails) and I can maintain a conversation with different kind of English speakers around the world (last 10 years I've spoken with people from Italy, Canada, USA, Israel, Germany, UK...) but I feel that I need to learn more.

That's because I've started writing my blog in English, to force myself to write and improve my language skills.

Reactjs

That was my first choice to start learning a new programming language. I mostly know and understand VUE (not deep but can read code and do some little projects). A friend told me to help him with a project on Reactjs and that was the click I needed to start learning this.

If you know Javascript and understand some simple programming concepts is a good language to learn, easy to start working (just start with create-react-app and you have a simple project to start playing)

Tailwindcss

I was a big defensor of Bootstrap, and still think that was a gamechanger, but every article or video I watch about Tailwindcss convinces me to take a shot.

I think is the best way to work with HTML without thinking about CSS (at least at the beginning when you are doing some mockups) but every minute I work with this technology I understand that can be used to build a big project and can be improved to work in production.

Frontity

This is a React framework to work with WordPress, it allows you to use a WordPress instance to be your headless backend and build the frontend part using Reactjs. This is a very good way for me to start working with headless CMS (I'm very confident with WordPress and is a very good CMS to work with)

Inertiajs

I'm interested in this project because is a good way to improve the two basic parts of a common web project (frontend part on react or VUE, backend part on Laravel or Rails)

There are much more technologies and projects I want to dig into (Jamstack, Jest, ReactNative, StoryBook...) but I don't want to put myself in a rush or give me more pressure than I need.

If you want to see how my stack has evolved, check out my thoughts on choosing between Next.js (React-based) and Astro in 2025.

Moss.sh, your virtual sysadmin

Sat, 11 Jan 2020 09:30:13 GMT

Since I work as a web developer and deal with the Internet, I've always been fighting with several hosting providers, dedicated servers, VPS, update installation, package management, PHP versions, security patches... Then I discover Moss.sh, and all these headaches disappeared, now it's like another step in the process, but not a problem to me.

With Moss.sh, you only have to worry about two things, what is the server size you need to start and what is your stack or Framework (Laravel, WordPress, JS, HTML, PHP...), everything else is not your problem anymore.

Main characteristics:

Integration with DigitalOcean, Google Cloud, Amazon EC2 or Vultr
You can manage all the Workspaces you need (and invite other users to them) to organize your servers and sites.
Automatic deploys integrated with your favourite code management tool (Bitbucket, Github, GitLab…)
Automatic server security updates.
Easy management of Workers and Cronjobs for your servers and sites.

And everything through a very easy interface. This tool was created by a good friend Daniel Vigueras and his team.

Comenzando con los Custom Post Types en WordPress

Fri, 15 Feb 2019 09:29:33 GMT

Un aspecto importante en WordPress son los Custom Post Types , una característica que se incluyó a partir de la versión 3 de este CMS. Como la mayoría sabe, en WordPress hay varios tipos de posts nativos, los posts normales, como este artículo, una página estática, los archivos adjuntos (imágenes y demás) y las barras de navegación. Cada una de estas cosas tiene un tipo de post concreto en la tabla wp_posts.

Desde la versión 3 se pueden definir Custom posts propios, lo que quiere decir que tenemos un montón de posibilidades de crear casi cualquier cosa que se nos ocurra. Para crear este tipo de posts se hace uso de la función register_post_type, que paso a describir a continuación, creando un Custom Post Type llamado Trabajo:

    add_action('init', 'franmoreno_trabajos_register');

    function franmoreno_trabajos_register() {

        $labels = array(
            'name' => __( 'Trabajos' ),
            'singular_name' => __( 'Trabajo' ),
            'add_new' => __( 'Añadir Nuevo' ),
            'add_new_item' => __( 'Añadir nuevo Trabajo' ),
            'edit_item' => __( 'Editar Trabajo' ),
            'new_item' => __( 'Nuevo Trabajo'),
            'view_item' => __( 'Ver Trabajo'),
            'search_items' => __( 'Buscar Trabajo'),
            'not_found' =>  __('No se encontró nada'),
            'not_found_in_trash' => __('No se encontró nada en la papelera'),
            'parent_item_colon' => ''
        );

        $args = array(
            'labels' => $labels,
            'public' => true,
            'rewrite' => true,
            'capability_type' => 'post',
            'hierarchical' => false,
            'menu_position' => null,
            'supports' => array('title','thumbnail','editor')
          );

        register_post_type( 'trabajos' , $args );
    }

Esta función recibe primero el nombre del Custom Post, y segundo un array con los distintos argumentos para crearlo. Este array contiene los siguientes campos:

labels: Otro array con los distintos textos que se mostrarán en el panel de administración para gestionar nuestro Custom Post Type.
public: Define si este Custom Post es de acceso público o va a ser de uso interno.
rewrite: Define si se va a hacer uso de los rewrites para generar permalinks con este tipo de datos.
capability_type: Define la forma en la que se accederá a el internamente, en este caso, decimos que igual que un post.
hierarchical: Permitimos que se asocien unos a otros como padres e hijos, false es que no, comportándose como un post. Si decimos true, se comportarán como páginas, pudiendo asignarles un padre.
menu_position: Definimos la posición que tendrá este Custom Post en el menú de administración de WordPress.
supports: Un array con los distintos campos que queremos que este Custom Post tenga en el panel de creación y edición, en este caso decimos que queremos que tenga título, imagen predeterminada y el campo de edición del post.

Añadimos el código anterior a nuestro fichero functions.php y al guardar y refrescar tendremos disponible nuestro Custom Post. Recomiendo, que para no tener dependencia entre el Custom Post y el Theme, separemos ambas cosas, creándolo como un plugin, en este caso, podemos crear un fichero en el directorio plugins al que llamaremos como queramos y cuyo contenido será algo así:

    <?php

    /*
    Plugin Name: Custom Post Trabajos
    Description: Custom posts de trabajos.
    Version: ...
    Author: ...
    Author Uri: ...
    License: ...
    */

    /* Aquí añadimos el código anterior que define el custom post */

    ...