Principles of Domain-Specific Languages (DSL)Principles of Domain-Specific Languages (DSL)

Learning ObjectivesLearning Objectives

In backend development, beyond the business logic written in general-purpose programming languages (Python, Go, Java, etc.), there are numerous files and code with different purposes, different syntaxes, but none belonging to general-purpose programming languages. They share a common umbrella concept: DSL (Domain-Specific Language).In backend development, beyond the business logic written in general-purpose programming languages (Python, Go, Java, etc.), there are numerous files and code with different purposes, different syntaxes, but none belonging to general-purpose programming languages. They share a common umbrella concept: DSL (Domain-Specific Language).

After reading this article, you will be able to:After reading this article, you will be able to:

• Understand the essential difference between DSL and general-purpose programming languages (GPL)Understand the essential difference between DSL and general-purpose programming languages (GPL)
• Master the DSL classification system: data serialization formats, embedded scripting languages, infrastructure definition languagesMaster the DSL classification system: data serialization formats, embedded scripting languages, infrastructure definition languages
• Distinguish the applicable scenarios of XML, JSON, YAML, TOML, CSV, Protobuf, and other data formatsDistinguish the applicable scenarios of XML, JSON, YAML, TOML, CSV, Protobuf, and other data formats
• Understand the design purpose of embedded scripting languages like LuaUnderstand the design purpose of embedded scripting languages like Lua
• Explain the principles and differences between Terraform (HCL) and PulumiExplain the principles and differences between Terraform (HCL) and Pulumi
• Understand how the OpenAPI specification and SDK auto-generation workUnderstand how the OpenAPI specification and SDK auto-generation work
• Judge which types of code are suitable for AI generationJudge which types of code are suitable for AI generation

------

1. DSL Overview: Another World Beyond General-Purpose Languages1. DSL Overview: Another World Beyond General-Purpose Languages

1.1 Overview of a DSL1.1 Overview of a DSL

DSL (Domain-Specific Language) is a language designed for a specific domain or specific task. In contrast, GPL (General-Purpose Language), such as Python, Java, Go, C++, etc., is designed to solve arbitrary computational problems.DSL (Domain-Specific Language) is a language designed for a specific domain or specific task. In contrast, GPL (General-Purpose Language), such as Python, Java, Go, C++, etc., is designed to solve arbitrary computational problems.

The core differences:The core differences:

You've actually been using DSLs all along:You've actually been using DSLs all along:

• SQL is a DSL for the database querying domain — you use SELECT * FROM users WHERE age > 18 to query data, rather than manually writing traversal logic in PythonSQL is a DSL for the database querying domain — you use SELECT * FROM users WHERE age > 18 to query data, rather than manually writing traversal logic in Python
• HTML/CSS are DSLs for web structure and styling — you use tags and attributes to describe pages, rather than manipulating pixels in C++HTML/CSS are DSLs for web structure and styling — you use tags and attributes to describe pages, rather than manipulating pixels in C++
• Regular expressions are a DSL for text pattern matching — you use \d{3}-\d{4} to match phone numbers, rather than writing character comparison loops by handRegular expressions are a DSL for text pattern matching — you use \d{3}-\d{4} to match phone numbers, rather than writing character comparison loops by hand

1.2 DSL Classification1.2 DSL Classification

DSLs can be divided into two major categories based on "whether they are Turing-complete":DSLs can be divided into two major categories based on "whether they are Turing-complete":

External DSLExternal DSL

Has independent syntax and parser, not dependent on any general-purpose programming language. The code written by users is processed by a dedicated interpreter or compiler.Has independent syntax and parser, not dependent on any general-purpose programming language. The code written by users is processed by a dedicated interpreter or compiler.

• Pure data description type: JSON, YAML, XML, TOML, CSV, Protobuf (contains no logic whatsoever)Pure data description type: JSON, YAML, XML, TOML, CSV, Protobuf (contains no logic whatsoever)
• Query/operation type: SQL, GraphQL, regular expressions (limited logic capability)Query/operation type: SQL, GraphQL, regular expressions (limited logic capability)
• Domain modeling type: HCL (Terraform), Dockerfile, Nginx configuration syntax (declaratively describes the state of a specific domain)Domain modeling type: HCL (Terraform), Dockerfile, Nginx configuration syntax (declaratively describes the state of a specific domain)

Internal DSL (Embedded DSL)Internal DSL (Embedded DSL)

Parasitically lives inside a general-purpose programming language, using the host language's syntax to build domain-specific expressions. The code itself is valid host language code, but reads like a specialized language.Parasitically lives inside a general-purpose programming language, using the host language's syntax to build domain-specific expressions. The code itself is valid host language code, but reads like a specialized language.

