Multi-language fusion application development system and application construction method based on gRPC

Abstract

The invention discloses a gRPC-based multi-language fusion application development system and an application construction method, and belongs to the field of computer software development. The system comprises a visual design and DSL generation unit, a JS / JS + + engine unit, a Go middle table service engine unit, a multi-language service adaptation unit, an integrated infrastructure unit, a protocol and code generation unit and a cross-platform application packaging unit. Through a calling link of JS / JS + +-Go middle station-multi-language service, a component expansion mechanism and an open interface are matched, a local component or remote service can be dynamically integrated into an application in a gRPC mode, and ecological butt joint with third-party applications such as a browser and a fingerprint browser is supported. Unified packaging of multi-language service capacity, infrastructure capacity and interface logic capacity is achieved, the development threshold of multi-language fusion application is remarkably lowered, and expansibility and maintainability of the system are improved.

Description

Technical Field

[0001] This invention relates to computer software development, and more particularly to a multi-language integrated application development system and application construction method based on gRPC. Background Technology

[0002] Traditional desktop development tools, represented by native development languages ​​such as "Easy Language," typically encapsulate the language, runtime, and integrated development environment (IDE) within a closed-loop system, providing a degree of "what you see is what you get" development experience for non-professional developers. However, these tools suffer from the following technical limitations: 1. Relatively closed languages ​​and ecosystems, making it difficult to directly interface with mainstream languages ​​and their libraries such as Go, Python, Node.js, Java, and C++; 2. Insufficient support for modern technologies such as cloud-native architecture, distributed services, and microservice governance; 3. Limited cross-platform support, making it difficult to simultaneously cover desktop, mobile, and web platforms; 4. Weak support for big data processing, artificial intelligence inference, and complex backend service orchestration; 5. Inability to fully leverage the advantages of different languages ​​in high concurrency, low-level control, big data, and the web ecosystem within a unified system.

[0003] In practical engineering, to achieve collaboration and interoperability between different programming languages, a hybrid integration of multiple methods is typically used, including JNI, FFI, local process communication, REST / SOAP, and message queues. These methods generally suffer from the following problems: 1. High integration cost: Developers need to understand multiple technology stacks and communication mechanisms; 2. High code invasiveness: A large amount of bridging and adaptation logic needs to be explicitly written in the business code; 3. Poor maintainability: Multiple protocols and implementations coexist, making upgrades and debugging difficult; 4. Inconvenient for non-professional developers: The overall system complexity is high, and it is difficult to achieve unified encapsulation through visualization or simplified scripts.

[0004] gRPC, a high-performance remote procedure call framework based on HTTP / 2 and Protocol Buffers, boasts advantages such as strongly typed interfaces, efficient serialization, and multi-language support, making it a crucial infrastructure in cloud-native and microservice architectures. However, in typical use cases: it requires manually defining and maintaining .proto files; generating and writing corresponding code for both the server and client sides; browser-side gRPC-Web adaptation is typically required, leading to complex configuration and deployment; and for users who wish to build local applications in a "low-code" or "scripting language-like" manner, the learning curve remains relatively steep.

[0005] Currently, there is a lack of a multi-language integrated development engine that uses gRPC as the unified communication protocol, Go as the local middleware engine, integrates lightweight message queues, embedded databases, key-value caching, and file systems, and encapsulates these capabilities into a unified development experience through JavaScript / JS++ and a visual DSL. Specifically, it lacks an engine that: can: unify multiple gRPC-based multi-language service processes locally, with unified discovery, authentication, and scheduling by the middleware platform; can describe business logic through JS / JS++ scripts or visual processes without needing to know the underlying service type and deployment location (local or remote); can integrate lightweight message queues, databases, caching, and file system capabilities within the engine and expose them externally through a unified script interface; can support extending upload components according to specified formats and dynamically integrate them as local or remote gRPC services; and can easily connect to third-party application ecosystems such as browsers and fingerprint browsers through open interfaces, forming a sustainable and evolving application ecosystem. Summary of the Invention

[0006] Purpose of the invention: The purpose of this invention is to provide a multi-language integrated application development system and application construction method based on gRPC, aiming to overcome the shortcomings of existing technologies such as complex multi-language integration, high threshold for using gRPC, dispersed infrastructure capabilities, and unfriendly to non-professional developers.

[0007] Technical solution: A multi-language integrated application development system based on gRPC, including:

[0008] The Visual Design and DSL Generation Unit is used to receive user design input regarding user interface, business process, and service call relationships through a graphical interface, and generate a domain-specific language DSL that describes the design input.

