{"id":19228132,"url":"https://github.com/unit-mesh/unit-mesh","last_synced_at":"2025-05-12T14:29:09.643Z","repository":{"id":148190546,"uuid":"617788189","full_name":"unit-mesh/unit-mesh","owner":"unit-mesh","description":"Unit Mesh is a Asymptotic AI programming architecture pattern. Unit Mesh 是一个基于 AIGC/GenAI 为核心思想的软件架构","archived":false,"fork":false,"pushed_at":"2024-03-06T09:09:34.000Z","size":22764,"stargazers_count":187,"open_issues_count":0,"forks_count":17,"subscribers_count":22,"default_branch":"master","last_synced_at":"2025-05-12T14:29:01.891Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://unitmesh.cc/","language":"Kotlin","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/unit-mesh.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null}},"created_at":"2023-03-23T05:29:38.000Z","updated_at":"2025-04-11T03:00:48.000Z","dependencies_parsed_at":"2023-11-30T03:30:03.265Z","dependency_job_id":"7281e3a1-92fe-4a57-9f8d-80defb233bf7","html_url":"https://github.com/unit-mesh/unit-mesh","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/unit-mesh%2Funit-mesh","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/unit-mesh%2Funit-mesh/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/unit-mesh%2Funit-mesh/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/unit-mesh%2Funit-mesh/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/unit-mesh","download_url":"https://codeload.github.com/unit-mesh/unit-mesh/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253754681,"owners_count":21958893,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-09T15:26:51.619Z","updated_at":"2025-05-12T14:29:09.612Z","avatar_url":"https://github.com/unit-mesh.png","language":"Kotlin","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Unit Mesh: Asymptotic AI programming architecture pattern\n\n\u003e Unit Mesh是一种基于人工智能生成的分布式架构，与传统的分布式架构不同，Unit Mesh 中的服务单元 (Unit) 是由 AI 生成的，应用程序中的服务和数据抽象为一个个独立的单元，并通过统一的控制平面进行管理和部署。\n\n[简体中文版](README.zh_CN.md)\n\n![Unit Mesh](images/unit-mesh-processes.png)\n\n\u003e Unlike traditional distributed architectures, the service units (Units) in Unit Mesh are generated by AI, and the services and data in the application are abstracted into individual units that are managed and deployed through a unified control plane.\n\nPS: The reason why it is called Unit Mesh is because we wrote an underlying service called [UnitServer](https://github.com/prompt-engineering/unit-server), and there are references to Service Mesh and Data Mesh architecture concepts, so AI takes We suggest we call it ****Unit Mesh**** .\n\n## TLDR Version\n\nOur initial definition of this version (0.1, called UnitGenius) has three core features:\n\n- **Language and Framework DSL** (Domain Specific Language) Abstraction: abstracts non-programming language and framework features to simplify the possibility of errors.\n- **REPL as a Service**: runs AI-generated code and provides corresponding API services.\n- **AI Designed Adaptive Architecture**: Self-adaptive API service architecture to automatically adapt and optimize in different environments.\n\nDevelopers can generate a certain level of DSL abstracted code by interacting with AI, and then run and test this code on REPL, the Serverless service. Developers can also submit this code to the AI for automated operations and maintenance, and the AI will optimize and tune the code to further improve the performance and reliability of the API service.\n\nStart with the nonsense version of the text.\n\n## Unit Mesh Preliminary Demo: DSL + REPL = Unit Server\n\nFor a detailed process, see the second half of this article.\n\nFront-end page: [https://prompt.phodal.com/zh-CN/click-flow/unit-mesh-unit-server/](https://prompt.phodal.com/zh-CN/click-flow/unit-mesh-unit-server/)\n\nFirst, you need to clone the code of Unit Server: [https://github.com/prompt-engineering/unit-server](https://github.com/prompt-engineering/unit-server) , then Then, select kotlin-repl or typescript-repl corresponding to both Kotlin and TypeScript languages.\n\nThen, run your Unit Server according to the corresponding README.\n\nNext, have ChatGPT generate the following code in ChatFlow, and click the ``Run`` button:\n\n```jsx\n%spring\n\n@RestController\nobject Pages {\n   @GetMapping(\"/\")\n   fun main() = \"It works!\"\n}\n```\n\nFinally, you get a running service (the feature is still under development): [http://localhost:8080/](http://localhost:8080/hello) and after visiting the service, if's should be It works.\n\n---\n\nPS: Here there is a manual code to call the Application class and call the main method, because we need to do static analysis to determine the framework used, for the time being not written in the Unit Server code.\n\n# Unit Mesh Architecture\n\nRepeat the definition again:\n\n\u003e Unit Mesh is a distributed architecture based on artificial intelligence generation. Unlike traditional distributed architectures, the service units (Units) in Unit Mesh are generated by AI, and the services and data in the application are abstracted into individual units and managed and deployed through a unified control plane.\n\u003e# Unit Mesh\n\n## Unit Mesh core idea: AI-generated code is Unit\n\nUnit Mesh is an architectural pattern centered around units.\n\n- AI generates Units, i.e., the code that AI should generate should be runnable **Unit**, up to React components and down to backend services.\n- Unit verification: Humans check and verify the units, and if there is a problem with the AI-generated code, then humans just need to fix it.\n- Unit adaptive deployment architecture. When deployed, Units can form Serverless architectures, microservices architectures, monolithic architectures, and mesh architectures, without human intervention.\n\nCarbon base is suitable as a Verifier.\n\n## Core Elements of Unit Mesh Architecture\n\nCombined with the Unit Server we designed, the Unit Mesh architecture we designed consists of the following three elements:\n\n![Unit Mesh Elements](images/unit-mesh-elements.png)\n\n### DSL abstraction for languages and frameworks: encapsulating unstable abstractions\n\nSince AI-generated code has various problems, such as inability to interface with internal cloud platforms, erroneous imports, etc., we need to design domain-specific languages to solve this problem and encapsulate abstractions.\n\nIn short: we need to **abstract all unstable elements** to build stable elements.\n\nThe detailed design will be developed later in the Unit Server section.\n\n---\n\nPS: Since the large language model has a contextual capacity limit, like me, I can't get the recharge only with 4k. therefore, I design the Unit to be called 4k Unit Mesh, I design the DSL to be called 4k Unit DSL, some people may be 99k DSL.\n\n### REPL as a Service: AI Code Fixer's\n\nAfter the DSL, we also need a REPL (Read-Eval-Print Loop) service that can directly run up the AI-generated units and then let humans test whether the generated code is correct. If there are errors in the generated AI, an AI code fixer is needed to fix the code.\n\nFor a service, if we are an API, it needs to be a Serverless service, which is why we call it in the diagram: REPL i.e. **Serverless** service. Details can be found later in the design of Unit Server.\n\n### Adaptive Architecture for AI Design\n\nOne of the drawbacks of designing systems by humans is that if the units are not the same at design time, development time, and runtime, then there are all kinds of doubts. So, we would prefer to design into a tri-state consistent architectural pattern, which itself is a problem for the adaptive optimization of the architecture.\n\nSince all code is a Unit, it can be designed as a microservice, developed as a Serverless, or online as a monolith. As Google's Service Waver does, we don't decide on the runtime architecture, we let you choose.\n\nSo, let AI decide how to run our Units.\n\n![Adaptive Architecture](images/adaptive-architecture.png)\n\n---\n\nPS: Originally, the title should have been Adaptive Architecture, but I thought about just the code structure and such, and reconsidered it.\n\n# Unit Mesh Design Insights: Counterintuitive is the way to go\n\nAt the end of last year, when researching low-latency architectures, I was struck by various **counterintuitive** architectural patterns in this field, such as: GC is the problem, then don't GC.\n\nSo when designing Unit Mesh, our question remains the same: **How to open your mind**. So our main challenge is how to **expand your mind** and open your mind**.\n\n### Point 1: If layered architecture is the bottleneck, then don't layered architecture\n\nIn that \"Future-proof AI programming\" layered architecture is our biggest challenge, so the ideal way to propose is the Serverless + FaaS approach, which is based on the existing armament and is too idealistic.\n\nAnd as we wrote UnitServer, we found that we could also Class as a Service approach (manual dog head).\n\nSince our code runs in the cloud and is generated by AI, do humans have to look at the code? When do humans have to look at the code? It's just when they check in, and when they review the architecture, so they only need to generate the architecture when they **review** it.\n\nExample: I want to analyze the calls to xx services and the corresponding code, **please** pull it out for me.\n\n### Point 2: If dependencies are the problem, then don't depend on them\n\nThe second challenge we encounter is the dependency problem, and dependencies are two problems:\n\n- Library dependencies for the project. That is, library dependencies similar to Gradle, Maven, NPM at this level\n- Code dependencies. I.e. `import` of the code source file\n\nRepeater ChatGPT does not solve the problem very well, so you have to let GPT forget about it. The ideal programming experience should be that if I want to use Spring, the intelligence will automatically analyze the dependencies, such as Intelij IDEA. so we use `% spring` like Jupyter magic syntax in UnitServer to automatically solve these two types of problems.\n\n### Point 3: If Serverless deployment is the problem, then don't use Serverless deployment\n\nInitially in Unit Server, we designed Unit Server as a Serverless-like architecture, so we ran into a problem: the cost of a Serverless architecture is not acceptable to all. So, we just need to use Serverless as a development when testing Unit and merge it into a monolithic or microservice architecture online, then we can solve this problem perfectly.\n\nAt this point, we also need to break through the hierarchical architecture, since each time the code is generated, we only need a package name, such as: `org.clickprompt.unitmesh`, all the code is under this package; or, we can further divide the business into different packages, combined with tools to categorize the code.\n\n### Unit Mesh Discovery Path: From REPL to UnitServer\n\nThe above is too theoretical, let's take a look at our exploration path, which is divided into four steps:\n\n1. start with a minimal Hello, world optimization\n2. build a REPL environment\n3. abstract and simplify the design ← repeat. 4.\n4. connect to the real-world Prompt.\n\nSee Unit Server and ChatFlow commit records for details.\n\n### Start with the smallest Hello, world\n\nFirst, let's look at a Hello, World for Spring written in Kotlin Script.\n\n```kotlin\n@file:DependsOn(\"org.springframework.boot:spring-boot-starter-web:2.7.9\")\n\nimport ...\nimport java.util.*\n\n@Controller\nclass HelloController {\n    @GetMapping(\"/hello\")\n    fun helloKotlin(): String {\n        return \"hello world\"\n    }\n}\n\n@SpringBootApplication\nopen class ReplApplication\n\nfun main(args: Array\u003cString\u003e) {\n    ...\n}\n\nmain(arrayOf(\"--server.port=8083\"))\n```\nIn this example, you will find a series of useless code, dependency information, import information, main function. And as the creator of a 4k Unit Mesh, I had to get rid of these unstable useless messages in order to run it correctly, so it became:\n\n```kotlin\n%use spring\n\n@Controller\nclass HelloController {\n    @GetMapping(\"/hello\")\n    fun helloKotlin(): String {\n        return \"hello world\"\n    }\n}\n```\n\nThis way, I just need to get ChatGPT to return the Controller and that's it.\n\n### Building the REPL environment: WebSocket + %magic\n\nNow that we have a simplified DSL, the next step is to bring in Kotlin Script to build a Unit Serverless server, which is what we have: [https://github.com/prompt-engineering/unit-server](https://github.com/prompt-engineering/unit-server).\n\nThe source code of Unit Server is built on the Kotlin Jupyter API, which encapsulates the Kotlin REPL environment. The main reason for basing this on Kotlin Jupyter instead of Kotlin REPL is that magic and DSL can be used to abstract the details, such as in\n\n```kotlin\n\"spring\" to Json.encodeToString(\n    SimpleLibraryDefinition(\n        imports = listOf(\n            \"org.springframework.boot.*\".\n            \"org.springframework.boot.autoconfigure.*\".\n            \"org.springframework.web.bind.annotation.*\".\n            \"ComponentScan\".\n            Configuration\", \"org.springframework.context.annotation.\n        Configuration\").\n        dependencies = listOf(\n            \"org.springframework.boot:spring-boot-starter-web:2.7.9\"\n        )\n    )\n)\n```\n\nThat is, you can automatically add Spring's dependencies and Import information, and you can support the Hello, World approach to the steps. In addition to Spring, we also need magic for other libraries.\n\nFinally, the interface is then exposed using WebSocket to make it available to ChatFlow.\n\n### Abstraction, simplified design ← Loop\n\nOf course, just having a hello, world isn't enough, so we need more examples, such as access to a database. And because of Spring's scanning mechanism, and we don't want to (mostly not) do too much specialization for Spring, we switched to the Kotr framework in Kotlin.\n\nPS: It is worth noting that we still need to abstract the framework, but Ktor is a little better than we expected. So, here comes our second version of\n\n```kotlin\n%use kotless\n%use exposed\n\ndata class User(val id: Int, val username: String)\n\nclass Server : KotlessAWS() {\n    override fun prepare(app: Application) {\n        Database.connect(\"jdbc:h2:mem:test\", driver = \"org.h2.Driver\")\n\n        transaction {\n            SchemaUtils.create(Users)\n        }\n\n        app.routing {\n            post(\"/register\") {\n                val user = call.receive\u003cUser\u003e()\n                val id = transaction {\n                    // Insert the new user into the database\n                    users.insert {\n                        it[username] = user.username\n                    } get Users.id\n                }\n\n                val newUser = User(id, user.username)\n                call.respond(newUser)\n            }\n        }\n    }\n}\n\nobject Users : org.jetbrains.exposed.sql.Table(\"users\") {\n    val id = integer(\"id\").autoIncrement()\n    val username = varchar(\"username\", 50).uniqueIndex()\n\n    override val primaryKey = PrimaryKey(id, name = \"PK_User_ID\")\n}\n```\n\nIn this version, we use Exposed as the ORM for the database, using H2 as the database. Of course, it's still 10% away from taking this code as a Unit, but basically it can solve most of the CRUD scenarios.\n\nPS 1: KotlessAWS here is just an AWS Serverless abstraction, does not affect our operation, we can directly encapsulate a UnitMesh class, is lazy.\n\nPS 2: We just need to take out the code in routing by static analysis, and then optimize it. More code for exploring the process can be found at: [_samples]([https://github.com/prompt-engineering/unit-server/tree/master/kotlin-repl/_samples](https://github.com/prompt-engineering/unit-server/tree/master/kotlin-repl/_samples)).\n\n### A real-world Prompt\n\nNow, let's run it in conjunction with AI: the\n\n``kotlin\nPlease help me implement a RESTful API for user registration using Ktor + Kotlin + Exposed, with the following requirements:\n\n- Where database is involved, please use Database.connect directly.\n- Only return the core logic and write it in Server class, I want to deploy it in Serverless server.\n- Please use Kotlin DSL to write the code.\n- Do not return any other extraneous code such as comments, dependencies, imports, etc.\n\nFinally, you return only the code of the class, in the following format:\n```\n\n```kotlin\nclass Server : KotlessAWS() {\n    override fun prepare(app: Application) {\n        Database.connect(\"jdbc:h2:mem:test\", driver = \"org.h2.Driver\", user = \"root\", password = \"\")\n        transaction {\n            SchemaUtils.create(Users)\n        }\n\n        app.routing {\n            { {{{}}}\n        }\n    }\n}\n```\n\nLife is short, welcome to join our Watchlist and discuss the future together.\n\n## Join Waitlist\n\nRight now **Waitlist engineers**, you can join Unit Mesh's Watchlist at:\n\n[https://github.com/prompt-engineering/unit-mesh](https://github.com/prompt-engineering/unit-mesh)\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Funit-mesh%2Funit-mesh","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Funit-mesh%2Funit-mesh","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Funit-mesh%2Funit-mesh/lists"}