• Pulumi (written in TypeScript/Python/Go, but the API design reads like declarative configuration)Pulumi (written in TypeScript/Python/Go, but the API design reads like declarative configuration)
• Ruby on Rails route definitions (get '/users', to: 'users#index' — valid Ruby code, but reads like configuration)Ruby on Rails route definitions (get '/users', to: 'users#index' — valid Ruby code, but reads like configuration)
• Test framework assertion syntax (expect(value).toBe(42) — valid JavaScript, but reads like natural language)Test framework assertion syntax (expect(value).toBe(42) — valid JavaScript, but reads like natural language)

1.3 DSL Landscape in Backend Projects1.3 DSL Landscape in Backend Projects

In a typical backend project, you'll encounter the following categories of DSLs:In a typical backend project, you'll encounter the following categories of DSLs:

DSLs in Backend Projects ├── Data Serialization Formats (describe data structures) │ ├── Text formats: JSON, YAML, XML, TOML, CSV, INI │ └── Binary formats: Protobuf, MessagePack, Avro, BSON ├── Embedded Scripting Languages (programmable configuration layer) │ ├── Lua (game engines, Nginx, Redis) │ ├── GDScript (Godot engine) │ └── Jsonnet (configuration template generation) ├── Infrastructure and Ops DSLs (declaratively describe system state) │ ├── HCL (Terraform) │ ├── Dockerfile / Docker Compose YAML │ └── Nginx / Apache configuration syntax └── Interface Description Languages (describe API contracts) ├── OpenAPI / Swagger ├── Protocol Buffers (.proto files) └── GraphQL Schema

With this landscape in mind, the following chapters will unfold each branch one by one.With this landscape in mind, the following chapters will unfold each branch one by one.

------

2. Data Serialization Formats: Describing Structured Data in Text2. Data Serialization Formats: Describing Structured Data in Text

2.1 Overview of Data Serialization2.1 Overview of Data Serialization

Serialization is the process of converting in-memory data structures (objects, dictionaries, arrays, etc.) into a storable or transmissible text/byte stream. The reverse process — restoring in-memory data structures from text/byte streams — is called deserialization.Serialization is the process of converting in-memory data structures (objects, dictionaries, arrays, etc.) into a storable or transmissible text/byte stream. The reverse process — restoring in-memory data structures from text/byte streams — is called deserialization.

Data serialization formats are the most fundamental category of DSLs — they are pure data description external DSLs with no logic capability, responsible only for statically describing "what the value is."Data serialization formats are the most fundamental category of DSLs — they are pure data description external DSLs with no logic capability, responsible only for statically describing "what the value is."

2.2 Motivation for needing These Formats2.2 Motivation for needing These Formats

Suppose you've developed a backend service with a database address of localhost:5432. If you hardcode this address in the source code, local development works fine, but when deploying to production, the database address changes to db.prod.company.com:5432, and you'd need to modify the source code and recompile.Suppose you've developed a backend service with a database address of localhost:5432. If you hardcode this address in the source code, local development works fine, but when deploying to production, the database address changes to db.prod.company.com:5432, and you'd need to modify the source code and recompile.

The standard engineering practice is: separate variable parameters from code and store them in independent configuration files. The program reads the configuration file at startup and determines its behavior based on the values within.The standard engineering practice is: separate variable parameters from code and store them in independent configuration files. The program reads the configuration file at startup and determines its behavior based on the values within.

Beyond configuration, data serialization formats are widely used for: data exchange between systems (API requests/responses), data persistence storage, cross-language communication, and more.Beyond configuration, data serialization formats are widely used for: data exchange between systems (API requests/responses), data persistence storage, cross-language communication, and more.

2.3 Human-Readable Text Formats2.3 Human-Readable Text Formats

The following are the most common text serialization formats in engineering, introduced in chronological order.The following are the most common text serialization formats in engineering, introduced in chronological order.

INIINI

The earliest configuration format, originating from Windows systems. Simple structure, composed of sections and key-value pairs:The earliest configuration format, originating from Windows systems. Simple structure, composed of sections and key-value pairs:

[database] host = localhost port = 5432 [server] debug = true

The advantage is strong readability. The limitation is no support for nested structures or array types, making it unable to express complex configurations. Currently mainly found in legacy systems and some Linux configurations (like php.ini, my.cnf).The advantage is strong readability. The limitation is no support for nested structures or array types, making it unable to express complex configurations. Currently mainly found in legacy systems and some Linux configurations (like php.ini, my.cnf).