[0009] The JS / JS++ engine unit, implemented in Go, is used to convert DSLs into JavaScript / JS++ scripts and interpret and execute them, and expose a unified application interface to the scripts for accessing services and infrastructure capabilities.

[0010] The Go middleware service engine unit, implemented in Go, is used to receive call requests from the JS / JS++ engine unit, perform service registration and discovery, authentication and authorization, request routing and load balancing, and forward the call requests to the target service in the multi-language service adaptation unit via the gRPC protocol.

[0011] The multi-language service adaptation unit is used to carry one or more business services implemented in at least one of the programming languages ​​Go, Python, Node.js, Java, and C++. Each business service provides a gRPC interface to the outside world according to a unified .proto protocol buffer file definition, and registers the service with the Go middleware service engine unit at startup.

[0012] The integrated infrastructure unit is deployed in conjunction with the Go middleware service engine unit to provide lightweight message queue capabilities, embedded relational database capabilities, key-value storage capabilities, and file system capabilities, and provides a unified interface for the JS / JS++ engine unit and multi-language service adaptation unit to call.

[0013] The protocol and code generation unit is used to automatically generate .proto protocol buffer files, multi-language server skeleton code, and front-end software development kits (SDKs) that encapsulate gRPC call details based on DSLs or JavaScript / JS++ scripts.

[0014] The component extension and registration unit is used to receive component packages that conform to the preset component format, parse the component metadata, and integrate the services corresponding to the components into the service registry of the Go middleware service engine unit by means of local gRPC registration or remote gRPC registration.

[0015] The cross-platform application packaging unit is used to embed the front-end interface, JS / JS++ engine unit, and front-end SDK into the cross-platform runtime environment, and package them together with the Go middleware service engine unit and multi-language service adaptation unit to generate an application that can run on desktop or mobile terminals.

[0016] Furthermore, the JS / JS++ engine unit embeds a JavaScript engine and extends the standard JavaScript syntax to form the JS++ language, which provides:

[0017] Syntax or built-in APIs for declaratively defining service calls, enabling business scripts to directly call gRPC services using simplified syntax;

[0018] The automatic bidirectional conversion capability between DSL and DSL allows users to define business logic through visual or script-based methods.

[0019] Furthermore, the integrated infrastructure units include:

[0020] The lightweight message queue subunit is used to implement publish / subscribe messages, delayed messages, and task queues;

[0021] An embedded relational database subunit used to store structured data as local files;

[0022] The key-value storage subunit is used to provide key-value caching capabilities and supports most commonly used commands in Redis standalone mode;

[0023] The file system subunit is used to provide server-like file storage and management capabilities, supporting directory-based storage and access control for massive amounts of files.

[0024] Furthermore, the component extension and registration unit receives component packages including component metadata description files, front-end resource files, and service definition files. The component extension and registration unit determines the component type based on the metadata description files and automatically completes component deployment and gRPC registration.

[0025] Furthermore, the system also includes a third-party application integration interface unit, used for:

[0026] Establish a control connection with a browser or fingerprint browser to automate operations such as opening pages, logging in to accounts, and filling out forms.

[0027] The aforementioned control capabilities are encapsulated into service interfaces that can be called in DSL and JavaScript / JS++ to enable the construction of operational functions for third-party applications.

[0028] A method for building a multi-language integrated application based on gRPC includes the following steps:

[0029] S1. Receive user input on interface layout, business process, and service call relationship design through the visual design and DSL generation unit, and generate DSL;

[0030] S2. Convert the DSL into a JavaScript / JS++ script, which is then loaded, interpreted, and executed by the JS / JS++ engine unit;

[0031] S3: The protocol and code generation unit parses DSL or JavaScript / JS++ scripts and automatically generates .proto protocol buffer files, multi-language server skeleton code, and front-end SDK;

[0032] S4. Implement and deploy the corresponding business services to the multi-language service adaptation unit based on the multi-language server skeleton code, and register the business services with the Go middleware service engine unit.

[0033] S5. During application operation, when a user triggers an event on the front-end interface, the JavaScript / JS++ script calls the encapsulated function in the front-end SDK, and the JS / JS++ engine unit sends the call request to the Go middleware service engine unit.

[0034] The S6 and Go middleware service engine units authenticate and authorize call requests, discover services based on service registration information, and forward call requests to the corresponding target business services via the gRPC protocol.

