DEV Community: 오병진

Framework-Level DI Even for student Node.js Developers

오병진 — Tue, 25 Mar 2025 07:48:03 +0000

When developing servers with Node.js, one often encounters the alluring temptation of Spring.

This is because of its structured, systematic nature, and the difficulty in breaking free from its constraints.

Therefore, in the Node.js community, a framework called Nest.js emerged.

It stemmed from the strong desire to develop servers in a structured format, similar to Spring.

However, Spring's DI utilizes runtime reflection at the language level to support DI.

Similarly, Dotnet uses attributes to track and perform DI through reflection.

So, how does Nest.js achieve DI?

Spring and Dotnet leverage reflection at the language level because their underlying languages are compiled languages.

But ECMAScript is merely an interpreted language, a commoner, isn't it?

Below is one example from the Nest.js tutorial.

import { Controller, Get, Post, Body } from '@nestjs/common';
import { CreateCatDto } from './dto/create-cat.dto';
import { CatsService } from './cats.service';
import { Cat } from './interfaces/cat.interface';

@Controller('cats')
export class CatsController {
    constructor(private catsService: CatsService) {}
    @Post()
    async create(@Body() createCatDto: CreateCatDto) {
        this.catsService.create(createCatDto);
    }
    @Get()
    async findAll(): Promise<Cat[]> {
        return this.catsService.findAll();
    }
}

Clearly, this TypeScript code, after compilation, will lack type tags. Therefore, it won't know the argument types needed for the constructor of the class.

The solution lay in the language specification.

Reflect

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Reflect

Fortunately, there was a built-in feature that allows adding metadata to each object at the language level.

It's a simple function that adds and retrieves metadata from objects.

So, TypeScript thought:

What if we add type information to the metadata when compiling classes?

Therefore, TypeScript stores the information about the argument types needed for the constructor of a class in Reflect whenever a class decorator is used.

This doesn't involve any transformations or black magic; it's purely a feature of the TypeScript compiler.

With the types of the constructor's arguments stored in the class's metadata,

we can retrieve the types and use them accordingly.

You can examine the implementation in NestJS, but it's quite extensive, so I recommend another library.

https://github.com/microsoft/tsyringe/blob/master/src/decorators/injectable.ts

This library, created by Microsoft, has very clean code.

I recommend checking it out. This concludes the post.

How to Force an LLM to Output JSON

오병진 — Thu, 20 Mar 2025 08:18:08 +0000

How does an LLM reliably produce responses that strictly follow JSON syntax when using features like "json_mode" or "function calling"?

These options actually provide an answer to the question: "How can we get an LLM to generate responses exactly the way we want?"

You're probably familiar with the fact that LLMs generate responses token by token, step-by-step.

But what's not commonly known, especially outside technical circles, is that each token is generated probabilistically.

Then, what if we could influence or adjust the probabilities, discouraging tokens that don't match our desired format?

Wouldn't that let us reliably produce code snippets in JSON, CSV, or Python scripts with correct syntax?

Surprisingly, this approach is widely used in practice—known under names like json_mode, structured output, or function calling.

Given that tokens are selected probabilistically, couldn't we intentionally manipulate these probabilities?

Here's an example from llama.cpp:
https://github.com/ggml-org/llama.cpp/blob/master/grammars/json.gbnf

By artificially setting the probabilities of grammatically incorrect tokens to zero, we can ensure the LLM strictly adheres to the desired syntax.

Function Calling for Elementary School Students

오병진 — Mon, 17 Mar 2025 07:16:51 +0000

In the previous article, we discussed important keywords frequently used in LLM that are beneficial to know directly.
We also covered Function Calling, which is central to modern LLMs, AI, and agents.

However, it seems that the concept of Function Calling (Tool Calling) isn't as widely understood as one might expect.
Therefore, I decided to summarize the concept of Function Calling clearly.

import { OpenAI } from "openai";

const openai = new OpenAI({ apiKey: "YOUR_API_KEY" });

async function callFunction() {
  const response = await openai.chat.completions.create({
    model: "gpt-4o",
    messages: [
      { role: "user", content: "Tell me the current time." }
    ],
    functions: [
      {
        name: "get_current_time",
        description: "Returns the current time.",
        parameters: {},
      },
    ],
    function_call: "auto",
  });

  if (response.choices[0].message.function_call) {
    console.log("Function called by LLM:", response.choices[0].message.function_call.name);
  }
}

callFunction();

If you've read the previous article, this code snippet might look familiar.

When you send a message to an LLM, it responds by selecting both the message and which function (if any) to call.

If the function_call option is set to required, it must always call a function. If it's set to auto, it may choose not to call one.

Then how am I supposed to get the function arguments in this case..??

This is actually the most important part. It's pretty rare to call a function without providing any arguments at all.

So typically, we ask the LLM to fill in these argument values for us.

To guide the LLM on how to fill them, we provide it with a function list, including the parameters defined using a JSON Schema. (A JSON Schema is basically a JSON specification describing exactly how the JSON object should be structured.)