CSVCSV

CSV (Comma-Separated Values) is the simplest tabular data format:CSV (Comma-Separated Values) is the simplest tabular data format:

name,age,city Alice,30,Beijing Bob,25,Shanghai

Each row is a record, with fields separated by commas. CSV is widely used for data import/export, spreadsheet exchange, and data analysis pipelines. Its limitation is that it can only express flat two-dimensional tables, doesn't support nested structures, and has no type information (all values are strings).Each row is a record, with fields separated by commas. CSV is widely used for data import/export, spreadsheet exchange, and data analysis pipelines. Its limitation is that it can only express flat two-dimensional tables, doesn't support nested structures, and has no type information (all values are strings).

XMLXML

XML (eXtensible Markup Language) was born in 1998 and was once the mainstream standard for data exchange:XML (eXtensible Markup Language) was born in 1998 and was once the mainstream standard for data exchange:

<?xml version="1.0" encoding="UTF-8"?> <config> <database> <host>localhost</host> <port>5432</port> </database> <server> <debug>true</debug> <allowed_origins> <origin>https://example.com</origin> <origin>https://app.example.com</origin> </allowed_origins> </server> </config>

XML has very strong expressive power, supporting nesting, attributes, namespaces, Schema validation, and other advanced features. But its syntax is verbose — large amounts of opening/closing tags result in a low signal-to-noise ratio, and the experience of writing and reading by hand is poor.XML has very strong expressive power, supporting nesting, attributes, namespaces, Schema validation, and other advanced features. But its syntax is verbose — large amounts of opening/closing tags result in a low signal-to-noise ratio, and the experience of writing and reading by hand is poor.

XML is still widely used in:XML is still widely used in:

• Java ecosystem (Maven's pom.xml, Spring configuration, Android layout files)Java ecosystem (Maven's pom.xml, Spring configuration, Android layout files)
• Enterprise web services (SOAP protocol)Enterprise web services (SOAP protocol)
• Office document formats (.docx, .xlsx are essentially ZIP-compressed collections of XML files)Office document formats (.docx, .xlsx are essentially ZIP-compressed collections of XML files)
• RSS/Atom feeds, SVG vector graphicsRSS/Atom feeds, SVG vector graphics

JSONJSON

JSON (JavaScript Object Notation) was born in 2001 and rapidly replaced XML as the de facto standard for Web API data exchange due to its simplicity:JSON (JavaScript Object Notation) was born in 2001 and rapidly replaced XML as the de facto standard for Web API data exchange due to its simplicity:

{ "database": { "host": "localhost", "port": 5432 }, "server": { "debug": true } }

Its advantages are clear structure and native parsing support in virtually all programming languages. The main drawback is no support for comments, and the numerous brackets and quotes are error-prone when writing by hand. JSON is also the standard format for frontend project configuration (package.json, tsconfig.json).Its advantages are clear structure and native parsing support in virtually all programming languages. The main drawback is no support for comments, and the numerous brackets and quotes are error-prone when writing by hand. JSON is also the standard format for frontend project configuration (package.json, tsconfig.json).

YAMLYAML

YAML (YAML Ain't Markup Language) was also born in 2001 and is currently the most widely used configuration format in the backend and DevOps world. Docker Compose, Kubernetes, GitHub Actions, and other tools all use YAML:YAML (YAML Ain't Markup Language) was also born in 2001 and is currently the most widely used configuration format in the backend and DevOps world. Docker Compose, Kubernetes, GitHub Actions, and other tools all use YAML:

# Database configuration database: host: localhost port: 5432 # Server configuration server: debug: true allowed_origins: - https://example.com - https://app.example.com

Advantages include comment support, concise syntax, and the ability to express complex nested structures. The disadvantage is that it relies on indentation to represent hierarchy — indentation errors cause parsing failures, which is the most common issue for beginners.Advantages include comment support, concise syntax, and the ability to express complex nested structures. The disadvantage is that it relies on indentation to represent hierarchy — indentation errors cause parsing failures, which is the most common issue for beginners.

> Note: YAML's full name "YAML Ain't Markup Language" is a recursive acronym.> Note: YAML's full name "YAML Ain't Markup Language" is a recursive acronym.

TOMLTOML

TOML (Tom's Obvious Minimal Language) was born in 2013 and is adopted by Rust's package manager Cargo and Python's pyproject.toml:TOML (Tom's Obvious Minimal Language) was born in 2013 and is adopted by Rust's package manager Cargo and Python's pyproject.toml:

[database] host = "localhost" port = 5432 [server] debug = true allowed_origins = [ "https://example.com", "https://app.example.com" ]

TOML attempts to combine INI's simplicity with YAML's expressiveness while avoiding indentation-sensitivity issues.TOML attempts to combine INI's simplicity with YAML's expressiveness while avoiding indentation-sensitivity issues.

2.4 Binary Serialization Formats2.4 Binary Serialization Formats

The above formats are all human-readable text. For scenarios with higher performance and size requirements, there are also binary serialization formats — they sacrifice readability for smaller sizes and faster parsing speeds.The above formats are all human-readable text. For scenarios with higher performance and size requirements, there are also binary serialization formats — they sacrifice readability for smaller sizes and faster parsing speeds.

Taking Protocol Buffers as an example, you need to define the Schema first:Taking Protocol Buffers as an example, you need to define the Schema first:

// user.proto syntax = "proto3"; message User { string name = 1; int32 age = 2; string email = 3; }

Then the compiler (protoc) automatically generates serialization/deserialization code for various languages. This "define Schema first, then generate code" pattern is consistent with the OpenAPI SDK generation approach introduced later.Then the compiler (protoc) automatically generates serialization/deserialization code for various languages. This "define Schema first, then generate code" pattern is consistent with the OpenAPI SDK generation approach introduced later.

2.5 Complete Comparison2.5 Complete Comparison

Key takeaway: The essential function of all these formats is the same — converting structured data into a storable, transmissible form. Text formats prioritize human readability and ease of editing; binary formats prioritize parsing performance and transmission size. Which format to choose depends on the trade-offs required by the specific scenario.Key takeaway: The essential function of all these formats is the same — converting structured data into a storable, transmissible form. Text formats prioritize human readability and ease of editing; binary formats prioritize parsing performance and transmission size. Which format to choose depends on the trade-offs required by the specific scenario.

------

3. Embedded Scripting Languages: The Programmable Configuration Layer3. Embedded Scripting Languages: The Programmable Configuration Layer

3.1 Concept Definition3.1 Concept Definition

Python, JavaScript, Go, and similar languages are general-purpose programming languages (GPLs) that can run independently and build complete applications.Python, JavaScript, Go, and similar languages are general-purpose programming languages (GPLs) that can run independently and build complete applications.

In contrast, there is another category of languages specifically designed to be embedded within other host programs, providing programmable extension capabilities for the host program. These are called embedded scripting languages.In contrast, there is another category of languages specifically designed to be embedded within other host programs, providing programmable extension capabilities for the host program. These are called embedded scripting languages.

The core problem they solve: when static configuration files (YAML/JSON) lack sufficient expressiveness and conditional logic, loops, and other logic are needed, how to achieve dynamic behavior without modifying the host program's source code.The core problem they solve: when static configuration files (YAML/JSON) lack sufficient expressiveness and conditional logic, loops, and other logic are needed, how to achieve dynamic behavior without modifying the host program's source code.

3.2 Lua: The Most Representative Embedded Scripting Language3.2 Lua: The Most Representative Embedded Scripting Language

Lua (meaning "moon" in Portuguese) is an extremely lightweight scripting language; the entire interpreter is only a few hundred KB when compiled. Its design goal is not to run independently, but to serve as an embeddable extension layer.Lua (meaning "moon" in Portuguese) is an extremely lightweight scripting language; the entire interpreter is only a few hundred KB when compiled. Its design goal is not to run independently, but to serve as an embeddable extension layer.

Typical Lua application scenarios:Typical Lua application scenarios:

• Game engines: World of Warcraft's addon system and Roblox's game scripts both use Lua. Game engines implement core rendering and physics computation in C/C++, while delegating frequently-changing parts like level logic and NPC dialogue to Lua scripts. This way, designers can modify game content without recompiling the engine.Game engines: World of Warcraft's addon system and Roblox's game scripts both use Lua. Game engines implement core rendering and physics computation in C/C++, while delegating frequently-changing parts like level logic and NPC dialogue to Lua scripts. This way, designers can modify game content without recompiling the engine.

• Web servers: OpenResty embeds Lua inside Nginx, enabling ops personnel to implement request filtering, rate limiting, authentication, and other logic using Lua scripts without modifying Nginx's C source code.Web servers: OpenResty embeds Lua inside Nginx, enabling ops personnel to implement request filtering, rate limiting, authentication, and other logic using Lua scripts without modifying Nginx's C source code.