[0035] S7. The target business service executes business logic, and if necessary, calls the message queue, database, key-value store or file system capabilities provided by the integration infrastructure unit to generate response results and return them to the Go middleware service engine unit.

[0036] The S8 and Go middleware service engine units return the response results to the front-end SDK and JavaScript / JS++ scripts to drive interface updates and subsequent processes.

[0037] Furthermore, the multilingual server skeleton code generated in step S3 includes dependency injection, configuration management, and logging structures, so that developers can fill in business logic without modifying the basic structure, achieving enterprise-level maintainability.

[0038] The development platform based on the above systems and methods allows users to develop a cross-platform application ecosystem with rich interfaces and complex backend logic by understanding only the business logic and process control, without needing to understand the details of gRPC protocol, database driver, message queue implementation and file system implementation.

[0039] Beneficial effects:

[0040] (1) This invention uses gRPC as the unified communication protocol and integrates the capabilities of languages ​​such as Go, Python, Node.js, Java, and C++ through the Go platform to achieve true multi-language collaboration.

[0041] (2) The present invention integrates a lightweight message queue, an embedded database, a key-value cache and a file system inside the engine, avoiding developers from deploying and managing multiple middleware separately.

[0042] (3) By visualizing the DSL process and using JS / JS++ scripts, the underlying details such as gRPC, database drivers, message queues, and file systems are shielded, enabling non-professional developers to quickly build complex applications.

[0043] (4) By specifying the component format and gRPC registration mechanism, it supports the dynamic expansion of local components and remote services, and new functional modules can be introduced as needed.

[0044] (5) Through open interfaces, third-party applications such as browsers and fingerprint browsers can be accessed to realize upper-level business such as automated operation, batch control, and multi-account management.

[0045] (6) Through cross-platform packaging units, desktop, mobile and web applications can be generated without changing the business scripts. Attached Figure Description

[0046] Figure 1 This is a schematic diagram of the system architecture;

[0047] Figure 2 This is a schematic diagram illustrating the specific process of user login and business processing implemented based on the present invention. Detailed Implementation

[0048] To make the technical solution of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0049] like Figure 1 As shown, the gRPC-based multi-language integrated application development system includes: a visual design and DSL generation unit 10; a JS / JS++ engine unit 20; a Go middleware service engine unit 30; a multi-language service adaptation unit 40; an integration infrastructure unit 50; a protocol and code generation unit 60; a component extension and registration unit 70; a cross-platform application packaging unit 80; and a third-party application integration interface unit 90. Specifically, the visual design and DSL generation unit 10, located in the front-end development interface layer, is used to generate DSL descriptions; the JS / JS++ engine unit 20 is responsible for interpreting and executing JS / JS++ scripts; the Go middleware service engine unit 30 serves as a unified gateway and scheduling center; the multi-language service adaptation unit 40 carries business capabilities; the integration infrastructure unit 50 provides message queue, database, caching, and file system capabilities; the protocol and code generation unit 60 is responsible for automatically generating protocols and skeleton code; the component extension and registration unit 70 enables pluggable extension of functional modules; the cross-platform application packaging unit 80 outputs the final installable and runnable application; and the third-party application integration interface unit 90 is used for interfacing with browsers, fingerprint browsers, and other external systems.

[0050] The Visual Design and DSL Generation Unit 10 provides a component panel, property panel, event panel, and process orchestration canvas, allowing users to complete interface layout and business process design by dragging and dropping.

[0051] In a typical embodiment, a DSL can be represented using YAML, JSON, or a custom markup language, and its structure includes:

[0052] 1. UI Part: Define the page, component tree, and component properties;

[0053] 2. Process Section: Define process control nodes such as events, conditional branches, loops, and parallelism;

[0054] 3. Service section: Define the service identifier, input parameters, output parameters, and invocation method.

[0055] Example DSL:

[0056] services:

[0057] UserService:

[0058] rpc:

[0059] Login:

[0060] request: [username, password]

[0061] response: [success, token]

[0062] ui:

[0063] components:

[0064] - type: Input

[0065] id: username_input

[0066] - type: Input

[0067] id: password_input

[0068] props:

[0069] type: password

[0070] - type: Button

[0071] id: login_btn

[0072] onClick:callService('UserService.Login',[username_input.value,password_input.value])

[0073] The DSL can be parsed by the protocol and code generation unit 60, which generates .proto files and multilingual service skeletons on the one hand, and equivalent JS / JS++ scripts on the other.

