Cómo usar una Boilerplate con alimentación de LLM para construir su propio nodo.js API

Durante mucho tiempo, una de las formas comunes de iniciar nuevos proyectos Node.js fue usar plantillas de Boilerplate. Estas plantillas ayudan a los desarrolladores a reutilizar estructuras de código familiares e implementar características estándar, como el acceso al almacenamiento de archivos en la nube. Con los últimos desarrollos en LLM, Project Boilerplates parecen ser más útiles que nunca.

Sobre la base de este progreso, he extendido mi nodo.js existente API Boilerplate con una nueva herramienta LLM Codegen. Esta característica independiente permite que la Boilerplate genere automáticamente el código del módulo para cualquier propósito basado en descripciones de texto. El módulo generado se completa con pruebas E2E, migraciones de bases de datos, datos de semillas y la lógica comercial necesaria.

Historia

Inicialmente creé un Repositorio de Github para una boorlerplate de API node.js para consolidar las mejores prácticas que he desarrollado a lo largo de los años. Gran parte de la implementación se basa en el código de una API de nodo.js real que se ejecuta en producción en AWS.

Me apasiona la arquitectura de corte vertical y los principios de código limpio para mantener la base de código mantenible y limpia. Con avances recientes en LLM, particularmente su soporte para grandes contextos y su capacidad para generar un código de alta calidad, decidí experimentar con la generación de un código mecanografiado limpio basado en mi calderera. Esta calderera sigue estructuras y patrones específicos que creo que son de alta calidad. La pregunta clave era si el código generado seguiría los mismos patrones y estructura. Basado en mis hallazgos, lo hace.

Para recapitular, aquí hay un punto culminante rápido de las características clave de la API de Node.js API:

• Arquitectura de corte vertical basada en DDD Y MVC principios
• Validación de entrada de servicios utilizando ZOD
• Desacoplar componentes de la aplicación con inyección de dependencia (InversifyJS)
• Integración y E2E Prueba con Supertest
• Configuración de múltiples servicios usando Dockercomponer

Durante el mes pasado, pasé mis fines de semana formalizando la solución e implementando la lógica de generación de código necesaria. A continuación, compartiré los detalles.

Descripción general de la implementación

Exploremos los detalles de la implementación. Todo Generación de código La lógica se organiza a nivel de raíz del proyecto, dentro del llm-codegen Carpeta, asegurando una navegación fácil. El código de Boilerplate node.js no tiene dependencia de llm-codegenpor lo que se puede usar como una plantilla regular sin modificación.

Cubre los siguientes casos de uso:

• Generación de código limpio y bien estructurado para un nuevo módulo basado en la descripción de la entrada. El módulo generado se convierte en parte de la aplicación Node.js REST API.
• Crear migraciones de bases de datos y extender scripts de semillas con datos básicos para el nuevo módulo.
• Generar y arreglar pruebas E2E para el nuevo código y garantizar que pasen todas las pruebas.

El código generado después de la primera etapa está limpio y se adhiere a los principios de arquitectura de corte vertical. Incluye solo la lógica comercial necesaria para las operaciones de Crud. En comparación con otros enfoques de generación de código, produce código limpio, mantenible y compilable con pruebas E2E válidas.

El segundo caso de uso implica generar la migración de DB con el esquema apropiado y actualizar el script de semillas con los datos necesarios. Esta tarea es particularmente adecuada para LLM, que la maneja excepcionalmente bien.

El caso de uso final es generar pruebas E2E, que ayudan a confirmar que el código generado funciona correctamente. Durante la ejecución de pruebas E2E, se utiliza una base de datos SQLITE3 para migraciones y semillas.

Principalmente los clientes LLM compatibles son OpenAi y Claude.

Cómo usarlo

Para comenzar, navegue a la carpeta raíz llm-codegen e instale todas las dependencias ejecutando:

NPM I

llm-codegen No se basa en Docker ni en cualquier otra dependencia de terceros pesados, lo que hace que la configuración y la ejecución sean fáciles y directas. Antes de ejecutar la herramienta, asegúrese de configurar al menos uno *_API_KEY Variable de entorno en el .env Archifique con la clave API apropiada para su proveedor LLM elegido. Todas las variables de entorno compatible se enumeran en el .env.sample archivo (OPENAI_API_KEY, CLAUDE_API_KEY etc.) puedes usar OpenAI, Anthropic Claudeo OpenRouter LLaMA. A mediados de diciembre, OpenRouter LLaMA es sorprendentemente gratis de usar. Es posible registrarse aquí y obtener un token para uso gratuito. Sin embargo, la calidad de salida de este modelo de llama gratuita podría mejorarse, ya que la mayor parte del código generado no pasa la etapa de compilación.