• Databases: Redis supports sending Lua scripts to the server for execution, used to implement composite operations requiring atomicity guarantees (such as "read-then-write").Databases: Redis supports sending Lua scripts to the server for execution, used to implement composite operations requiring atomicity guarantees (such as "read-then-write").

Here's an example of a Lua script embedded in Nginx (OpenResty):Here's an example of a Lua script embedded in Nginx (OpenResty):

-- Function: Token authentication for /api/secret path local uri = ngx.var.uri local token = ngx.req.get_headers()["Authorization"] if uri == "/api/secret" and token ~= "Bearer my-secret-token" then ngx.status = 403 ngx.say("Access denied") return ngx.exit(403) end

3.3 Other Embedded Scripting Languages3.3 Other Embedded Scripting Languages

Key takeaway: Embedded scripting languages occupy the boundary between internal DSL and external DSL in the DSL classification — they are independent languages (with their own syntax and interpreters), but their design goal is to be embedded in host programs rather than independently build applications. They fill the gap between "static configuration files" (pure data description DSLs) and "general-purpose programming languages" (GPLs): when configuration needs to express logic (conditional branching, loops, function calls), embedding a lightweight scripting language is the standard engineering solution.Key takeaway: Embedded scripting languages occupy the boundary between internal DSL and external DSL in the DSL classification — they are independent languages (with their own syntax and interpreters), but their design goal is to be embedded in host programs rather than independently build applications. They fill the gap between "static configuration files" (pure data description DSLs) and "general-purpose programming languages" (GPLs): when configuration needs to express logic (conditional branching, loops, function calls), embedding a lightweight scripting language is the standard engineering solution.

------

4. Infrastructure as Code4. Infrastructure as Code

4.1 What Is "Infrastructure"4.1 What Is "Infrastructure"

In backend engineering, "infrastructure" refers to the underlying resources that applications depend on to run:In backend engineering, "infrastructure" refers to the underlying resources that applications depend on to run:

• Compute resources: Servers (virtual machines or containers)Compute resources: Servers (virtual machines or containers)
• Data storage: Database instances, object storage bucketsData storage: Database instances, object storage buckets
• Networking: Firewall rules, load balancers, DNS configurationNetworking: Firewall rules, load balancers, DNS configuration
• Middleware: Message queues, cache clustersMiddleware: Message queues, cache clusters

In the cloud computing era, these resources are created and managed through cloud providers' (AWS, Alibaba Cloud, Tencent Cloud) consoles via graphical interfaces.In the cloud computing era, these resources are created and managed through cloud providers' (AWS, Alibaba Cloud, Tencent Cloud) consoles via graphical interfaces.

4.2 Limitations of Manual Management4.2 Limitations of Manual Management

Manual operations via the console are feasible for small-scale projects, but as project scale grows, the following problems emerge:Manual operations via the console are feasible for small-scale projects, but as project scale grows, the following problems emerge:

1. Not repeatable: Operations aren't recorded; you can't precisely reproduce the same environmentNot repeatable: Operations aren't recorded; you can't precisely reproduce the same environment
2. Not auditable: Can't trace "who changed what configuration, when"Not auditable: Can't trace "who changed what configuration, when"
3. Not collaborative: Operations can't be put under version control or code reviewNot collaborative: Operations can't be put under version control or code review
4. Error-prone: Manual operations in production carry the risk of mistakesError-prone: Manual operations in production carry the risk of mistakes

Infrastructure as Code (IaC) has the core idea: declaratively define infrastructure resources using code, giving them version control, automated execution, and repeatable deployment capabilities.Infrastructure as Code (IaC) has the core idea: declaratively define infrastructure resources using code, giving them version control, automated execution, and repeatable deployment capabilities.

4.3 Terraform4.3 Terraform

Terraform is the most widely used IaC tool, developed by HashiCorp. It uses the dedicated HCL (HashiCorp Configuration Language).Terraform is the most widely used IaC tool, developed by HashiCorp. It uses the dedicated HCL (HashiCorp Configuration Language).

Terraform adopts a declarative paradigm: users describe the desired end state, and Terraform automatically calculates the operations needed to transition from the current state to the target state.Terraform adopts a declarative paradigm: users describe the desired end state, and Terraform automatically calculates the operations needed to transition from the current state to the target state.

hcl 📋 Salin📋 Copy

# Define a cloud server resource "aws_instance" "my_server" { ami = "ami-0c55b159cbfafe1f0" # OS image instance_type = "t3.micro" # Instance type tags = { Name = "my-first-server" } } # Define a PostgreSQL database instance resource "aws_db_instance" "my_database" { engine = "postgres" instance_class = "db.t3.micro" username = "admin" password = "please-use-secrets-manager" }