[0074] Unit 20, the JS / JS++ Engine, is implemented in Go and embeds a JavaScript engine (such as V8 or QuickJS) that extends standard JavaScript syntax to form the JS++ language. The main functions of this unit are:

[0075] 1. Interpret and execute JS / JS++ scripts generated by the DSL;

[0076] 2. Expose a unified API to scripts, including namespaces such as ui, api, mq, db, cache, and fs;

[0077] 3. Encapsulate the service call instructions in the script into a unified gateway request and send it to the Go middleware service engine unit 30.

[0078] Example JS++ script:

[0079] async function onLoginClick() {

[0080] const username = ui.get('username_input').value;

[0081] const password = ui.get('password_input').value;

[0082] const resp = await api.user.login({ username, password});

[0083] if (resp.success) {

[0084] / / Write the token to the cache

[0085] cache.set('auth_token', resp.token);

[0086] ui.showToast('Login successful');

[0087] } else {

[0088] ui.showToast('Login failed');

[0089] }

[0090] }

[0091] ui.bind('login_btn', 'click', onLoginClick)

[0092] Among them, api.user.login is provided by the front-end SDK and communicates with the Go middleware service engine unit 30 through the gRPC client inside the JS / JS++ engine; the cache namespace is mapped to the key-value storage sub-unit interface in the integration infrastructure unit 50.

[0093] Go middleware service engine unit 30 is one of the core modules of this invention. It is implemented in Go language and its main functions include:

[0094] 1. Unified gRPC Gateway: Receives and distributes call requests from JS / JS++ engine unit 20 and front-end SDK;

[0095] 2. Service Registration and Discovery: Maintain the registration information of each service in the multilingual service adaptation unit 40;

[0096] 3. Authentication and Authorization: Perform access control based on the caller's identity, token, access policy, etc.

[0097] 4. Routing and Load Balancing: Routes requests to the appropriate service instance based on service name, version number, tag, etc.

[0098] 5. Interaction with integrated infrastructure unit 50: Provides capabilities such as message writing, database access, cache read / write, and file operations.

[0099] Its example pseudocode can be represented as follows:

[0100] type GatewayServer struct {

[0101] registry ServiceRegistry

[0102] auth AuthManager

[0103] infra InfraProvider / / Encapsulates MQ, DB, Cache, FS

[0104] }

[0105] func (g *GatewayServer) Call(ctx context.Context, req *pb.GatewayRequest) (*pb.GatewayResponse, error) {

[0106] / / 1. Authentication

[0107] if err := g.auth.Check(ctx, req.Token, req.Service, req.Method);err != nil {

[0108] return nil, status.Error(codes.PermissionDenied, "unauthorized")

[0109] }

[0110] / / 2. Service Discovery

[0111] target, err := g.registry.Resolve(req.Service)

[0112] if err != nil {

[0113] return nil, status.Error(codes.Unavailable, "service notfound")

[0114] }

[0115] / / 3. Forwarding the call

[0116] client := NewGenericGrpcClient(target.Address)

[0117] return client.Invoke(ctx, req)

[0118] }

[0119] In practice, advanced governance capabilities such as service grouping, canary releases, rate limiting, and circuit breaking can be implemented through configuration.

[0120] The integrated infrastructure unit 50 is embedded within or tightly coupled to the Go middleware service engine unit 30, and includes at least the following sub-units:

[0121] 1. Lightweight message queue subunit 51, which provides capabilities such as publish / subscribe, delayed queues, and simple task queues, and can be implemented based on memory queues or embedded persistence mechanisms;

[0122] 2. An embedded relational database subunit 52, used to provide structured data storage capabilities, may be implemented based on SQLite in one embodiment;

[0123] 3. Key-value storage subunit 53 is used to provide high-performance key-value caching capabilities. In one embodiment, it can be based on miniredis or an equivalent implementation, supporting most commonly used commands in a Redis single-machine scenario.

[0124] 4. File system subunit 54 is used to provide file read, write and management capabilities similar to a server file system, support the storage of massive files based on a directory structure, and provide mechanisms such as access control and quota management.

[0125] The integration infrastructure unit 50 exposes a unified API through the JS / JS++ engine unit 20, for example:

[0126] / / Using message queues in JS++

[0127] mq.publish('order_created', { orderId, amount});

[0128] / / Using databases in JS++

[0129] const user = await db.queryOne('SELECT * FROM users WHERE id = ?',[userId]);

[0130] / / Using caching in JS++

[0131] cache.set('session:' + userId, sessionData, { expireSeconds: 3600});

[0132] / / Using the file system in JS++