async function callFunction() {
  const response = await openai.chat.completions.create({
    model: "gpt-4o",
    messages: [
      { role: "user", content: "What's the weather like in Seoul?" }
    ],
    functions: [
      {
        name: "get_weather",
        description: "Returns the current weather information for a given city.",
        parameters: {
          type: "object",
          properties: {
            city: {
              type: "string",
              description: "Name of the city to retrieve weather information for."
            }
          },
          required: ["city"]
        }
      }
    ],
    function_call: "auto",
  });

  const functionCall = response.choices[0].message.function_call;

  if (functionCall) {
    console.log("Function called by LLM:", functionCall.name);

    const args = JSON.parse(functionCall.arguments);
    const result = get_weather(args.city);

    console.log(`City: ${args.city}, Weather: ${result}`);
  }
}

function get_weather(city) {
  // Dummy data returned instead of a real API call
  const weatherData = {
    "Seoul": "Sunny, 15°C",
    "New York": "Cloudy, 8°C",
    "Tokyo": "Rainy, 12°C"
  };

  return weatherData[city] || "Weather information not found.";
}

callFunction();

https://sdk.vercel.ai/docs/foundations/tools#schemas

And that's the story of modern Function Calling, up until today.

Then... what exactly can we do with this?

Well, you can build those beloved services you often use, like cline, continue, windsurf, or cursor.

Here's a leaked prompt from a service called Manus:
https://gist.github.com/jlia0/db0a9695b3ca7609c9b1a08dcbf872c9

As you can see, they're enthusiastically providing a bunch of functions. All these details are fed into the LLM under the tools property.

In short, by using Function Calling, you can create all those amazing services mentioned above.

Now, you might think: "Okay, I get Function Calling, but how do we handle file modifications?"

This is also simple—just declare a function that the LLM can understand.

Instead of rewriting an entire file, you let the LLM rewrite only certain portions of the code—exactly like how we, humans, modify code bit by bit.

This is much cleaner, easier, and less error-prone.

But honestly, writing JSON Schema manually like this is just too much…

As we discussed earlier, manually writing each schema can feel quite tedious—what we'd casually call "annoying."

It's a task prone to mistakes when done by hand, and it's super easy for your schemas to drift away from the actual specifications without even noticing.

Think about Swagger—same issue there.

That's exactly why I prefer typia over zod.

Here's an example of how effortlessly Typia handles this:

https://typia.io/playground

Not only does it easily generate JSON Schemas like the example above, it even creates validation functions to verify your outputs.

But still, even with tools like this, building an agent from scratch can feel pretty tedious—unless you're someone who genuinely enjoys coding. Some people just want to quickly experiment or try out ideas without all the hassle.

That's exactly why our team is developing a library called Agentica:

https://github.com/wrtnlabs/agentica

Right now, we're deeply thinking about, "How can we make building agents as simple and intuitive as possible?"

Our goal is to make it accessible, whether you're a backend developer, frontend developer, or even someone completely outside of LLM-specific roles—so anyone can easily dive in and create their own agents.

OpenAI Agents Are Language-Dependent

오병진 — Fri, 14 Mar 2025 05:50:55 +0000

Recently, OpenAI released a generative AI project called openai-agents-python.

I believe the biggest difference in this release is the ability to register tools simply, as shown in the following code:

@function_tool
def get_weather(city: str) -> str:
    return f"the weather in {city} is sunny."

agent = agent(
    name="hello world",
    instructions="you are a helpful agent.",
    tools=[get_weather],
)

Previously, developers had to manually write JSON schemas or use libraries to create them. This manual process meant that actual code and interfaces remained separate. The new release is notable because of the function_tool decorator, which automates JSON schema creation by extracting metadata from functions:

# 2. inspect function signature and get type hints
sig = inspect.signature(func)
type_hints = get_type_hints(func)
params = list(sig.parameters.items())
takes_context = False
filtered_params = []

This functionality significantly reduces manual labor associated with writing JSON schemas.

However, this approach has a few limitations:

First, it only reads type annotations provided explicitly by users. Without these annotations, it cannot generate accurate JSON schemas.

Second, because it relies on reflection, it may not be supported in languages lacking proper reflection capabilities. In other words, it's "language-dependent."

Despite these limitations, the convenience is still impressive.

Is there something similar in TypeScript?

Interestingly, the Korean tech community identified this need early on and developed libraries in a similar direction—almost a year ahead. A Korean developer, Samchon, created typia and openapi.

These libraries allow TypeScript developers to automatically generate JSON schemas and validation code at compile-time, using only type definitions (interfaces) rather than full functions or classes.

You can see an example of an agent built using typia and openapi here.

Here's a snippet from that repository:

export const functions = typia.llm.application<tool, "chatgpt">().functions.map((func): ChatCompletionTool => {
  return {
    type: "function",
    function: {
      name: func.name,
      description: func.description,
      parameters: func.parameters as Record<string, any>,
    },
  };
});