Execution flow:Execution flow:

bash 📋 Salin📋 Copy

terraform plan # Preview the changes to be made terraform apply # Confirm and execute, automatically creating resources on the cloud platform

4.4 Pulumi4.4 Pulumi

Pulumi offers a different approach: directly use general-purpose programming languages (TypeScript, Python, Go, etc.) to define infrastructure, rather than learning the dedicated HCL syntax.Pulumi offers a different approach: directly use general-purpose programming languages (TypeScript, Python, Go, etc.) to define infrastructure, rather than learning the dedicated HCL syntax.

The same server definition, expressed with Pulumi + TypeScript:The same server definition, expressed with Pulumi + TypeScript:

typescript 📋 Salin📋 Copy

import * as aws from "@pulumi/aws"; const server = new aws.ec2.Instance("my-server", { ami: "ami-0c55b159cbfafe1f0", instanceType: "t3.micro", tags: { Name: "my-first-server" }, }); const bucket = new aws.s3.Bucket("my-bucket", { acl: "private", }); export const serverIp = server.publicIp;

Since it uses general-purpose programming languages, developers can leverage language features like loops, conditional branching, and function abstraction to handle complex infrastructure logic.Since it uses general-purpose programming languages, developers can leverage language features like loops, conditional branching, and function abstraction to handle complex infrastructure logic.

4.5 Terraform vs Pulumi Comparison4.5 Terraform vs Pulumi Comparison

Dimension	Terraform	Pulumi
Language	HCL (dedicated language)	TypeScript / Python / Go and other general-purpose languages
Learning cost	Need to learn HCL syntax	Use already-mastered programming languages, lower learning cost
Community ecosystem	Very mature, covers nearly all cloud providers	Rapidly growing, but smaller scale than Terraform
Use cases	Ops-team-led standardized infrastructure management	Developer-led projects needing complex logic
AI code generation fit	High (fixed patterns)	Very high (essentially general-purpose language code)

Key takeaway: HCL in IaC tools is a typical external DSL — it has independent syntax and a parser, specifically for declaratively describing infrastructure state. Pulumi adopts an internal DSL strategy — using general-purpose programming language syntax to express domain-specific concepts. Both share the same goal (transforming infrastructure management from manual operations to code-driven), but take different paths (dedicated language vs general-purpose language). Code can be put under Git version control, undergo team review, and be automatically executed and rolled back.Key takeaway: HCL in IaC tools is a typical external DSL — it has independent syntax and a parser, specifically for declaratively describing infrastructure state. Pulumi adopts an internal DSL strategy — using general-purpose programming language syntax to express domain-specific concepts. Both share the same goal (transforming infrastructure management from manual operations to code-driven), but take different paths (dedicated language vs general-purpose language). Code can be put under Git version control, undergo team review, and be automatically executed and rolled back.

------

5. Glue Code and SDK Auto-Generation5. Glue Code and SDK Auto-Generation

5.1 What Is Glue Code5.1 What Is Glue Code

In software engineering, glue code refers to code that itself contains no business logic but merely connects two systems or modules.In software engineering, glue code refers to code that itself contains no business logic but merely connects two systems or modules.

Typical glue code includes:Typical glue code includes:

• HTTP request code written when the frontend calls backend APIs (URL construction, header settings, response parsing)HTTP request code written when the frontend calls backend APIs (URL construction, header settings, response parsing)
• HTTP client code written when backend service A calls service B's interfaceHTTP client code written when backend service A calls service B's interface
• Interface adaptation code between different programming languagesInterface adaptation code between different programming languages

The characteristics of such code: highly repetitive, pattern-fixed, but indispensable.The characteristics of such code: highly repetitive, pattern-fixed, but indispensable.

5.2 OpenAPI Specification and Code Auto-Generation5.2 OpenAPI Specification and Code Auto-Generation

Since glue code has highly pattern-based characteristics, the engineering world's solution is: first describe API interfaces in a standard format, then use tools to automatically generate client code.Since glue code has highly pattern-based characteristics, the engineering world's solution is: first describe API interfaces in a standard format, then use tools to automatically generate client code.

The OpenAPI Specification (formerly Swagger) is the industry standard for describing REST APIs. It uses YAML or JSON format to precisely define API paths, parameters, request bodies, and response structures:The OpenAPI Specification (formerly Swagger) is the industry standard for describing REST APIs. It uses YAML or JSON format to precisely define API paths, parameters, request bodies, and response structures:

yaml 📋 Salin📋 Copy