[0133] await fs.writeFile(' / user_data / ' + userId + ' / profile.json',JSON.stringify(profile))

[0134] Through the above encapsulation, business scripts do not need to know whether SQLite, miniredis or other implementations are used. They only need to call through a unified abstract interface, thereby further reducing the development threshold.

[0135] The multilingual service adaptation unit 40 includes multiple services implemented according to a unified .proto definition, which can run on local processes or remote servers.

[0136] In a typical embodiment, it may include:

[0137] A high-concurrency gateway service implemented in Go;

[0138] Big data analytics and AI model inference services implemented in Python;

[0139] Third-party platform API integration service implemented based on Node.js;

[0140] Complex business rule engines or enterprise-level business systems implemented in Java;

[0141] High-performance computing or low-level device control services implemented in C++.

[0142] Each service registers its service name, version number, address, and other information with the Go middleware service engine unit 30 when it starts up.

[0143] The component extension and registration unit 70 is used to support on-demand extension of system functions.

[0144] In one embodiment, the component can adopt a pre-defined packaging format (e.g., a compressed package containing metadata description files, front-end resources, back-end service definitions, and deployment scripts). After the developer uploads the component package to the engine, the system automatically completes the following steps:

[0145] 1. Parse component metadata to determine component type (UI component, service component, operation component, etc.) and its dependencies;

[0146] 2. For service components, generate or load the corresponding gRPC service definition based on the description file, and deploy the corresponding service process locally or remotely;

[0147] 3. Mount the local component service to the Go middleware service engine unit 30 via local gRPC registration;

[0148] 4. For components located on a remote server, register their address and access credentials via remote gRPC registration;

[0149] 5. Expose components as services or UI controls that can be directly referenced in the DSL and JS / JS++.

[0150] Through this mechanism, components can be integrated either as local gRPC services or as remote services, thus forming a loosely coupled and scalable component ecosystem.

[0151] The third-party application integration interface unit 90 provides unified access capabilities for browsers, fingerprint browsers, and other external applications.

[0152] In one embodiment, this can be achieved as follows:

[0153] 1. Provides a control interface based on local HTTP / WebSocket, allowing engine scripts to drive the browser to perform operations such as opening pages, logging in, and filling out forms;

[0154] 2. Integrate with the fingerprint browser's automated control interface to achieve automated operation across multiple accounts and environments;

[0155] 3. Package the above control capabilities into a JS / JS++ API so that business scripts can control the behavior of external browsers in the form of "calling services".

[0156] Example

[0157] The following uses the "user login and data query" scenario as an example to illustrate the complete process of building an application based on the system of this invention, such as... Figure 2 As shown.

[0158] 1. Users drag and drop login interface components and configure related events in the visual designer, and the system generates a DSL;

[0159] 2. The DSL is converted into a JS / JS++ script and loaded by the JS / JS++ engine unit 20;

[0160] 3. The protocol and code generation unit 60 generates user.proto and UserService skeleton code in languages ​​such as Go / Python based on the DSL;

[0161] 4. Developers fill in the authentication logic in the skeleton code, compile and deploy it to the multi-language service adaptation unit 40;

[0162] 5. UserService registers with Go middleware service engine unit 30 when it starts;

[0163] 6. When the application is running, the user enters their username and password on the login screen, triggering a login event;

[0164] 7. When JS++ calls api.user.login, the front-end SDK encapsulates it as a gRPC request and sends it to the Go middleware platform;

[0165] 8. After completing authentication and service discovery, the Go middleware will forward the request to UserService;

[0166] 9. UserService calls the embedded database subunit 52 in the integrated infrastructure unit 50 to query user information and returns the login result;

[0167] 10. JS++ determines the subsequent interface redirection or error message based on the returned result.

[0168] In more complex scenarios, business scripts can also utilize message queues, caching, and file system capabilities simultaneously, and connect to external services or browsers through component extension mechanisms to achieve fully automated business processes.