Para empezar llm-codegenejecute el siguiente comando:

NPM Run Start

A continuación, se le pedirá que ingrese la descripción y el nombre del módulo. En la descripción del módulo, puede especificar todos los requisitos necesarios, como los atributos de entidad y las operaciones requeridas. El trabajo restante del núcleo es realizado por micro-agentes: Developer, Troubleshootery TestsFixer.

Aquí hay un ejemplo de una generación de código exitosa:

A continuación se muestra otro ejemplo que demuestra cómo se solucionó un error de compilación:

El siguiente es un ejemplo de un generado orders Código de módulo:

Un detalle clave es que puede generar código paso a paso, comenzando con un módulo y agregando otras hasta que todas las API requeridas estén completas. Este enfoque le permite generar código para todos los módulos requeridos en solo unas pocas ejecuciones de comando.

Cómo funciona

Como se mencionó anteriormente, todo el trabajo es realizado por esos micro-agentes: Developer, Troubleshooter y TestsFixercontrolado por el Orchestrator. Se ejecutan en el orden listado, con el Developer Generando la mayor parte de la base de código. Después de cada paso de generación de código, se realiza una verificación para los archivos faltantes en función de sus roles (por ejemplo, rutas, controladores, servicios). Si falta algún archivo, se realiza un nuevo intento de generación de código, incluidas las instrucciones en el mensaje sobre los archivos y ejemplos faltantes para cada rol. Una vez que el Developer Comienza su trabajo, comienza la compilación de TypeScript. Si se encuentran algún error, el Troubleshooter Se hace cargo, pasando los errores al aviso y esperando el código corregido. Finalmente, cuando la compilación tiene éxito, se ejecutan las pruebas E2E. Siempre que falla una prueba, el TestsFixer Entren con instrucciones de inmediato específicas, asegurando que todas las pruebas pasen y el código permanezca limpio.

Todos los micro-agentes se derivan del BaseAgent clase y reutilización activamente sus implementaciones de métodos base. Aquí está el Developer Implementación de referencia:

Cada agente utiliza su aviso específico. Mira este GitHub enlace para el aviso utilizado por el Developer.

Después de dedicar un esfuerzo significativo a la investigación y las pruebas, refiné las indicaciones para todos los microgentes, lo que resultó en un código limpio y bien estructurado con muy pocos problemas.

Durante el desarrollo y las pruebas, se utilizó con varias descripciones de módulos, que van desde simples hasta altamente detalladas. Aquí hay algunos ejemplos:

- The module responsible for library book management must handle endpoints for CRUD operations on books.
- The module responsible for the orders management. It must provide CRUD operations for handling customer orders. Users can create new orders, read order details, update order statuses or information, and delete orders that are canceled or completed. Order must have next attributes: name, status, placed source, description, image url
- Asset Management System with an "Assets" module offering CRUD operations for company assets. Users can add new assets to the inventory, read asset details, update information such as maintenance schedules or asset locations, and delete records of disposed or sold assets.

Prueba con gpt-4o-mini y claude-3-5-sonnet-20241022 Mostró la calidad del código de salida comparable, aunque el soneto es más costoso. Claude Haiku (claude-3–5-haiku-20241022), aunque más barato y similar en precio a gpt-4o-minia menudo produce código no compilable. En general, con gpt-4o-miniuna sola sesión de generación de código consume un promedio de alrededor de 11k tokens de entrada y tokens de salida de 15k. Esto equivale a un costo de aproximadamente 2 centavos por sesión, basado en un precio de token de 15 centavos por 1 m tokens de entrada y 60 centavos por 1 m de tokens de salida (a partir de diciembre de 2024).

A continuación se presentan registros de uso antrópico que muestran consumo de token:

Según mi experimentación en las últimas semanas, concluyo que, si bien aún puede haber algunos problemas con el paso de las pruebas generadas, el 95% del código generado es compilable y ejecutable.

Espero que hayas encontrado algo de inspiración aquí y que sirva como punto de partida para tu próxima API Node.js o una actualización a tu proyecto actual. Si tiene sugerencias de mejoras, no dude en contribuir enviando relaciones públicas para código o actualizaciones rápidas.

Si disfrutó de este artículo, no dude en aplaudir o compartir sus pensamientos en los comentarios, si ideas o preguntas. ¡Gracias por leer y feliz experimento!

ACTUALIZAR [February 9, 2025]: El repositorio de GitHub de Codegen LLM se actualizó con API de Speeek apoyo. Es más barato que gpt-4o-mini y ofrece casi la misma calidad de salida, pero tiene un tiempo de respuesta más largo y, a veces, lucha con los errores de solicitud de API.

A menos que se indique lo contrario, todas las imágenes son del autor