openapi: 3.0.0 info: title: Email Service API version: 1.0.0 paths: /emails: post: summary: Send email requestBody: content: application/json: schema: type: object properties: to: type: string example: "user@example.com" subject: type: string body: type: string responses: '200': description: Sent successfully

Based on this specification file, tools like openapi-generator can automatically generate client SDKs in multiple languages:Based on this specification file, tools like openapi-generator can automatically generate client SDKs in multiple languages:

• Python: client.emails.send(to="user@example.com", subject="Hi", body="Hello")Python: client.emails.send(to="user@example.com", subject="Hi", body="Hello")
• TypeScript: client.emails.send({ to: "user@example.com", subject: "Hi", body: "Hello" })TypeScript: client.emails.send({ to: "user@example.com", subject: "Hi", body: "Hello" })
• Go: client.Emails.Send(ctx, &SendEmailRequest{To: "user@example.com", ...})Go: client.Emails.Send(ctx, &SendEmailRequest{To: "user@example.com", ...})

The generated SDK encapsulates all HTTP request details; callers don't need to care about URL paths, request methods, serialization formats, or other low-level implementation details.The generated SDK encapsulates all HTTP request details; callers don't need to care about URL paths, request methods, serialization formats, or other low-level implementation details.

5.2 Revisiting Armin's Case5.2 Revisiting Armin's Case

Returning to the case from the beginning of this article, we can now accurately understand each component:Returning to the case from the beginning of this article, we can now accurately understand each component:

Component	Nature	Description
Go	Business logic code	Core functionality implementation of the email service
YAML	Configuration files	Service configuration, CI/CD pipeline definitions, OpenAPI specification files
Pulumi	Infrastructure code	Define cloud resources (servers, databases, networking) using Go/TypeScript
SDK glue code	Auto-generated client libraries	Python and TypeScript SDKs auto-generated from the OpenAPI specification

The YAML configuration, Pulumi resource definitions, and SDK glue code are all highly pattern-based code with clear specification constraints — precisely the areas where AI code generation is most capable. Therefore, "90% of 40,000 lines generated by AI" is entirely reasonable.The YAML configuration, Pulumi resource definitions, and SDK glue code are all highly pattern-based code with clear specification constraints — precisely the areas where AI code generation is most capable. Therefore, "90% of 40,000 lines generated by AI" is entirely reasonable.

------

6. AI and DSL6. AI and DSL

6.1 AI Code Generation Applicability Analysis6.1 AI Code Generation Applicability Analysis

Characteristic Dimension	Suitable for AI Generation	Not Suitable for AI Generation
Pattern level	Highly repetitive, has fixed templates	Requires creative design, no precedent to follow
Specification constraints	Has clear schema or syntax specification	Vague requirements, unclear boundaries
Context dependency	Locally self-consistent, individual definitions don't depend on global understanding	Requires understanding the entire system's architectural intent
Verifiability	Can be automatically validated by tools (e.g., terraform validate)	Can only rely on human judgment of design reasonableness

The four categories of technologies introduced in this article — configuration files, embedded scripts, IaC code, and SDK glue code — all share the characteristics in the left column. This explains why AI's code generation effectiveness in these areas is significantly better than for business logic code.The four categories of technologies introduced in this article — configuration files, embedded scripts, IaC code, and SDK glue code — all share the characteristics in the left column. This explains why AI's code generation effectiveness in these areas is significantly better than for business logic code.

6.2 Evaluation Framework6.2 Evaluation Framework

When judging whether a piece of code is suitable for AI generation, you can reference these three criteria:When judging whether a piece of code is suitable for AI generation, you can reference these three criteria:

1. Is there an existing specification or schema? — If yes, AI-friendlyIs there an existing specification or schema? — If yes, AI-friendly
2. Is it a large number of repeated patterns? — If yes, AI-friendlyIs it a large number of repeated patterns? — If yes, AI-friendly
3. Can the generated result be automatically verified by tools? — If yes, AI-friendlyCan the generated result be automatically verified by tools? — If yes, AI-friendly

Code that satisfies all three criteria (like generating SDKs from OpenAPI specifications, or batch-defining homogeneous resources with Terraform) can heavily rely on AI generation. Code that satisfies none of the criteria (like designing a new distributed consistency protocol) still requires engineers to complete themselves.Code that satisfies all three criteria (like generating SDKs from OpenAPI specifications, or batch-defining homogeneous resources with Terraform) can heavily rely on AI generation. Code that satisfies none of the criteria (like designing a new distributed consistency protocol) still requires engineers to complete themselves.

------

7. Glossary7. Glossary