[0169] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A gRPC-based multi-language fusion application development system, characterized in that, include: The Visual Design and DSL Generation Unit is used to receive user design input regarding user interface, business process, and service call relationships through a graphical interface, and generate a domain-specific language DSL that describes the design input. The JS / JS++ engine unit, implemented in Go, is used to convert DSLs into JavaScript / JS++ scripts and interpret and execute them, and expose a unified application interface to the scripts for accessing services and infrastructure capabilities. The Go middleware service engine unit, implemented in Go, is used to receive call requests from the JS / JS++ engine unit, perform service registration and discovery, authentication and authorization, request routing and load balancing, and forward the call requests to the target service in the multi-language service adaptation unit via the gRPC protocol. The multi-language service adaptation unit is used to carry one or more business services implemented based on Go, Python, Node.js, Java, and C++ programming languages. Each business service provides a gRPC interface to the outside world according to a unified .proto protocol buffer file definition, and registers the service with the Go middleware service engine unit at startup. The integrated infrastructure unit is deployed in conjunction with the Go middleware service engine unit to provide lightweight message queue capabilities, embedded relational database capabilities, key-value storage capabilities, and file system capabilities, and provides a unified interface for the JS / JS++ engine unit and multi-language service adaptation unit to call. The protocol and code generation unit is used to automatically generate .proto protocol buffer files, multi-language server skeleton code, and front-end software development kits (SDKs) that encapsulate gRPC call details based on DSLs or JavaScript / JS++ scripts. The component extension and registration unit is used to receive component packages that conform to the preset component format, parse the component metadata, and integrate the services corresponding to the components into the service registry of the Go middleware service engine unit by means of local gRPC registration or remote gRPC registration. The cross-platform application packaging unit is used to embed the front-end interface, JS / JS++ engine unit, and front-end SDK into the cross-platform runtime environment, and package them together with the Go middleware service engine unit and multi-language service adaptation unit to generate an application that can run on desktop or mobile terminals. 2.The gRPC-based polyglot fusion application development system according to claim 1, wherein, The JS / JS++ engine unit embeds a JavaScript engine and extends the standard JavaScript syntax to form the JS++ language, which provides: Syntax or built-in APIs for declaratively defining service calls, enabling business scripts to directly call gRPC services using simplified syntax; The automatic bidirectional conversion capability between DSL and DSL allows users to define business logic through visual or script-based methods.

3. The multi-language integrated application development system based on gRPC according to claim 1, characterized in that, The integrated infrastructure unit includes: The lightweight message queue subunit is used to implement publish / subscribe messages, delayed messages, and task queues; An embedded relational database subunit used to store structured data as local files; The key-value storage subunit is used to provide key-value caching capabilities and supports most commonly used commands in Redis standalone mode; The file system subunit is used to provide server-like file storage and management capabilities, supporting directory-based storage and access control for massive amounts of files. 4.The gRPC-based polyglot fusion application development system of claim 1, wherein, The component extension and registration unit receives component packages including component metadata description files, front-end resource files, and service definition files. The component extension and registration unit determines the component type based on the metadata description files and automatically completes component deployment and gRPC registration. 5.The gRPC-based polyglot fusion application development system of claim 1, wherein, It also includes a third-party application integration interface unit, used for: Establish a control connection with a browser or fingerprint browser to automate operations such as opening pages, logging in to accounts, and filling out forms. The aforementioned control capabilities are encapsulated into service interfaces that can be called in DSL and JavaScript / JS++ to enable the construction of operational functions for third-party applications. 6.A method for constructing a multi-language fusion application based on gRPC, characterized in that, Includes the following steps: S1. Receive user input on interface layout, business process, and service call relationship design through the visual design and DSL generation unit, and generate DSL; S2. Convert the DSL into a JavaScript / JS++ script, which is then loaded, interpreted, and executed by the JS / JS++ engine unit; S3: The protocol and code generation unit parses DSL or JavaScript / JS++ scripts and automatically generates .proto protocol buffer files, multi-language server skeleton code, and front-end SDK; S4. Implement and deploy the corresponding business services to the multi-language service adaptation unit based on the multi-language server skeleton code, and register the business services with the Go middleware service engine unit. S5. During application operation, when a user triggers an event on the front-end interface, the JavaScript / JS++ script calls the encapsulated function in the front-end SDK, and the JS / JS++ engine unit sends the call request to the Go middleware service engine unit. The S6 and Go middleware service engine units authenticate and authorize call requests, discover services based on service registration information, and forward call requests to the corresponding target business services via the gRPC protocol. S7. The target business service executes business logic, and if necessary, calls the message queue, database, key-value store or file system capabilities provided by the integration infrastructure unit to generate response results and return them to the Go middleware service engine unit. The S8 and Go middleware service engine units return the response results to the front-end SDK and JavaScript / JS++ scripts to drive interface updates and subsequent processes. 7.The method of Claim 6, wherein the gRPC-based polyglot fusion application is constructed by, The multilingual server skeleton code generated in step S3 includes dependency injection, configuration management, and logging structures.

Images