With this simple code, you can easily extract a list of tools as JSON schemas.

If you're curious about how this transformation works, you can check it out in the typia playground.

If you find these repositories helpful, consider giving them a star—it would encourage the maintainers greatly.

LLM for Elementary School Students

오병진 — Mon, 10 Mar 2025 08:24:25 +0000

The hottest keyword in the industry these days is LLM.
Models like Claude 3.5 and Grok3 are constantly emerging,
and services utilizing LLMs, such as Character.AI, are also increasing.

As developers, we'll likely integrate LLMs into our services someday,
so it's a good idea to familiarize ourselves with the basic concepts beforehand to avoid confusion!
So, I've summarized the key keywords.

LLM
Simply put, LLM (Large Language Model) is
"an AI that understands text input and responds with text."
Models like GPT-4, Claude 3, and Grok3 are prime examples.

These days, LLMs go beyond simply generating sentences,
performing various tasks such as coding, image analysis, and solving equations.
It seems we've entered an era where developers utilize AI as a tool.

Tool Call, Function Call
LLMs don't just provide answers; they can also be instructed to
"call the necessary tools to assist with the task."

For example,

If a user says, "Calculate this number,"
the LLM requests the calculator API to be called,
and then delivers the result back to the user.
However, the LLM itself doesn't directly call the API;
we need to implement the actual call in code 😢

RAG (Retrieval-Augmented Generation)
No matter how intelligent an LLM is,
it generates answers based only on the data it has been trained on.
So, how does it retrieve information like the latest news or internal documents?

That's where RAG comes in.

It first searches (Retrieval) for necessary information from an external database,
and then generates (Generation) an answer based on that information.
This allows the LLM to incorporate up-to-date information.

In short, before the LLM answers, it's fed the necessary materials for the answer, and the summarization or answering based on those materials is all called RAG.

4B, 8B, 308B? What do these numbers mean?

When you look at LLM models, you'll see numbers like 8B and 70B attached.
This refers to the number of parameters (Parameter) the model has been trained on.

8B (8 billion) → Lightweight model, fast
308B (308 billion) → Extremely large model, but slow

Larger models are more accurate, but speed and cost can be a burden.
These days, effectively utilizing lightweight models is a trend.

Heavier models result in slower response times,
leading to higher churn rates among end-users.

Multi-Agent
Instead of an LLM handling everything alone,
multiple smaller AI's (agents) work collaboratively.

For example:

One handles coding,
another handles data analysis,
and another handles document organization.
Dividing roles like this results infaster speeds and more accurate responses.
Isn't it just like a company? Someone handles the frontend... someone handles the backend...

Validation Feedback
LLMs don't always give the right answer.
They might provide incorrect answers.

Therefore, **Validation Feedback **is necessary.

If the user provides feedback on whether the LLM's response is correct or incorrect,
the model can become increasingly intelligent.
This can be automated to create a self-learning system for the LLM.

Or, when Function Call or response format is defined,
if it doesn't follow the format, it can be forced to follow it.

Using Function Call in OpenAI
To actually use Function Call with OpenAI's GPT-4,
it can be implemented as follows.

🔹 TypeScript Example


import { OpenAI } from "openai";

const openai = new OpenAI({ apiKey: "YOUR_API_KEY" });

async function callFunction() {
  const response = await openai.chat.completions.create({
    model: "gpt-4",
    messages: [
      { role: "user", content: "Tell me the current time" }
    ],
    functions: [
      {
        name: "get_current_time",
        description: "Returns the current time.",
        parameters: {},
      },
    ],
    function_call: "auto",
  });

  if (response.choices[0].message.function_call) {
    console.log("Function called by LLM:", response.choices[0].message.function_call.name);
  }
}

callFunction();

By using Function Call in this way,
LLMs can evolve into a "truly useful AI" that performs actual functions, rather than just generating text.

Agentica

Carefully filling in argument values for these Function Calls can be quite tedious.
Therefore, services like Vercel AI and LangChain use the zod library to
perform Validation Feedback on whether the argument values returned by the LLM are correct.

This ensures highly accurate Function Calls.

However, writing schemas for each argument of complex functions using zod can be very cumbersome, and
developers might find it "tedious".

Therefore, I recommend the Agentica library.

import { Agentica } from "@agentica/core";
import typia from "typia";

const agent = new Agentica({
  controllers: [
    await fetch(
      "https://shopping-be.wrtn.ai/editor/swagger.json",
    ).then(r => r.json()),
    typia.llm.application<ShoppingCounselor>(),
    typia.llm.application<ShoppingPolicy>(),
    typia.llm.application<ShoppingSearchRag>(),
  ],
});
await agent.conversate("I wanna buy MacBook Pro");

With this simple code, functions in three classes and swagger endpoints are
designated as Function Calls and automatically called during conversations.

This creates a simple "chatbot agent".

The field of handling LLMs and AI is becoming increasingly user-friendly.
The advancement of technology is truly awe-inspiring.