The best way to Use an LLM-Powered Boilerplate for Constructing Your Own Node.js API

For a very long time, considered one of the common ways to start out recent Node.js projects was using boilerplate templates. These templates help developers reuse familiar code structures and implement standard features, comparable to access to cloud file storage. With the newest developments in LLM, project boilerplates seem like more useful than ever.

Constructing on this progress, I’ve prolonged my existing Node.js API boilerplate with a brand new tool LLM Codegen. This standalone feature enables the boilerplate to routinely generate module code for any purpose based on text descriptions. The generated module comes complete with E2E tests, database migrations, seed data, and vital business logic.

History

I initially created a GitHub repository for a Node.js API boilerplate to consolidate the perfect practices I’ve developed through the years. Much of the implementation is predicated on code from an actual Node.js API running in production on AWS.

I’m obsessed with vertical slicing architecture and Clean Code principles to maintain the codebase maintainable and clean. With recent advancements in LLM, particularly its support for big contexts and its ability to generate high-quality code, I made a decision to experiment with generating clean TypeScript code based on my boilerplate. This boilerplate follows specific structures and patterns that I consider are of top quality. The important thing query was whether the generated code would follow the identical patterns and structure. Based on my findings, it does.

To recap, here’s a fast highlight of the Node.js API boilerplate’s key features:

• Vertical slicing architecture based on DDD & MVC principles
• Services input validation using ZOD
• Decoupling application components with dependency injection (InversifyJS)
• Integration and E2E testing with Supertest
• Multi-service setup using Dockercompose

Over the past month, I’ve spent my weekends formalizing the answer and implementing the vital code-generation logic. Below, I’ll share the small print.

Implementation Overview

Let’s explore the specifics of the implementation. All Code Generation logic is organized on the project root level, contained in the llm-codegen folder, ensuring easy navigation. The Node.js boilerplate code has no dependency on llm-codegen, so it could be used as an everyday template without modification.

It covers the next use cases:

• Generating clean, well-structured code for brand spanking new module based on input description. The generated module becomes a part of the Node.js REST API application.
• Creating database migrations and lengthening seed scripts with basic data for the brand new module.
• Generating and fixing E2E tests for the brand new code and ensuring all tests pass.

The generated code after the primary stage is clean and adheres to vertical slicing architecture principles. It includes only the vital business logic for CRUD operations. In comparison with other code generation approaches, it produces clean, maintainable, and compilable code with valid E2E tests.

The second use case involves generating DB migration with the suitable schema and updating the seed script with the vital data. This task is especially well-suited for LLM, which handles it exceptionally well.

The ultimate use case is generating E2E tests, which help confirm that the generated code works accurately. Throughout the running of E2E tests, an SQLite3 database is used for migrations and seeds.

Mainly supported LLM clients are OpenAI and Claude.

The best way to Use It

To start, navigate to the foundation folder llm-codegen and install all dependencies by running:

npm i

llm-codegen doesn’t depend on Docker or some other heavy third-party dependencies, making setup and execution easy and easy. Before running the tool, be sure that you set no less than one *_API_KEY environment variable within the .env file with the suitable API key in your chosen LLM provider. All supported environment variables are listed within the .env.sample file (OPENAI_API_KEY, CLAUDE_API_KEY etc.) You should utilize OpenAI, Anthropic Claude, or OpenRouter LLaMA. As of mid-December, OpenRouter LLaMA is surprisingly free to make use of. It’s possible to register here and procure a token at no cost usage. Nonetheless, the output quality of this free LLaMA model could possibly be improved, as a lot of the generated code fails to pass the compilation stage.

To start out llm-codegen, run the next command:

npm run start

Next, you’ll be asked to input the module description and name. Within the module description, you possibly can specify all vital requirements, comparable to entity attributes and required operations. The core remaining work is performed by micro-agents: Developer, Troubleshooter, and TestsFixer.

Here is an example of a successful code generation:

Below is one other example demonstrating how a compilation error was fixed:

The next is an example of a generated orders module code:

A key detail is which you can generate code step-by-step, starting with one module and adding others until all required APIs are complete. This approach lets you generate code for all required modules in only a number of command runs.

How It Works

As mentioned earlier, all work is performed by those micro-agents: Developer, Troubleshooter and TestsFixer, controlled by the Orchestrator. They run within the listed order, with the Developer generating a lot of the codebase. After each code generation step, a check is performed for missing files based on their roles (e.g., routes, controllers, services). If any files are missing, a brand new code generation attempt is made, including instructions within the prompt in regards to the missing files and examples for every role. Once the Developer completes its work, TypeScript compilation begins. If any errors are found, the Troubleshooter takes over, passing the errors to the prompt and waiting for the corrected code. Finally, when the compilation succeeds, E2E tests are run. At any time when a test fails, the TestsFixer steps in with specific prompt instructions, ensuring all tests pass and the code stays clean.

All micro-agents are derived from the BaseAgent class and actively reuse its base method implementations. Here is the Developer implementation for reference:

Each agent utilizes its specific prompt. Take a look at this GitHub link for the prompt utilized by the Developer.

After dedicating significant effort to research and testing, I refined the prompts for all micro-agents, leading to clean, well-structured code with only a few issues.

Throughout the development and testing, it was used with various module descriptions, starting from easy to highly detailed. Listed here are a number of examples:

- The module answerable for library book management must handle endpoints for CRUD operations on books.
- The module answerable for the orders management. It must provide CRUD operations for handling customer orders. Users can create recent orders, read order details, update order statuses or information, and delete orders which might be canceled or accomplished. Order should 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 recent assets to the inventory, read asset details, update information comparable to maintenance schedules or asset locations, and delete records of disposed or sold assets.

Testing with gpt-4o-mini and claude-3-5-sonnet-20241022 showed comparable output code quality, although Sonnet is dearer. Claude Haiku (claude-3–5-haiku-20241022), while cheaper and similar in price to gpt-4o-mini, often produces non-compilable code. Overall, with gpt-4o-mini, a single code generation session consumes a mean of around 11k input tokens and 15k output tokens. This amounts to a price of roughly 2 cents per session, based on token pricing of 15 cents per 1M input tokens and 60 cents per 1M output tokens (as of December 2024).

Below are Anthropic usage logs showing token consumption:

Based on my experimentation over the past few weeks, I conclude that while there should be some issues with passing generated tests, 95% of the time generated code is compilable and runnable.

I hope you found some inspiration here and that it serves as a place to begin in your next Node.js API or an upgrade to your current project. Should you could have suggestions for improvements, be at liberty to contribute by submitting PR for code or prompt updates.

For those who enjoyed this text, be at liberty to clap or share your thoughts within the comments, whether ideas or questions. Thanks for reading, and completely satisfied experimenting!

UPDATE [February 9, 2025]: The LLM-Codegen GitHub repository was updated with DeepSeek API support. It’s cheaper than gpt-4o-mini and offers nearly the identical output quality, however it has an extended response time and sometimes struggles with API request errors.