- El middleware de Next.js tiene una configuración de logging limitada, y el logging predeterminado solo se activa en el entorno de desarrollo, lo que dificulta rastrear problemas en producción
- En el middleware solo se pueden pasar headers, y no es posible encadenar múltiples middlewares, por lo que la implementación de logging compleja queda limitada
- El logging con AsyncLocalStorage muestra comportamientos inesperados en el runtime Edge, y el compartir contexto entre páginas y middleware no funciona correctamente
- Incluso usando un servidor personalizado, es difícil resolver los problemas de logging, y las restricciones de diseño de Next.js obligan a los desarrolladores a trabajar de cierta manera
- SvelteKit de Vercel ofrece un middleware flexible y mecanismos de paso de datos, mostrando un diseño más amigable para desarrolladores que Next.js
Trasfondo del problema de logging en Next.js
- Al operar un servicio con Next.js e intentar implementar logs de producción, se descubrió que la función de logs por defecto solo está activada en el entorno de desarrollo
- Ante la necesidad de implementar un sistema de logging adecuado para producción, se toparon con las limitaciones de Next.js
Limitaciones del middleware
- Según la documentación oficial, el middleware se ejecuta antes del enrutamiento y es adecuado para implementar funciones como autenticación, logging y redirecciones
- En la práctica, los parámetros que pueden pasarse al middleware están limitados a 4, y en realidad solo los headers pueden transmitirse de forma útil
- No se soporta una estructura para encadenar o combinar varios middlewares
- En Node.js existen prácticas de middleware ya consolidadas en Express y similares, pero en Next.js no se pueden aplicar correctamente
Intento de rodear el problema con AsyncLocalStorage
- Se intentó gestionar instancias de logging a nivel de middleware usando pino y AsyncLocalStorage
- Aunque en el middleware es posible guardar logs por solicitud con un contexto único, se observó que solo funciona correctamente en el entorno del navegador
- Esto se debe a que el middleware de Next.js usa por defecto el runtime Edge, y aun configurándolo como runtime nodejs, según el proyecto el comportamiento puede ser inestable
Fallas en los componentes de página
- Al llamar a la función de logging en páginas o componentes de layout reales, logger() devuelve null
- Existe un problema estructural por el cual el contexto de logger creado en el middleware no se transmite al contexto de renderizado asíncrono
- La única solución es pasar información de logging como requestId en los headers, lo que complica el código y también vuelve confusa la estructura de imports
- En los componentes de cliente también se requiere una separación estructural similar
Intento de introducir un servidor personalizado
- Siguiendo el ejemplo de servidor personalizado de la documentación oficial, se probó usar http.createServer y app.getRequestHandler de next.js
- En ese entorno se quiso volver a usar AsyncLocalStorage, pero se repitió el problema de no poder vincular el contexto entre middleware, página y servidor personalizado
- En el fondo, Next.js solo usa AsyncLocalStorage correctamente dentro de su propio interior, y no da a los desarrolladores el mismo nivel de acceso
- En la práctica, las únicas formas de pasar datos del middleware a la página son modificar headers de respuesta y mover rutas mediante redirect/rewrite
- Desde la perspectiva del usuario, es muy difícil extender esto con flexibilidad o pasar contextos personalizados
Comparación con SvelteKit
- SvelteKit de Vercel ofrece un sistema de middleware más flexible que Next.js
- Permite pasar datos de la solicitud libremente mediante el objeto event.locals
- Se pueden definir múltiples funciones handle y encadenarlas, facilitando la implementación de lógica compleja
- SvelteKit muestra un diseño amigable para desarrolladores, en contraste con las restricciones de Next.js
- Aunque SvelteKit también es un producto de Vercel y se considera un proyecto secundario frente a Next.js, ofrece una mejor experiencia
Crítica al issue tracker y a la cultura del ecosistema
- El issue tracker oficial de GitHub de Next.js casi no responde a los comentarios de los usuarios
- Incluso issues o bugs populares suelen quedar abandonados por mucho tiempo sin respuesta ni solución
- Aunque se prepare código mínimo reproducible y se reporte un issue, no suele haber una respuesta real ni seguimiento
Conclusión y reflexión
- Los bugs y límites estructurales que se encuentran en Next.js dañan repetidamente la productividad de los desarrolladores y muestran la necesidad de mejoras de fondo
- Al compararlo con otros frameworks como SvelteKit, Next.js queda por detrás en usabilidad pese a ser el producto principal
- Aunque no sea fácil reemplazar Next.js de inmediato, surge el deseo de considerar otras opciones en proyectos futuros
7 comentarios
Parece que todavía no se dieron cuenta de que React también perjudica la productividad.
Esta vez, solo por interés personal, probé hacer desarrollo web, un área totalmente distinta de la que originalmente desarrollaba. Hice un foro con next.js v15 app router, pero cada vez que veo textos así... siento que se me van las ganas de probar algo nuevo del lado web. ¿Por qué el ecosistema es tan inestable? ¿Y luego cuando salga otra cosa nueva todos van a correr en masa hacia allá, la van a usar un poco y después la van a criticar mientras buscan otra cosa? El desarrollo web sí que debe ser difícil.
La rapidez de los cambios en esta industria es tanto una ventaja como una desventaja jaja. Pero el problema del texto, en el fondo, se debe al caos que provoca Vercel. Si van a trabajar en frontend, conviene tenerle bastante cuidado a Vercel :(
Como empecé mi carrera en la web, quizá por eso lo veo así, pero la web (sobre todo el frontend) originalmente se desarrolla con ese saborcito (?) jaja
Con ese sabor de cambios rapidísimos...
El lado de JS se siente un poco así. Hay un montón de cosas que supuestamente son buenas, pero todas tienen algún problemita y van cambiando rapidísimo según la moda...
Aunque puede ser que lo sienta así porque antes trabajaba principalmente con Java, EJB y Struts.
Comentarios en Hacker News
Estoy 100% de acuerdo; me topé con los mismos problemas y no volveré a usar Next.js jamás, además voy a recomendarle a todos los equipos de la empresa que usen otras alternativas.
Next.js tiene una capa de abstracción enorme que no hace falta en el 99.9999% de los proyectos; y en los pocos casos donde sí hace falta algo así, me parece mejor construir una solución a medida con componentes de más bajo nivel.
De todas las tecnologías que he usado, Next.js fue por mucho la peor.
Qué alivio saber que no soy el único que piensa así.
Hice una app de producción monetizada de complejidad media con Next.js; al principio usé Vercel y Google Firebase, y después migré a self-hosting y reemplacé todo por Pocketbase.
Pocketbase fue la única experiencia aceptable; todo lo demás fue realmente terrible.
Complejidad infinita, cambios incompatibles constantes, documentación difícil de abordar: nada fue fácil.
Estoy seguro de que estaríamos mejor hoy si en los últimos 5 años hubiéramos frenado las tendencias de FE y nos hubiéramos enfocado en enseñar bien las tecnologías que ya existían en ese momento.
También he hecho frontends complejos con React; React tampoco me gusta mucho, pero Next.js fue todavía peor.
Incluso hice un CMS con Go y JS vainilla; tal vez el DX era un poco menor, pero al menos sentía que realmente sabía qué estaba pasando.
No entiendo por qué con React y Next.js, incluso después de 6 años, uno sigue adivinando qué va a pasar.
He ganado experiencia para desenredar el enredo del framework, pero en general todo se siente demasiado desordenado y mal diseñado.
Con Go, salvo los primeros 6 meses, casi nada me sorprendió, y las bases de código viejas siguen siendo sólidas.
Es una lástima que no podamos tener esa misma experiencia en frontend.
En mi experiencia, las asperezas de Next.js no son bugs, son features.
Todo se siente diseñado para hacer que el usuario se rinda y termine atado al hosting de Vercel.
Creo que la situación va a empeorar todavía más.
Hoy hasta cursos online como los de PluralSight están empujando únicamente Next.js en sus contenidos sobre React.
No sé cómo llegamos a esto, pero aquí estamos.
En mi caso, Sharepoint me dejó recuerdos todavía peores, así que Next.js sería el segundo peor.
Lo más frustrante de Next.js es que pretende darte todo como un framework full-stack tipo Rails, Wordpress o Meteor, pero en realidad solo tiene opiniones sobre las partes más aburridas y limitadas —middleware, redimensionado de imágenes, SSR, etc.— y deja en manos del usuario las decisiones que de verdad importan, como la base de datos, el ORM o el protocolo de comunicación.
En la práctica es bastante distinto de Rails/Wordpress/Meteor, y se supone que un framework debería definir la infraestructura, pero aquí terminó pasando lo contrario: la infraestructura controla al framework.
En mi dashboard, "Fluid Active CPU" e "ISR Writes" son de las categorías de uso más altas, y lo único que hago es pagar $20 y rezar para no pasarme del 100%.
Los nombres de las métricas parecen tecnopalabras de Star Trek, y ni ganas me dan de aprenderlas porque seguro cambian otra vez en la próxima versión mayor.
Bastantes conocidos que antes eran fanáticos de Zeit al final movieron sus proyectos y clientes a otra parte.
Si Vercel me preguntara qué debería cambiar en la próxima gran release, solo podría responder: "Todo lo que decidieron desde App Router en adelante estuvo mal".
No sé cómo podrían recuperarse de esto.
Creo que muchos de los problemas de Next.js vienen de no tener claro dónde se ejecuta realmente el código.
Se mezclan navegador, middleware, edge y node, SSR y demás, y eso crea una complejidad enorme.
Este tipo de casos tan delicados aplican cuando:
operas un servicio B2C global y quieres reducir la latencia con semánticas edge
estás dispuesto a pagar el hosting caro de Vercel
necesitas una arquitectura no demasiado compleja y sin trabajos en segundo plano
Fuera de eso, un SPA con react-vite o un SSR tradicional tipo Rails suele ser mucho más sensato.
Yo ni siquiera estoy de acuerdo con esas condiciones.
Incluso si Next.js encajara en el caso, la caída en productividad y mantenibilidad no me parece que valga para nada la pena.
Yo uso Lustre de Gleam y no pienso volver atrás.
También creo que la keynote del fundador de Elm muestra un caso completamente opuesto a Next.js.
https://www.youtube.com/watch?v=sl1UQXgtepE
Diría que Vercel es un cáncer para la web moderna.
Se ha infiltrado en todos los ecosistemas de frameworks y abusa de eso para vender planes pagos, mientras finge preocuparse por el open source, la competencia y el avance de la web.
Incluso en el primer caso, cuesta creer que usar Vercel y SSR vaya a resolver los cuellos de botella de rendimiento.
La mayoría de los problemas de rendimiento vienen de cosas básicas, como bundles demasiado grandes o demasiadas llamadas lentas a APIs.
Hacer profiling básico, optimizar y simplificar primero suele ser mucho más efectivo que complicar la arquitectura.
Me identifiqué con la parte de "no saber dónde corre el código".
Antes pensaba que la idea de JavaScript para todo era una ventaja, pero ahora siento que ese mismo es el problema.
En mi empresa usamos Inertia.js + Vue, y en general la configuración es mucho más simple: mantiene toda la potencia del renderizado en frontend, pero el routing se maneja 100% del lado del servidor y no hace falta una API aparte.
También puedes usar Inertia con React o Svelte.
Al principio usábamos Nuxt, pero era tan complejo como para tener que operar al mismo tiempo un servidor backend y otro frontend, y era difícil saber dónde corría cada cosa.
Ahora, gracias a que PHP es servidor y JS es navegador, no tenemos que pensar en eso en absoluto.
Para nosotros eso es una ventaja enorme.
Me parece que ese comentario resume bien el punto.
Vercel está buscando optimizar el rendimiento con React Server Components, Partial Pre-rendering, servidores edge, streaming y demás.
Todas esas decisiones raras de diseño o de API vienen de ahí.
En algunos casos eso puede ayudar, pero incluso usar SSR de forma adecuada en algunas edge functions ya puede mejorar bastante las cosas.
Gracias por dejar feedback.
Somos conscientes de los problemas de DX en Middleware, y en la versión 15.5 dimos un avance importante con el soporte para runtime de Node[1].
Si pudiera volver atrás, le habría puesto un nombre como Routing Middleware o Routing Handler, para dejar más claro que es un escape hatch avanzado en la etapa de routing que puede delegarse al CDN edge.
Si lo que necesitas son logs, puedes resolverlo con OpenTelemetry siguiendo la práctica de
instrumentation.ts[2].[1] https://nextjs.org/blog/next-15-5#nodejs-middleware-stable
[2] https://nextjs.org/docs/app/api-reference/file-conventions/instrumentation
Gracias por responder.
Pero cuando sacas el tema de instrumentation y observability, suena como si estuvieran resolviendo un problema simple de logs con otra capa más de complejidad.
No todas las apps necesitan OpenTelemetry.
No entiendo por qué no puede funcionar algo normal como
logger().info().Existe en otros lenguajes y frameworks; no entiendo por qué aquí tiene que ser tan difícil.
Como el ambiente acá es bastante negativo, quiero dejar esto claro primero: Next.js es un gran software para el propósito que realmente tiene.
Creo que hicieron bien un software que sostiene millones de sitios.
El problema viene por la falta de referencias detalladas y documentación profunda; la documentación te dice qué existe, pero no explica bien cómo usarlo de verdad, cuándo se ejecuta ni cuáles son las trampas comunes.
Es amable con principiantes, pero se queda corta al explicar contextos de runtime complejos o complejidad derivada.
Es una tendencia que veo en muchos proyectos hoy en día.
Es muy difícil equilibrar lo user friendly con las explicaciones detalladas.
Ojalá siga mejorando.
Repito mi punto en una sola frase.
El autor de ese post no supo reconocer la diferencia entre dominios y quiso invocar funciones igual en todos lados.
Los errores de Next.js vienen de intentar fusionar a la fuerza dominios que originalmente son distintos.
Si mezclas edge, SSR, Node y cliente de esta forma, lo único que haces es aumentar la complejidad.
La documentación no lo resuelve; de hecho, solo agrega más confusión.
Una vez me recomendaron en Reddit el enfoque de instrumentation.
Si más o menos por la misma época hubiera estado configurando opentelemetry en Next, aunque la documentación hubiera sido distinta, igual habría terminado escribiendo un post después de vivir algo así.
No es culpa de ustedes, pero casi todos los paquetes de opentelemetry aparecen marcados como experimentales, y eso no da mucha confianza para usarlos en producción.
Configurar instrumentation de pino también fue bastante difícil.
Tuve que agregar
pinoaserverExternalPackagespara que funcionara bien.La auto-instrumentación además era extremadamente sensible al orden de los imports, y solo se instrumentaba el default export de pino.
Las variables locales del módulo tampoco funcionaban como esperaba, así que terminé usando
globalThis.Y aun así terminé chocando con esto: https://github.com/vercel/next.js/issues/80445
Al final sí quedó funcionando, pero la configuración fue realmente incómoda.
Esa fue mi experiencia por usar router manual (= sin
vercel/otel).Si ya tomaron la decisión de soportar middleware del lado del servidor, no entiendo por qué todavía no permiten encadenar middleware (varias funciones conectadas) y solo soportan uno.
Es algo que prácticamente cualquier otro framework de servidor ofrece.
Me cuesta creer que de verdad no se pueda tener "una cadena de varios middleware".
https://nextjs.org/docs/messages/nested-middleware
Que te digan que si tienes varios debes fusionarlos en un solo archivo para ejecutarlos de ahí me parece increíble.
Si entendí bien, ¿Next.js básicamente dice que no estructures eso en varios archivos y mejor lo juntes todo en uno?
¿Es por temas de scoping que cuesta usar varios archivos? Como framework, es una exigencia absurdísima.
No puedo quitarme la sospecha de que muchas de estas decisiones absurdas no se tomaron porque beneficien al framework, sino porque favorecen más a Vercel.
La primera vez que vi Next.js pensé inmediatamente en Meteor.js.
Le invertí bastante tiempo para aprenderlo en proyectos personales, pero por su exceso de abstracción y rigidez era difícil pasar de un prototipo.
Estas soluciones de “incluye baterías” siguen apareciendo porque la configuración es cómoda.
Hace poco incluso en Hacker News, en una comparación entre Laravel y Symphony, salió el tema de que todo se rompe cuando la complejidad crece.
Si comparas este enfoque con el de armar piezas a medida como en el viejo NodeJS/React SPA, cada componente queda independiente con abstracciones de bajo nivel, así que hay más flexibilidad y también es más fácil reemplazar partes.
Tiene desventajas, claro, pero aun así suele ser más fluido que el overengineering, es decir, que la complejidad acumulada en capas.
Entiendo perfectamente por qué las soluciones con baterías incluidas son populares.
Combinar herramientas y librerías distintas y hacer que todo sea compatible es realmente tedioso.
Este enfoque más modular suele funcionar mejor cuando alguien con más experiencia se encarga de dejar bien montada la base.
Yo vengo de asp.net, que en las comunidades startup suele tener mala fama, pero en realidad es un framework extremadamente bien diseñado.
También viene con baterías incluidas, pero siempre pude escapar del framework y sobreescribir lo que necesitara, y nunca sentí que estuviera peleándome con él.
Tanto Blazor Server como Blazor Webasm te dejan hacer frontend en C#, y ambos sirven bien para paneles internos o apps SaaS.
Y sobre todo, con renderizado tradicional del lado del servidor también puedes resolver casi todo.
Si alguien está frustrado con los frameworks web, de verdad se lo recomendaría.
Ahora además tiene muy buen soporte multiplataforma, es rápido y es fácil de aprender.
Tiene curva de aprendizaje, pero una vez entiendes la estructura de módulos, puedes sobreescribir lo que quieras.
Muy rara vez me topé con límites duros comparado con otros frameworks.
Ese enfoque de usar piezas ensamblables como en NodeJS/React SPA me resulta ajeno en Angular.
Angular no es una librería sino un framework, así que la mayoría de lo que necesitas ya viene incluido.
(RxJS sí tiene cierta curva de aprendizaje, pero con dominar lo básico ya es suficientemente potente).
Normalmente no he tenido mucha experiencia de “pelearme con el framework” en una SPA.
La documentación y los tutoriales —incluyendo Tour of Heroes— son excelentes.
https://v17.angular.io/tutorial/tour-of-heroes
La documentación más reciente está en https://angular.dev/
Laravel es un caso exitoso de abstracción sobreingenierizada.
Gracias a Laravel nunca me he arrepentido en producción.
Un poco cambiando de tema, conectar constantemente herramientas y librerías pequeñas que no terminan de ser compatibles es literalmente todo mi trabajo.
Mi equipo es chico, así que gastamos muchísimo tiempo manteniendo todo al día y haciendo mantenimiento, y además los problemas con paquetes abandonados son frecuentes.
No es solo experiencia: el tiempo inicial de construcción del sistema y el costo de mantenimiento son muchísimo más grandes de lo que uno imagina.
Cuando lo haces tú mismo, sientes que Rails te da 10 veces más productividad que ir pegando librerías sueltas en Node.
Los problemas solo aparecen si no te gusta la base y la filosofía del framework (por ejemplo, si odias ActiveRecord).
Eso de que “cuando sube la complejidad todo se rompe” es simplemente falta de nivel técnico.
Yo soy de los que más defienden React, y también me gustó el cambio de class components a hooks.
Pero cada vez que uso Next.js siento que ya ni sé por dónde empezó a salir mal todo.
Me gustan muchos frameworks y hasta lenguajes raros, pero Next.js es el único caso donde ni siquiera entiendo la mitad de los mensajes de error.
En especial, he perdido una cantidad absurda de tiempo con problemas rarísimos de hydration.
Yo no uso React ni Next.js.
Personalmente prefiero HTML + CSS con un poco de JS vainilla.
Hasta me pasó que una landing page simple hecha con Next.js se rompía en Firefox.
Y peor todavía: la forma de fallar era mostrar solo una pantalla negra con letras blancas encima de todo el contenido diciendo "An application client side error has occurred".
Me sorprendió que una landing page tan simple ni siquiera pudiera renderizarse; cuando entendí que era por culpa de un framework frontend en JS, solo pensé: “sí, tiene sentido”.
Quizá a quienes intentan convencer a usuarios de esto les parezca aceptable, pero para alguien fuera de la industria puede ser desconcertante.
Creo que Next ya es un ejemplo de algo que se arruinó solo.
Todo lo que pasa por el ciclo del VC termina así.
Ya no lo puedo usar; Vite es la opción por defecto.
Siempre voy a preferir soluciones más ligeras.
El término “middleware” en Next.js se presta mucho a confusión.
En realidad es una edge function ligera que se ejecuta antes de que la solicitud llegue a la app (para revisar headers, routing, guards simples, etc.).
Corre en el runtime edge y es un entorno separado del servidor de la app.
Parece que el autor también está confundiendo el runtime edge con el runtime del servidor.
A mí al principio también me costó entender ese límite, y como todo gira alrededor de JavaScript, la separación se vuelve borrosa.
Creo que hace falta un modelo mental claro.
Culpar a la complejidad de Next.js se siente un poco como culpar a una caja de herramientas por traer más cosas aparte de un martillo.
El problema es que la complejidad de Next.js es autoinfligida.
El término middleware ya tiene un significado muy claro en casi todos los frameworks.
Normalmente, middleware es una cadena de funciones que se invocan antes de la solicitud dentro del runtime, y se da por hecho que corren en el mismo proceso.
Next.js, en cambio, manda eso al edge y además solo permite una.
En la mayoría de las apps ni siquiera hace falta funcionalidad edge; eso debería ser algo opt-in para cuando realmente se necesite.
Siguiendo tu analogía de la caja de herramientas, lo correcto sería agregar solo las herramientas que realmente necesitas.
Next.js no debería usar el término “middleware” en este contexto.
Eso no es solo un mal uso, es abuso del término.
Middleware tiene una definición establecida desde hace años en la industria de aplicaciones web, así que si querían significar algo totalmente distinto, no deberían haber usado esa palabra.
Yo uso el app router de Next.js y la verdad estoy satisfecho.
Next.js hace muy fácil moverse entre frontend y backend, y creo que eso hace que la gente piense que esa parte también está abstraída, cuando no es así.
En realidad es un sistema muy complejo, y tienes que hacerte cargo de esa complejidad tú mismo.
Que algo sea complejo no siempre significa que sea lento o improductivo.
Separar frontend y backend en dos sistemas distintos sí es más fácil de manejar, pero también es más tedioso.
Aunque conozcas React, aprender Next.js se siente como empezar de cero, y hay muchas cosas que solo entiendes después de sufrirlas en carne propia.
Aun así, cuando ya te acostumbras un poco, es un sistema muy conveniente para moverte fácilmente entre frontend y backend.
Veo que mucha gente le dio dislike a mi comentario, y me gustaría saber por qué.
Siempre estoy dispuesto a aprender.
En este tipo de discusiones me gustaría que no se quedaran solo en el rechazo automático y que realmente se debatiera bien.
Por fin veo una opinión sensata.
Por ejemplo, sería como confundir sin pensarlo el concepto de paquete/módulo de Python con el de módulo en Go, y luego quejarse de que Go es malo.
Siempre hace falta un entendimiento básico de la tecnología que estás usando.
Desde que Next.js cambió al app router, sentí como si hubieran puesto a graduados de bootcamp a “mejorar” la API de express.
La API de express, con todos sus defectos, al menos representa un enfoque maduro si consideras que todas las interfaces de servidor —servlets, rack, plug, etc.— fueron convergiendo durante años hacia diseños tipo muñeca rusa.
Además de la pésima API de middleware, también fue rarísima la decisión de eliminar parámetros de request y reemplazarlos por funciones globales como
cookies()yheaders().Supongo que hay restricciones de diseño fundamentales escondidas detrás de eso, pero desde afuera parece que tiraron a la basura todas las lecciones aprendidas y decidieron repetir los mismos errores.
Y encima se suma el soporte para runtimes edge de lowest common denominator, lo que hace todo todavía más limitado.
Yo siempre trato de usar distintos stacks en proyectos nuevos.
He usado express+react, angular, vue, next, nuxt, go, .net, node, php, etc., tanto en frontend como en backend.
En la mayoría de los frameworks encuentro ventajas y desventajas, y también disfruto aprender algo nuevo.
Next.js es la única excepción: al construir una app bastante grande, desde el principio hasta el final sentí que cada cosa era rara, lenta, incómoda o absurdamente mal diseñada.
Todavía me toca mantenerla, y es el único “algo” que realmente odio.
Dicen que el ecosistema está bien y que es popular, pero en mi experiencia real fue irreversiblemente negativo.
Es raro, pero es la realidad.
¿Alguien sabe la dirección postal de Vercel?
Este issue ya el próximo año va a tener edad para entrar a primaria, así que me gustaría mandarles una tarjetita que diga “¡que te vaya bien en la escuela!”.
https://github.com/vercel/next.js/issues/10084
Lo que dice la opinión de Hacker News en el comentario de abajo es exacto.
"Next.js tiene una capa de abstracción enorme e innecesaria para el 99.9999% de los proyectos; en los pocos casos en que realmente se necesita algo así, creo que sería mejor hacer una solución a medida con componentes de más bajo nivel"
APIs excesivamente complejas sin necesidad, la forma en que promocionan como production ready algo inestable e incompleto, y la enorme dependencia de Vercel hacen que, si no usas Vercel, sea difícil operarlo en serio.