Term	Full Name	Definition
DSL	Domain-Specific Language	A language designed for a specific domain, contrasted with general-purpose programming languages
GPL	General-Purpose Language	A programming language that can solve arbitrary computational problems, e.g., Python, Java, Go
External DSL	External DSL	A domain-specific language with independent syntax and parser, e.g., SQL, HCL, YAML
Internal DSL	Internal DSL / Embedded DSL	A domain-specific expression built using host language syntax, parasitic within a GPL, e.g., Pulumi
Data Serialization	Data Serialization	The process of converting in-memory data structures into a storable or transmissible format
INI	Initialization	The earliest key-value configuration format, originating from Windows systems
CSV	Comma-Separated Values	A plain text tabular format with comma-separated fields
XML	eXtensible Markup Language	A tag-based text data format with strong expressiveness but verbose syntax
JSON	JavaScript Object Notation	A lightweight key-value-based data exchange format, the de facto standard for Web APIs
YAML	YAML Ain't Markup Language	An indentation-based configuration file format, widely used in backend and DevOps
TOML	Tom's Obvious Minimal Language	An explicit-syntax configuration format, commonly used in Rust and Python ecosystems
Protobuf	Protocol Buffers	A binary serialization format developed by Google, requires pre-defined Schema, small size and fast
MessagePack	—	A JSON-like binary serialization format, no Schema required
Lua	—	A lightweight embedded scripting language, commonly used for game engine, web server, and database extensions
IaC	Infrastructure as Code	The engineering practice of defining and managing cloud computing resources with code
Terraform	—	An IaC tool developed by HashiCorp, using the HCL declarative language
HCL	HashiCorp Configuration Language	The dedicated configuration language used by Terraform
Pulumi	—	An IaC tool supporting general-purpose programming languages
OpenAPI	—	The industry standard specification for describing REST API interfaces (formerly Swagger)
SDK	Software Development Kit	A client library that encapsulates API calling details
Glue Code	Glue Code	Adapter code without business logic, used only to connect two systems

------

SummarySummary

There is a large amount of non-business-logic code in backend engineering. They share a common umbrella concept: DSL (Domain-Specific Language) — languages designed for specific domains, contrasted with general-purpose programming languages.There is a large amount of non-business-logic code in backend engineering. They share a common umbrella concept: DSL (Domain-Specific Language) — languages designed for specific domains, contrasted with general-purpose programming languages.

The DSLs introduced in this article can be categorized into four groups:The DSLs introduced in this article can be categorized into four groups:

1. Data serialization formats (XML / JSON / YAML / TOML / CSV / Protobuf, etc.) — Pure data description external DSLs, converting structured data into storable, transmissible formsData serialization formats (XML / JSON / YAML / TOML / CSV / Protobuf, etc.) — Pure data description external DSLs, converting structured data into storable, transmissible forms
2. Embedded scripting languages (Lua, etc.) — Between configuration and general-purpose languages, providing programmable extension capabilities for host programsEmbedded scripting languages (Lua, etc.) — Between configuration and general-purpose languages, providing programmable extension capabilities for host programs
3. Infrastructure definition languages (HCL / Dockerfile, etc.) — Declarative external DSLs describing the desired system state; Pulumi achieves the same goal as an internal DSLInfrastructure definition languages (HCL / Dockerfile, etc.) — Declarative external DSLs describing the desired system state; Pulumi achieves the same goal as an internal DSL
4. Interface description languages and glue code generation (OpenAPI / .proto) — Automatically generating inter-system connection code through specification descriptionsInterface description languages and glue code generation (OpenAPI / .proto) — Automatically generating inter-system connection code through specification descriptions

Understanding the DSL classification framework enables you to quickly identify the nature of "code that doesn't look like code" in backend projects: which category of DSL it belongs to, what domain problem it solves, and why it isn't written in a general-purpose programming language.Understanding the DSL classification framework enables you to quickly identify the nature of "code that doesn't look like code" in backend projects: which category of DSL it belongs to, what domain problem it solves, and why it isn't written in a general-purpose programming language.

At the same time, because DSL code has the characteristics of being highly pattern-based, specification-driven, and automatically verifiable, it is also the most effective application area for current AI code generation technology.At the same time, because DSL code has the characteristics of being highly pattern-based, specification-driven, and automatically verifiable, it is also the most effective application area for current AI code generation technology.

← SebelumnyaPrevious4-server-and-backend/cross-platform4-server-and-backend/cross-platform SelanjutnyaNext →4-server-and-backend/file-storage4-server-and-backend/file-storage