Method and device for realizing front-end full stack through Cell JS, program product and storage medium

Abstract

The invention discloses a method and equipment for realizing a front-end full stack through CellJS, a program product and a storage medium, and relates to the technical field of Web application development. The method comprises the following steps: defining a plurality of service interfaces, and generating a metadata file according to each service interface; when the back-end module is started, the back-end module loads the metadata file to obtain a data set containing mapping information of the service interface and the service method; constructing an authentication and authorization module according to the data set; generating a front-end client class corresponding to each service interface; when a user triggers a login operation on the front-end interface, the front-end module sends the login operation to the corresponding rear-end module, and generates an access token according to the authentication and authorization module and the front-end client class; when the front-end module initiates business service calling, the rear-end module performs permission verification according to the access token to obtain a verification result; and performing service processing according to a verification result, and returning a service processing result to the front-end module. By implementing the technical scheme provided by the invention, the development complexity of the full-stack application can be reduced.

Description

Methods, devices, program products, and storage media for implementing a full-stack front-end using CellJS Technical Field

[0001] This application relates to the technical field of web application development, and specifically to a method, device, program product, and storage medium for implementing a full-stack front-end using CellJS. Background Technology

[0002] In modern web application development, full-stack development typically adopts a front-end and back-end separation architecture. The front-end uses JavaScript or TypeScript to build the user interface and interaction logic, while the back-end uses languages ​​such as Java, Python, and Node.js to define API interfaces, handle HTTP requests, implement error handling mechanisms, and ensure type safety.

[0003] In traditional full-stack development, front-end components and back-end services are developed and maintained independently. Front-end developers need to manually write HTTP client code to call back-end APIs, including constructing request parameters, parsing response data, and handling error states. Back-end developers, on the other hand, need to implement API routing definitions, request validation, business logic processing, data serialization, and user authentication and authorization modules in different programming language environments.

[0004] However, the aforementioned traditional technical solutions suffer from a large development workload. The front-end and back-end need to implement their respective API call logic and service processing logic, requiring developers to switch between different technology stacks and maintain multiple codebases, increasing the development complexity of full-stack applications. Summary of the Invention

[0005] This application provides a method, device, program product, and storage medium for implementing a full-stack front-end using CellJS, which can reduce the development complexity of full-stack applications.

[0006] The first aspect of this application provides a method for implementing a full-stack front-end using CellJS, specifically including: defining multiple service interfaces in a common directory shared by the front-end module and the back-end module, and generating metadata files based on each service interface; when the serverless function container of the back-end module performs a cold start, the back-end module loads the metadata files to obtain a first data set containing service interface and service method mapping information; constructing an authentication and authorization module based on the first data set, the authentication and authorization module being used for token management and access control; generating front-end client classes corresponding to each service interface based on each service interface and the metadata files; when a user triggers a login operation on the front-end interface, the front-end module sends the login operation to the corresponding back-end module, and generates an access token based on the authentication and authorization module and the front-end client classes; when the front-end module initiates a business service call, the back-end module performs permission verification based on the access token to obtain a verification result; performing business processing based on the verification result, and returning the business processing result to the front-end module.

[0007] By adopting the above technical solution, and uniformly defining service interfaces and generating metadata files in a shared public directory for both front-end and back-end modules, consistent management of front-end and back-end interfaces is achieved, avoiding the problem of repeatedly developing interface definitions across different technology stacks in traditional solutions. During cold starts, the back-end module can automatically load the metadata file to obtain the mapping relationship between service interfaces and methods, and build an authentication and authorization module accordingly, making permission management more unified and standardized. Simultaneously, front-end client classes are automatically generated based on service interfaces and metadata files, reducing the workload of manually writing HTTP call code. When a user triggers a login operation, the front-end module can directly interact with the back-end module through the generated client class to obtain an access token; in subsequent business calls, the back-end module can perform unified permission verification based on the access token and complete the corresponding business processing. This CellJS-based full-stack front-end implementation solution reduces the development complexity of full-stack applications through unified interface definitions, automated code generation, and a standardized authentication and authorization mechanism.

[0008] Optionally, the step of constructing the authentication and authorization module based on the first data set includes: scanning service implementation classes with remote call markers, matching and verifying the service implementation classes with service interfaces in the first data set, and generating mapping relationship data; creating a dependency injection container based on the mapping relationship data, and registering the service implementation classes into the dependency injection container according to the corresponding service interfaces; creating a configuration management service instance based on the dependency injection container, performing integrity verification on the configuration management service instance, and using the verified configuration management service instance as a configuration item set; and constructing the authentication and authorization module based on the dependency injection container and the configuration item set.

[0009] By adopting the above technical solution, service implementation classes marked with remote call tags are scanned and matched with service interfaces in the first data set to ensure consistency between service implementations and interface definitions. By creating a dependency injection container based on mapping relationship data and registering service implementation classes according to service interfaces, automatic assembly and lifecycle management of service components are achieved. By creating configuration management service instances and performing integrity checks, the correctness and completeness of configuration items are guaranteed. Finally, an authentication and authorization module is built based on the dependency injection container and configuration item set, forming a clear and maintainable service architecture. This dependency injection-based service management solution improves system scalability and maintainability while ensuring the correctness of service implementations and simplifies the configuration and management process of service components.

[0010] Optionally, when a user triggers a login operation on the front-end interface, the front-end module sends the login operation to the corresponding back-end module and generates an access token based on the authentication and authorization module and the front-end client class. This includes: when the user triggers a login operation on the front-end interface, obtaining the authorization code sent by the front-end module, constructing a network request message based on the authorization code and the front-end client class, and sending it to the corresponding back-end module; the back-end module parses the route identifier from the network request message, obtains an authentication service instance from the dependency injection container based on the route identifier, and generates an access token based on the authentication service instance and the authentication and authorization module.

[0011] By adopting the above technical solution, the front-end module constructs network request messages based on the authorization code and the front-end client class, realizing a standardized authentication request format; the back-end module accurately locates the authentication service instance through routing identifiers, ensuring the accuracy of authentication processing; simultaneously, it generates access tokens using the authentication service instance and the authentication authorization module, ensuring the security and standardization of the tokens. This authorization code-based identity authentication scheme, while ensuring the security and reliability of the authentication process, achieves type security of authentication requests and precise matching of service instances through the front-end client class and dependency injection container, improving the reliability and maintainability of the identity authentication process.

[0012] Optionally, the authentication and authorization module includes an external authentication client submodule and a token processing submodule. Generating an access token based on the authentication service instance and the authentication and authorization module includes: obtaining a first access token from an external authentication server using the authorization code through the external authentication client submodule based on the authentication service instance; obtaining a user identifier using the first access token based on the authentication service instance; and reading a set of roles associated with the user identifier from the permission storage based on the user identifier. The token processing submodule writes the user identifier and the set of roles into a JSON Web Token payload, generates a second access token using the token signing key provided by the configuration management service instance, and encapsulates the second access token as login response data and returns it to the frontend module.

[0013] By adopting the above technical solution, the OAuth2.0 authentication process of the external authentication server is organically combined with the internal JWT token mechanism. The external authentication client submodule achieves standardized integration with the third-party authentication server, ensuring the reliability of identity authentication. By reading user role information from the permission storage and writing the user identifier and role set into the JWT payload, unified management of user identity and permission information is achieved. The JWT is signed using the signing key provided by the configuration management service instance, ensuring the token's immutability and security. This hybrid authentication scheme based on OAuth2.0 and JWT leverages the mature authentication mechanism of the external authentication server while implementing lightweight local token verification through JWT. This improves system performance while ensuring authentication security and provides foundational support for subsequent fine-grained access control.

[0014] Optionally, when the front-end module initiates a business service call, the back-end module performs permission verification based on the access token to obtain a verification result, including: when the front-end module initiates a business service call, the front-end module parses and stores the second access token from the login response data; constructs a business request data object according to the request data type of the business service interface corresponding to the business service, and sends the second access token to the header of the business network request message of the business request data object through the front-end client class corresponding to the business service interface; the back-end module uses the verification key in the configuration management service instance to perform signature verification and validity period verification on the second access token through the token processing submodule to obtain a verification result.

[0015] By adopting the above technical solution, the front-end module standardizes the storage and use of JWT tokens, ensuring the identity of each business call. The front-end client class encapsulates the business request data object according to the type specification defined in the interface and attaches a JWT token, achieving type security and identity association for the request data. The back-end module uses the token processing submodule to perform signature verification and validity period checks using a verification key, ensuring the legitimacy and timeliness of the business request. This JWT-based request authentication scheme, by implementing unified processing of request data type checking and identity verification during business calls, not only ensures the security of business calls but also provides complete type constraints, improving system reliability and development efficiency.

[0016] Optionally, the step of performing business processing based on the verification result and returning the business processing result to the front-end module includes: when the verification result is successful, parsing the user identifier and the current role set from the payload of the second access token; constructing a remote procedure call routing table based on the routing identifier in the first data set and the current role set; searching for the role set required by the business network request message in the remote procedure call routing table based on the business routing identifier in the business network request message; comparing the current role set with the required role set to obtain the business processing result; obtaining the corresponding business service instance from the dependency injection container based on the business processing result; deserializing the request body of the business network request message into a business data object that matches the corresponding request data type in the public directory; obtaining a business processing result data object based on the business data object and the business service instance; and serializing the business processing result data object according to the corresponding response data type and returning it to the front-end module.

[0017] By adopting the above technical solution, a remote procedure call routing table is dynamically constructed based on user identifiers and role information in the JWT payload, achieving fine-grained access control. By comparing the current role set with the role set required by the business interface, the compliance of business operation permissions is ensured. A dependency injection container is used to accurately obtain business service instances, and request data is deserialized and response data is serialized based on data types defined in the public directory, ensuring type security in the data processing process. This business processing solution based on a unified type system, through the tight integration of role verification, type checking, and data conversion, ensures the accuracy of data processing while guaranteeing business processing security, improving system reliability and maintainability, and simplifying the complexity of front-end and back-end data interaction.

[0018] Optionally, after returning the business processing result to the front-end module, the method further includes: the front-end module updating the business data status in the front-end status management container according to the business processing result, and triggering the corresponding interface components to re-render to display the business processing result; when the front-end module initiates subsequent business service calls, it reuses the stored access token and the generated front-end client class to repeatedly execute the permission verification and business processing process.

[0019] By adopting the above technical solution, the front-end module manages the business data state uniformly through a state management container and establishes a responsive association with the interface rendering, enabling real-time display of business processing results. By reusing stored access tokens and generated front-end client classes, the repeated token acquisition and client class initialization processes are avoided, improving the efficiency of subsequent business calls. This front-end processing solution based on state management and resource reuse ensures timely responsiveness and consistency of the user interface, reduces system overhead by rationally reusing system resources, improves user interaction experience and system operating efficiency, simplifies the complexity of front-end code, and improves development efficiency and maintainability.

[0020] Secondly, this application provides a device for implementing a full-stack front-end using CellJS. The device includes one or more processors and a memory. The memory is coupled to the one or more processors and is used to store computer program code, which includes computer instructions. The one or more processors call the computer instructions to cause the device for implementing a full-stack front-end using CellJS to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, this application provides a computer program product containing instructions that, when run on a device implementing a full-stack front-end via CellJS, cause the device implementing a full-stack front-end via CellJS to execute the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, this application provides a computer-readable storage medium including instructions that, when run on a device implementing a full-stack front-end via CellJS, cause the device to perform the method described in the first aspect and any possible implementation thereof. Attached Figure Description

[0023] Figure 1 is a flowchart illustrating a method for implementing a full-stack front-end using CellJS, as provided in an embodiment of this application; Figure 2 is an architecture diagram illustrating the generation of a front-end client class, as provided in an embodiment of this application; Figure 3 is a timing diagram illustrating a method for implementing a full-stack front-end using CellJS, as provided in an embodiment of this application; Figure 4 is an exemplary hardware structure diagram illustrating a device for implementing a full-stack front-end using CellJS, as provided in an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0025] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0026] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0027] This application provides a method for implementing a full-stack front-end using CellJS. Referring to Figure 1, Figure 1 is a flowchart illustrating a method for implementing a full-stack front-end using CellJS according to an embodiment of this application, including steps S101 to S107. The steps are as follows: S101: Define multiple service interfaces in a common directory shared by the front-end module and the back-end module, and generate metadata files based on each service interface.

[0028] In this embodiment, the public directory refers to a shared code directory structure that can be accessed simultaneously by the front-end and back-end modules. It represents a unified storage location for cross-module shared code files. The public directory typically contains interface definition files, data type definition files, and configuration files, enabling the front-end and back-end modules to be developed based on the same interface specifications. For example, the public directory could be a shared folder under the project root directory, containing an interfaces subdirectory for storing service interface definitions and a types subdirectory for storing data type definitions.

[0029] Specifically, firstly, a service interface definition file is created in the public directory. This file uses an interface description language to define multiple service interfaces, each containing information such as method name, input parameter types, output parameter types, and invocation method. Next, corresponding request and response data structures are defined for each service interface, including attributes such as field names, data types, required field identifiers, and validation rules. Then, a code generation tool scans the service interface definition file in the public directory, parsing the interface information, data type information, and method signature information. Finally, the parsed interface information is structured according to a preset metadata format, generating a metadata file in JSON or XML format containing interface identifiers, method lists, parameter definitions, and return value definitions. This generated metadata file is then stored in a specified location in the public directory.

[0030] S102: When the serverless function container of the backend module performs a cold start, the backend module loads the metadata file and obtains the first data set containing service interface and service method mapping information.

[0031] In this embodiment, a serverless function container refers to a lightweight virtualization runtime environment provided by a cloud computing platform for running serverless functions. It represents an independent container instance that allocates computing resources on demand and executes specific business logic. Serverless function containers feature automatic scaling, pay-as-you-go billing, and zero-maintenance management. When a request is received, a container instance is automatically created to execute the function code, and the container instance is automatically destroyed after execution. Examples include AWS Lambda containers, Alibaba Cloud Function Compute containers, and Tencent Cloud Cloud Function containers. These containers require cold start operations such as code loading, dependency installation, and environment initialization upon initial startup.

[0032] Specifically, when the serverless function container receives its first request and triggers the cold start process, the backend module first locates and reads the contents of the metadata file from a pre-defined public directory path. Next, it parses the read metadata file content, converting the JSON or XML metadata into in-memory data structure objects. Then, it iterates through the parsed metadata objects, extracting information such as the service interface identifier, the corresponding service method name, the method parameter definition, and the method return type. Next, it establishes a key-value mapping between the service interface identifier and the service method, where the key is the unique identifier of the service interface, and the value is a method description object containing the method name, parameter type list, and return type. Finally, all mapping relationships are organized into a first data set.

[0033] S103: Construct an authentication and authorization module based on the first data set. The authentication and authorization module is used for token management and access control.

[0034] In this embodiment, the authentication and authorization module represents a functional component responsible for handling user authentication and access control. It represents an independent module integrating security-related functions such as token generation, token verification, permission checking, and access control. The authentication and authorization module typically includes sub-components such as a user authentication processor, a token manager, a permission validator, and access control policies, providing a unified security mechanism for the entire system. For example, the authentication and authorization module may include a JWT token processor for generating and verifying access tokens, a role-permission manager for managing the mapping between user roles and permissions, and an access control interceptor for performing permission verification before business calls.

[0035] Specifically, the process begins by scanning service implementation classes in the backend module that are marked with remote call annotations or specific identifiers, obtaining their class names, method signatures, and annotation information. Next, the scanned service implementation class information is compared one by one with the service interfaces defined in the first data set to verify whether the service implementation class correctly implements the corresponding service interface, including method name matching, parameter type consistency checks, and return value type verification. Then, mapping relationship data between service interface identifiers and service implementation classes is generated, recording information such as interface name, implementation class path, method mapping table, and dependencies. Next, a dependency injection container is initialized based on the mapping relationship data, and verified service implementation classes are registered in the dependency injection container according to their corresponding service interface identifiers, establishing a binding relationship between interfaces and implementations. Then, configuration management-related service instances, including key managers, token configurators, and permission configurators, are obtained from the dependency injection container, and these instances undergo configuration integrity verification to ensure that necessary configuration parameters are complete. Finally, the verified configuration management service instances are organized into a configuration item set, and combined with the service instances in the dependency injection container, an authentication and authorization module is constructed, including a token processing submodule, a permission verification submodule, and an access control submodule.

[0036] S104: Generate the front-end client class corresponding to each service interface based on each service interface and metadata file.

[0037] In this embodiment, the front-end client class refers to a code class file automatically generated for the front-end module to call back-end services. It represents a client proxy object that encapsulates service call logic, parameter serialization, and response processing. The front-end client class typically contains method definitions that correspond one-to-one with the back-end service interfaces. Each method is responsible for handling operations such as network request construction, data transmission, and result parsing, allowing front-end developers to call remote services as if they were calling local methods. For example, for a user management service interface, the generated front-end client class might contain methods such as `createUser`, `updateUser`, and `deleteUser`, each encapsulating HTTP request sending, parameter validation, and error handling logic.

[0038] Specifically, the process begins by parsing detailed information about all service interfaces from the metadata file, including interface name, method list, input parameter structure, and output parameter structure. Next, each service interface is iterated through, and corresponding front-end method code is generated based on the method information defined in the interface, including method signature, parameter type declaration, and return value type declaration. Then, network request processing logic is generated for each method, including code snippets for request URL construction, HTTP method settings, request header configuration, and request body serialization. Next, parameter validation code is generated based on the service interface's input parameter definitions to ensure that the parameters passed during the call conform to the interface's required data type and format specifications. Then, response data deserialization code is generated based on the service interface's output parameter definitions, converting the response data received from the backend into data objects that the frontend can directly use. Next, error handling mechanisms are added to each front-end client class, including logic for network exception capture, HTTP status code judgment, and business error information extraction. Finally, the generated method code, request processing logic, and error handling code are organized into a complete front-end client class.

[0039] As shown in Figure 2, Figure 2 is an architecture diagram of generating a front-end client class provided by an embodiment of this application.

[0040] The topmost interface definition layer (Common) is the common contract for front-end and back-end collaboration. OauthServerInterface and WelcomeServer Interface correspond to the "defining service interfaces" step in the solution. These interfaces are not only the standard basis for the implementation of back-end services, but also the basic carrier for generating front-end client classes.

[0041] The next service implementation layer (Mode) is the concrete layer that carries the backend business logic. The module marked with @CellMode is the service unit under the CellJS framework, while OauthServerImpl and WelcomeServerImpl marked with @RpcService are the implementation classes of the corresponding interfaces in the interface definition layer. At the same time, backendCfg here is automatically configured and corresponds to the configuration management service instance in the solution. It is responsible for loading the environment, authentication and other configuration items required by the backend service, so that the backend service can run based on a unified configuration.

[0042] The middle RPC framework layer is the core bridge connecting the front end and the back end. Through the service registration / discovery and service instance management capabilities carried by @CellRpc, it corresponds to the remote procedure call support system in the solution. It is the underlying support for the front end to call back end services securely and accurately. For example, the RpcUtil call used by the front end in the previous login process relies on the capabilities of this layer.

[0043] The bottommost front-end call layer (Browser) is the implementation of the multi-terminal front-end modules in the solution. OauthServerWarp is a front-end client class generated based on the interface definition layer. It allows the front-end (whether it is ReactWeb, Mini Program or other carriers) to call the back-end service in a type-safe manner. The multiple front-end carriers covered by this layer also correspond to the front-end module design that adapts to different terminals in the solution. Overall, it connects the entire process architecture logic from interface definition to multi-terminal call.

[0044] S105: When a user triggers a login operation on the front-end interface, the front-end module sends the login operation to the corresponding back-end module, which generates an access token based on the authentication and authorization module and the front-end client class.

[0045] In this embodiment, an access token refers to a security credential used to verify user identity and authorize access permissions. It represents a digital credential issued by an authentication and authorization module, possessing a time limit and scope of permissions. Access tokens typically take the form of a JWT or an encrypted string, containing security elements such as user identifier, permission information, expiration date, and signature, serving as the basis for authentication and permission verification in subsequent business requests. For example, an access token can be a JWT token containing user ID, role information, expiration time, and a digital signature, or a string containing user session information encrypted with AES.

[0046] Specifically, when a user clicks the login button or submits a login form on the front-end interface, the front-end module first obtains the login credentials entered by the user, including authentication data such as username, password, or third-party authorization code. Next, the front-end module calls the authentication method in the corresponding front-end client class, constructs a network request message containing the login credentials according to the interface definition of the authentication method, and sets network transmission parameters such as request URL, HTTP method, request headers, and request body. Then, the constructed network request message is sent to the corresponding back-end module service address via the HTTP protocol. Upon receiving the network request message, the back-end module parses the routing identifier information from the request URL or request headers. This identifier is used to determine the specific service processing logic. Next, based on the parsed routing identifier, it searches for and retrieves the corresponding authentication service instance from the dependency injection container. This instance contains the specific implementation logic for user authentication and permission judgment. Then, the authentication service instance verifies the login credentials in the request, including authentication processes such as username / password verification, third-party authorization code verification, or biometric recognition. Finally, after successful user authentication, the authentication service instance calls the token generator in the authentication and authorization module to generate an access token containing a digital signature based on the user's identity information, permission scope, and system configuration parameters.

[0047] S106: When the front-end module initiates a business service call, the back-end module performs permission verification based on the access token to obtain the verification result.

[0048] In this embodiment, the verification result refers to the processing result information returned by the authentication and authorization module after verifying the access token, which indicates the verification status of the token's legality, validity, and permission scope. The verification result typically includes a status code indicating successful or failed verification, user identity information, a permission list, and an error description, providing a basis for security decisions in subsequent business logic execution. For example, the verification result may be a verification information object containing a successful verification status, a user ID of 12345, an administrator role, and a permission list indicating user management permissions, or an error information object containing a failed verification status and a token expiration error description.

[0049] Specifically, when the front-end module needs to call a specific business service, it first parses and extracts the second access token from the response data of the previous login operation, storing this token in the front-end module's local storage or memory cache for subsequent requests. Next, the front-end module obtains the request data type specifications required by the interface according to the business service interface definition corresponding to the target business service, including required fields, data format, and parameter constraints. Then, it constructs a business request data object according to the request data type specifications, converting the user-input business parameters into a structured data object that conforms to the interface requirements. Next, it calls the corresponding method in the front-end client class corresponding to the business service interface to serialize the business request data object into a network transmission format, adding an Authorization field to the HTTP header of the generated business network request message, and attaching the second access token as a Bearer token to the request header. Finally, it sends the complete network request message containing the business data and access token to the corresponding back-end module service address. After receiving the business network request message, the back-end module extracts the second access token from the request header through the token processing submodule in the authentication and authorization module. Next, the token processing submodule retrieves the key configuration information required for token verification from the configuration item set. It then uses the verification key from the configuration management service instance to perform digital signature verification on the second access token, confirming that the token has not been tampered with. Next, it verifies the validity period of the timestamp information in the token to determine if the token is within its valid usage period. Finally, it integrates the signature verification result, the validity period verification result, and the permission information in the token to generate a verification result containing the verification status, user identity, and permission scope.

[0050] S107: Perform business processing based on the verification results and return the business processing results to the front-end module.

[0051] In this embodiment, the business processing result refers to the data output generated by the backend module after executing specific business logic according to the frontend request. It is a comprehensive result object representing the execution status, returned data, and processing information of the business operation. The business processing result typically includes a success or failure status code, specific business data content, error message descriptions, and additional metadata, providing the frontend module with complete feedback on the business operation. For example, the business processing result of a user query operation may include a successful query status, a list of detailed user information, and query time, or it may include a failed query status and error descriptions indicating insufficient permissions.

[0052] Specifically, after the verification result shows that the second access token has passed verification, the backend module first parses the user identification information and the set of roles currently held by the user from the payload of the second access token, including user ID, username, and role list, etc., as identity and permission data. Next, based on the service interface routing identifier information defined in the first data set, and combined with the current user's role set, a remote procedure call routing table is constructed for that user. This routing table records the service interfaces accessible to the user and their corresponding permission requirements. Then, the business routing identifier is extracted from the business network request message, and the required role set and permission requirements for the business request are searched in the constructed remote procedure call routing table. The current user's role set is then compared and verified with the role set required by the business request to determine whether the user has the permission to execute the business operation, obtaining the business processing result of the permission verification. Then, when the permission verification passes, the corresponding business service instance is obtained from the dependency injection container based on the business routing identifier. This instance contains the specific business logic implementation code. Next, the request body of the business network request message is deserialized, and the JSON or XML format request data is converted into a business data object matching the method parameters of the business service instance according to the corresponding request data type defined in the public directory. Then, the corresponding method of the business service instance is called, passing the business data object as a parameter to execute the specific business processing logic, and obtaining a business processing result data object containing business result information. Finally, the business processing result data object is serialized according to the corresponding response data type defined in the public directory, converted into a network transmission format that the front-end module can parse, and the serialized business processing result is returned to the front-end module via an HTTP response.

[0053] As shown in Figure 3, Figure 3 is a timing diagram of a method for implementing a full-stack front-end using CellJS, provided in an embodiment of this application.

[0054] This sequence diagram fully presents the end-to-end interaction process from the user initiating a login request to the final generation and storage of the JWT token. It clearly shows the temporal relationship between multiple roles and components, such as the user, the front-end browser, the OAuth server, the ConfigService configuration management service, the permission / role service, and the JWT Service token service. Moreover, each step of the interaction is deeply consistent with the core logic of the CellJS-based full-stack front-end solution.

[0055] The process begins with the user triggering a login operation in the front-end browser. After the user clicks the login button, the front-end browser first sends a request to the ConfigService configuration management service to obtain the OAuth configuration containing information such as getApiSSOHost and getAppSSOClient. ConfigService returns the corresponding environment configuration based on the current environment (such as development / qa / staging / production). Based on this configuration, the front-end browser redirects the page to the authorization page of the OAuth server, completing the initial triggering and configuration preparation of the login request.

[0056] Once the OAuth authorization process begins, after the user completes the authorization operation on the OAuth server's authorization page, the OAuth server will return the authorization code (code) and the CSRF protection parameter (state) to the front-end browser. At this point, the front-end browser has obtained the key credentials for subsequently obtaining an access token.

[0057] The next step involves obtaining the access token and user information. The front-end browser uses the RpcUtil tool to call the back-end's oauthServer.getInfo method (this RpcUtil call logic corresponds to the front-end client class generated based on the service interface in the solution, implementing type-safe remote procedure calls). During the call, the back-end first retrieves the OAuth configuration from ConfigService again to ensure parameter accuracy. After ConfigService returns the configuration information, the back-end sends a POST request to the OAuth server to the / oauth / token interface based on the authorization code, successfully obtaining the first access token, access_token. Then, it sends a POST request to the / oauth / rs / getuserinfo interface, using the access_token to obtain the user's basic information, completing the identity information collection for the external authentication process.

[0058] During the user permission and role acquisition phase, the backend further calls the interface to obtain detailed OA user information (such as UserID, DeptID, etc.), specifically through a POST request to the / user / getuserbyidname interface (the interface path will be dynamically adjusted according to the environment). After the OAuth server returns the detailed user information, the backend then calls the / role / getrolebyuserid interface to obtain the user role list (returned in the form of a role_name array). This user identifier and role set data will serve as the core payload content for the subsequent generation of JWT tokens.

[0059] Finally, the JWT Token generation stage begins. The JWT Service uses the RS256 algorithm and combines it with the private key provided by the configuration management service to sign the payload containing user profile information (user identifier, role set, etc.) to generate a JWT Token. The validity period of this Token is set to 3:00 AM the next day. After generation, the Token is returned to the front-end browser, which saves the Token in the Session to provide a security credential for permission verification when initiating subsequent business service calls. This completes the entire login authentication and token generation process.

[0060] Based on the above embodiments, as an optional embodiment, the step of constructing the authentication and authorization module according to the first data set in S103 may specifically include the following steps: S201: scanning service implementation classes with remote call tags, matching and verifying the service implementation classes with the service interfaces in the first data set, and generating mapping relationship data.

[0061] In this embodiment, mapping relationship data refers to structured information that records the correspondence between service interfaces and their specific implementation classes. It represents the binding configuration and association mapping between interface definitions and implementation logic. Mapping relationship data typically includes the service interface's identifier information, the full path of the corresponding implementation class, a method signature mapping table, and dependency descriptions, providing basic configuration information for the construction of the dependency injection container and service instantiation. For example, mapping relationship data may include the user service interface IUserService corresponding to the implementation class com.example.UserServiceImpl, the method createUser mapped to the createUser method in the implementation class, and the related information such as the implementation class's dependency data access layer UserRepository.

[0062] Specifically, firstly, all class files in the backend module project are scanned using reflection to identify service implementation classes annotated with `@RemoteService`, `@Service`, or other custom remote call annotations. Next, detailed information for each scanned service implementation class is obtained, including the full class name, a list of implemented interfaces, public method signatures, and annotation configuration metadata. Then, all service interfaces defined in the first data set are traversed, obtaining the interface name, method definition list, and parameter type information for each service interface. Next, interface matching verification is performed on each scanned service implementation class to check whether the implementation class correctly implements the corresponding service interface, including verifying whether the implementation class inherits or implements the target interface, whether the method names are consistent, whether the number and types of parameters match, and whether the return value types are compatible. Then, a mapping relationship record is established for the service implementation classes and service interfaces that pass the matching verification, recording the correspondence between interface identifiers and implementation class paths, the mapping table between interface methods and implementation methods, the constructor parameter requirements of the implementation class, and dependency injection requirements. Finally, all verified mapping relationship records are organized into structured mapping relationship data.

[0063] S202: Create a dependency injection container based on the mapping relationship data, and register the service implementation classes into the dependency injection container according to the corresponding service interfaces.

[0064] In this embodiment, the dependency injection container refers to the core component used to manage the lifecycle and dependencies of service objects, representing a container manager responsible for service instantiation, dependency resolution, and object injection. The dependency injection container typically adopts a factory or singleton pattern design and includes core modules such as a service registry, instance cache pool, and dependency resolver. It can automatically create service instances based on service identifiers and resolve dependencies between services. For example, the dependency injection container can be Spring's ApplicationContext or a custom ServiceContainer. When a UserService instance is needed, the container automatically creates a UserServiceImpl object and injects its dependent service instances such as UserRepository and ConfigService.

[0065] Specifically, the core data structures of the dependency injection container are first initialized based on the configuration information in the mapping relationship data. This includes creating container management components such as a service registry, instance cache mapping table, and dependency graph. Next, each mapping record between a service interface and its implementation class in the mapping relationship data is traversed, extracting the fully qualified class name, interface identifier, and classpath information of the corresponding implementation class. Then, dependency analysis is performed on each service implementation class, using reflection to examine the constructor parameters, field injection annotations, and method injection annotations to identify other service interfaces or components that the implementation class depends on. Next, the specific registration operation is executed, using the Class object or interface identifier of the service interface as the registration key, and the Class object, instantiation factory method, and configuration metadata of the corresponding service implementation class as the registration values. The key-value pairs are stored in the container's service registry by calling the `register` or `put` method of the dependency injection container. Finally, an instantiation strategy is configured for each registered service, including setting lifecycle management rules such as singleton mode, prototype mode, or session scope, and specifying lazy loading or preloading strategies for instance creation. Next, the dependency graph between services is built and updated, the dependencies of newly registered services are added to the dependency resolver, and circular dependency detection is performed to ensure the integrity and resolvability of the dependency chain.

[0066] S203: Create a configuration management service instance based on the dependency injection container, perform integrity verification on the configuration management service instance, and use the verified configuration management service instance as a set of configuration items; build an authentication and authorization module based on the dependency injection container and the set of configuration items.

[0067] In this embodiment, the authentication and authorization module refers to the core security component responsible for handling user authentication and access control, representing a comprehensive security module that provides login authentication, token management, and access permission verification functions. The authentication and authorization module typically includes sub-modules such as an identity authenticator, token processor, permission verifier, and security configuration manager, capable of performing comprehensive security checks and access control on user requests. For example, the authentication and authorization module may include a JWT token generator for creating access tokens, an RBAC permission verifier for checking user role permissions, and a key manager for handling encryption and decryption operations, enabling a complete security process from authentication to permission authorization when a user initiates a business request.

[0068] Specifically, the process begins by retrieving the registration information of the configuration management service from the dependency injection container using the service interface identifier, and then creating an instance of the configuration management service by calling the container's `getBean` or `resolve` method. Next, the created configuration management service instance undergoes functional integrity verification, including checking if the configuration loading interface is working correctly, verifying the completeness of configuration data reading and parsing functions, and testing the stability and effectiveness of configuration item retrieval and update operations. Then, the configuration management service instance undergoes data integrity verification, verifying its ability to correctly load critical configuration items required by the system, such as database connection configuration, security key configuration, and service port configuration. The configuration management service instance that passes integrity verification is then encapsulated into a configuration item collection, which serves as the configuration data source for system operation, providing a unified configuration access interface and configuration change notification mechanism. Finally, based on the dependency injection container, instances of various sub-component services required by the authentication and authorization module are obtained, including core components such as user authentication service, token processing service, permission verification service, and encryption / decryption service. The configuration item collection is then injected into each sub-component, providing key parameters such as authentication policy configuration for the identity authenticator, key and validity period configuration for the token processor, and role and permission mapping configuration for the permission verifier. Finally, all sub-components are assembled and configured according to the authentication and authorization business process to build a complete authentication and authorization module.

[0069] Based on the above embodiments, as an optional embodiment, S105: When a user triggers a login operation on the front-end interface, the front-end module sends the login operation to the corresponding back-end module. The step of generating an access token based on the authentication and authorization module and the front-end client class can specifically include the following steps: S301: When a user triggers a login operation on the front-end interface, the authorization code sent by the front-end module is obtained, a network request message is constructed based on the authorization code and the front-end client class, and sent to the corresponding back-end module.

[0070] In this embodiment, the authorization code refers to a one-time verification credential used to temporarily identify a user's identity and authorization status, representing a security token for transmitting user authorization information in OAuth 2.0 or similar authorization processes. Authorization codes typically have a short validity period and are used only once. They contain key data such as user identifier, authorization scope, client information, and timestamps, providing secure and reliable authorization credentials for subsequent access token exchanges. For example, when a user clicks the login button on the front-end page and completes authentication, the system generates an authorization code similar to "auth_code_abc123xyz". This authorization code contains the user ID, client identifier, and a 5-minute validity period. The front-end module can use this authorization code to request a formal access token from the back-end.

[0071] Specifically, when a user enters their username and password on the login page of the front-end interface and clicks the login button, the front-end module first performs basic form validation, checking the format and completeness of the input data. Next, the front-end module sends the user's login credentials to the authentication server for identity verification. After verifying the user's identity, the authentication server generates a time-sensitive authorization code and returns it to the front-end module. Then, after obtaining the authorization code, the front-end module reads relevant information about the front-end client class from local storage or configuration, including configuration parameters such as the client identifier, client key, redirect URL, and authorization scope. Next, the front-end module constructs a standard network request message based on the obtained authorization code and the front-end client class information. This message typically uses the POST method, with the request header containing a Content-Type of application / json or application / x-www-form-urlencoded, and the request body containing necessary parameters such as the authorization code, client identifier, client key, and grant_type. Finally, the front-end module sends the constructed network request message to the corresponding back-end module via HTTP or HTTPS protocol.

[0072] S302: The backend module parses the route identifier from the network request message and obtains the authentication service instance from the dependency injection container based on the route identifier.

[0073] In this embodiment, a routing identifier refers to identifier information used to uniquely determine which specific service should handle a network request. It represents a critical path marker guiding request distribution and service location in a microservice architecture. The routing identifier typically includes information such as service name, interface path, HTTP method, and version number, providing the request router with accurate service location and method invocation guidance.

[0074] Specifically, when the backend module receives a network request message from the frontend, it first extracts basic information such as the request method type, request URL path, and protocol version from the HTTP request header. Next, it parses the path portion of the request URL, identifying the specific service path and interface identifier through string splitting and pattern matching. For example, it extracts "auth" as the service identifier and "token" as the interface identifier from " / api / v1 / auth / token". Then, it constructs a complete route identifier based on the request method type and path information. This identifier uniquely identifies the service type and specific method to be called and may include additional identifiers such as version information and parameter patterns. Next, based on the constructed route identifier, it searches for the corresponding service registration record in the dependency injection container, using the container's service lookup mechanism, such as the `getBean` or `resolve` methods, to locate the matching service interface type. Finally, the dependency injection container retrieves the corresponding authentication service implementation class information from the service registry based on the service interface identifier and checks the service's instantiation strategy and dependency configuration. Next, the container performs the creation or retrieval of the authentication service instance. If configured in singleton mode, it returns an existing instance from the instance cache; if configured in prototype mode, it creates a new service instance and automatically injects other components that the service depends on. Finally, the retrieved authentication service instance is returned to the request handler.

[0075] S303: Generate an access token based on the authentication service instance and the authentication authorization module.

[0076] In this embodiment, an access token is a security credential used to authorize a user to access protected resources. It represents a digital authentication credential containing user identity information, permission scope, and validity period restrictions. Access tokens typically use JWT (JSON Web Token) format or opaque token format and contain key information such as user identifier, role permissions, issuance time, and expiration time, providing a basis for authentication and access control for subsequent API calls and resource access.

[0077] Specifically, firstly, the authentication service instance, through the external authentication client submodule in the authentication and authorization module, sends the authorization code obtained from the front end along with client credential information to the external authentication server, requesting the exchange of a formal access token. After verifying the validity of the authorization code, the external authentication server returns a first access token as a temporary identity credential. Next, the authentication service instance uses the obtained first access token to initiate a user information query request to the external authentication server or user information service, obtaining verified user identification information, including the user's unique ID, username, and basic attributes. Then, based on the obtained user identification, the authentication service instance queries the set of roles associated with the user from the system's internal permission storage module, including the assigned role name, role permission scope, and role validity period. Next, the token processing submodule in the authentication and authorization module creates a JWT payload data structure, writing the user identifier, role set, token issuance time, expiration time, and other necessary declaration information into a JSON-formatted payload. Then, the token processing submodule obtains a pre-configured token signing key from the configuration management service instance. This key is used to ensure the integrity and tamper-proof nature of the access token, and uses an HMAC or RSA algorithm to digitally sign the JWT payload to generate a second access token.

[0078] Based on the above embodiments, as an optional embodiment, S303: the step of generating an access token according to the authentication service instance and the authentication authorization module may specifically include the following steps: S401: according to the authentication service instance, the external authentication client submodule uses the authorization code to exchange for a first access token from the external authentication server, according to the authentication service instance, the first access token is used to obtain a user identifier, and according to the user identifier, the set of roles associated with the user identifier is read from the permission storage.

[0079] In this embodiment, the external authentication client submodule refers to a dedicated component responsible for communicating and exchanging tokens with an external authentication server. It represents the core module that implements OAuth 2.0 client functionality and integrates with external authentication. The external authentication client submodule typically includes sub-components such as an HTTP client, token cache, error handler, and protocol adapter, enabling secure interaction with third-party authentication services according to standard authentication protocols.

[0080] Specifically, the authentication service instance first extracts key parameters such as the authorization code, client identifier, and redirection URI from the network request message, and performs format validation and integrity checks on these parameters. Next, the authentication service instance calls the external authentication client submodule within the authentication and authorization module. This submodule determines the token endpoint URL of the target external authentication server and the required authentication protocol type based on the configuration information. Then, the external authentication client submodule constructs a standard token exchange request, including setting the POST request method, adding a request header with Content-Type set to application / x-www-form-urlencoded, and including necessary parameters such as the authorization code, client ID, client key, and grant_type in the request body. Next, the external authentication client submodule sends the token exchange request to the external authentication server via the HTTPS protocol. After verifying the validity of the authorization code and the correctness of the client credentials, the external authentication server returns response data containing the first access token, token type, validity period, and refresh token. Finally, the authentication service instance uses the obtained first access token to construct a user information query request and initiates an API call to the user information endpoint of the external authentication server, carrying "Authorization:Bearer [first access token]" in the request header for authentication. Next, after verifying the first access token, the external authentication server returns the authenticated user information, including the user's unique identifier, username, email address, and basic attributes. The authentication service instance parses the user identification information from the response. Finally, based on the obtained user identification, the authentication service instance retrieves the set of roles associated with that user from the system's internal permission storage module.

[0081] S402: The token processing submodule writes the user identifier and role set into the JSON Web Token payload, generates a second access token using the token signing key provided by the configuration management service instance, and encapsulates the second access token into login response data and returns it to the front-end module.

[0082] In this embodiment, the JSON Web Token payload refers to the data portion of the JWT token used to store the actual claims information, representing a JSON-formatted data carrier containing user identity, permissions, and other custom claims. The JSON Web Token payload typically includes standard claims such as iss (issuer), exp (expiration time), and sub (subject), as well as custom claims such as user ID and role permissions, which are Base64 encoded to form the middle part of the JWT token.

[0083] Specifically, the token processing submodule first creates a JSON-formatted payload data structure, setting standard JWT claim fields including the `iss` field to identify the token issuer, the `iat` field to record the token issuance timestamp, and the `exp` field to set the token expiration timestamp, typically set to the current time plus the configured validity period. Next, the token processing submodule writes the user identification information obtained from the authentication service into the `sub` field of the payload, and the user's role set data into the custom `roles` field. It can also add other business-related claims such as user permission scope, tenant identifier, and session ID. Then, the token processing submodule obtains a pre-configured token signing key from the configuration management service instance. This key may be a symmetric key used for the HMAC algorithm or an asymmetric private key used for the RSA algorithm, ensuring the key's security and validity. Finally, the token processing submodule uses the JWT library to encode and sign the payload data and key. First, the payload is Base64URL encoded, then combined with the JWT header information to generate a digital signature using the specified signing algorithm, ultimately assembling a complete second access token. The token processing submodule then encapsulates the generated second access token, along with information such as token type, expiration time, refresh token, and permission scope, into a standard login response data format, typically in JSON format containing standard fields such as access_token, token_type, and expires_in. Finally, the encapsulated login response data is returned to the frontend module via an HTTP response.

[0084] Based on the above embodiments, as an optional embodiment, S106: When the front-end module initiates a business service call, the back-end module performs permission verification based on the access token to obtain the verification result. This step may specifically include the following steps: S501: When the front-end module initiates a business service call, the front-end module parses and stores the second access token from the login response data.

[0085] In this embodiment, the second access token refers to a security credential with complete user permission information generated by the system's internal token processing submodule. It represents a JWT-formatted access token containing user identity, role set, and system-specific claims. The second access token differs from the first access token obtained from an external authentication server; it integrates external authentication results and internal permission data, including system-defined user roles, permission scopes, and business-related custom claims, providing complete authentication and authorization for internal API calls and resource access.

[0086] Specifically, after the front-end module receives the login response data from the back-end, it first checks the HTTP response status code and validates the data format to confirm that the login operation was successfully completed and the response data structure is complete and valid. Next, the front-end module uses a JSON parser to parse the login response data, extracting the value of the `access_token` field from the response body as the second access token, and simultaneously parsing related token information such as `token_type`, `expires_in`, and `refresh_token`. Then, the front-end module performs basic validation on the parsed second access token, including checking whether the token format conforms to the JWT standard, whether the token length is reasonable, and whether the token contains the necessary header and payload. Next, the front-end module selects an appropriate storage mechanism to save the second access token: persistent storage using the browser's `localStorage`, session-level storage using `sessionStorage`, or secure storage using an HttpOnly Cookie, and decides whether to encrypt the token based on security requirements. Finally, the front-end module synchronously stores the token's expiration time information, sets a token refresh policy and an automatic logout mechanism, and ensures that the token is refreshed or the user is prompted to log in again when it is about to expire.

[0087] S502: Construct a business request data object based on the request data type of the business service interface corresponding to the business service, and send it to the corresponding backend module after attaching a second access token to the header of the business network request message of the business request data object through the front-end client class corresponding to the business service interface.

[0088] Specifically, the front-end module first determines the corresponding business service interface based on the business service to be called, and obtains the API documentation or interface definition information of that interface, including key information such as request method type, URL path, request parameter structure, and response data format. Next, the front-end module analyzes the request data type required by the business service interface, which may be in different formats such as JSON objects, form data, file uploads, or query parameters, and collects raw data from user input or business logic as the basis for the request content. Then, the front-end module creates the corresponding business request data object according to the data structure defined by the interface, performing data type conversion and formatting, including setting required fields, applying data validation rules, performing date format conversion, and adjusting numerical precision, among other data preprocessing operations. Finally, the front-end module instantiates or calls the front-end client class corresponding to the target business service. This client class encapsulates the API call logic for a specific business domain, including pre-configured service base URL, default request headers, and general error handling strategies. Then, the front-end client class uses the business request data object to construct a complete HTTP request message, setting the correct request method, target URL path, Content-Type request header, and request body data. It also appends a second access token retrieved from storage to the Authorization field of the request header, typically in the format "Bearer [second access token]". Next, the front-end client class sends the constructed business network request message to the corresponding back-end module through the built-in HTTP client component.

[0089] S503: The backend module uses the verification key in the configuration management service instance to perform signature verification and validity period verification on the second access token through the token processing submodule, and obtains the verification result.

[0090] Specifically, the backend module first extracts the value of the Authorization field from the HTTP header of the received business network request message, parses it to obtain a second access token of type Bearer, and performs preliminary verification of the token format to ensure it conforms to the JWT standard structure. Next, the backend module passes the extracted second access token to the token processing submodule. This submodule uses a JWT parsing library to decompose the token into three components: header, payload, and signature, and performs Base64URL decoding on each part. Then, the token processing submodule obtains the same verification key used when issuing the token from the configuration management service instance. This key may be a symmetric key for the HMAC algorithm or a public key for the RSA algorithm, ensuring key version consistency and validity. Next, the token processing submodule recalculates the header and payload of the token using the obtained verification key according to the signature algorithm type specified in the token header, generates the expected signature value, and compares it with the original signature in the token for verification. Finally, the token processing submodule verifies the token's validity period, extracts the expiration timestamp declared in the payload, compares it with the current system time, and checks the reasonableness of time-related declarations such as the IAT issuance time and NBF effective time. Next, the token processing submodule combines the signature verification result and the validity period verification result to generate a verification result containing verification status, error information, and user permission data.

[0091] Based on the above embodiments, as an optional embodiment, S107: the step of performing business processing according to the verification result and returning the business processing result to the front-end module may specifically include the following steps: S601: when the verification result is that the verification is successful, the user identifier and the current role set are parsed from the payload of the second access token, and a remote procedure call routing table is constructed according to the routing identifier in the first data set and the current role set.

[0092] In this embodiment, the Remote Procedure Call (RPC) routing table refers to an API call routing mapping data structure dynamically constructed based on user permissions and service configuration. It represents a navigation table that routes business requests to the corresponding microservice instances according to user roles and permissions. The RPC routing table typically contains key information such as route identifier, target service address, permission requirements, load balancing strategy, and circuit breaker configuration, ensuring that requests are correctly forwarded to the authorized service endpoints based on the user's actual permissions.

[0093] Specifically, firstly, after the backend module confirms that the verification result shows the second access token has passed, it calls the JWT parsing component to perform detailed parsing of the token's payload, extracting key identity data such as user ID, username, and tenant identifier. Next, the backend module parses the complete set of roles for the current user from the payload, including detailed permission information such as role name, role level, role validity period, and role scope, and performs format validation and validity checks on the role data. Then, the backend module obtains the system's pre-configured first data set, which contains configuration information such as all available business service route identifiers, corresponding microservice addresses, permission requirements, and routing rules, typically dynamically obtained from the configuration management service or service registry. Next, the backend module executes a permission matching algorithm, comparing the current role set with the permission requirements of each route identifier in the first data set to identify all business services and API endpoints that the user's current role has permission to access. Then, based on the permission matching results, the backend module dynamically constructs a personalized remote procedure call routing table, creating a route entry for each authorized route identifier, containing runtime information such as the target microservice instance address, load balancing weight, health check status, and call timeout configuration.

[0094] S602: Based on the business route identifier in the business network request message, search the remote procedure call routing table for the set of roles required for the business network request message, and compare the current set of roles with the set of roles required to obtain the business processing result.

[0095] In this application embodiment, the required role set refers to the combination of role permissions that the system requires users to have when accessing a specific business service interface. It is used to represent the minimum set of permission requirements necessary to perform a certain business operation or access a certain resource.

[0096] Specifically, the backend module first parses the business route identifier from the received business network request message. This identifier, typically contained in the request URL path, HTTP headers, or request parameters, uniquely identifies the specific business service interface the user wants to call. Next, the backend module uses the business route identifier as a query key to perform an exact match in the previously built remote procedure call routing table, locating the corresponding route entry and extracting the configured permission requirement information. Then, the backend module obtains the required set of roles for the business interface from the found route entry, including a complete definition of permission requirements such as a list of required roles, optional role combinations, and special permission identifiers, while also obtaining the role logical relationship configuration, such as AND, OR, or compound logical expressions. Next, the backend module executes a role permission comparison algorithm, matching and verifying the user's current role set against the required role set according to predefined logical relationships to check if the user meets the minimum permission requirements to access the business interface. Finally, the backend module generates a business processing result based on the permission comparison result. If the current role set meets the requirements of the required role set, it is marked as permission verification passed, allowing continued execution of business logic processing; if permissions are insufficient, an access denial result is generated, recording the specific reason for the insufficient permissions and the missing role information.

[0097] S603: Based on the business processing result, obtain the corresponding business service instance from the dependency injection container, deserialize the request body of the business network request message into a business data object that matches the corresponding request data type in the public directory, obtain the business processing result data object based on the business data object and the business service instance, and return the business processing result data object to the front-end module after serializing it according to the corresponding response data type.

[0098] Specifically, the backend module first determines the specific business service type to be invoked based on the business processing result after successful permission verification, and then searches for the corresponding business service instance registration information, including metadata information such as service interface type, implementation class, and scope configuration, in the service registry of the dependency injection container. Next, the backend module obtains the business service instance through the instantiation mechanism of the dependency injection container. The container automatically resolves the service dependencies, creates or retrieves existing service objects, and injects necessary dependency components such as the data access layer, caching service, and message queue. Then, the backend module extracts the request body data from the business network request message, uses a deserialization component in JSON or XML format to convert the raw request data into a structured data object, and performs data validation and type matching based on the request data types defined in the public directory. Finally, based on the data type definitions in the public directory, the backend module maps the deserialized request data to a business data object that matches the business service interface contract, performing necessary data conversion, format adjustment, and business rule validation processing. Then, the backend module calls the corresponding business method of the obtained business service instance, passing in the constructed business data object as a parameter, and executes specific business logic processing, including core business operations such as data persistence, business calculation, external service calls, and transaction management, to obtain a business processing result data object containing the processing results. Next, according to the response data type specifications defined in the public directory, the backend module uses a serialization component to convert the business processing result data object into JSON, XML, or other agreed-upon format response data, while setting appropriate HTTP status codes and response header information. Finally, the backend module encapsulates the serialized business processing result into a complete HTTP response message and returns it to the frontend module via a network connection.

[0099] Based on the above embodiments, as an optional embodiment, S107: after the step of returning the business processing result to the front-end module, the step of updating data is also included, which may include the following steps: S701: the front-end module updates the business data status in the front-end status management container according to the business processing result, and triggers the corresponding interface components to re-render to display the business processing result.

[0100] Specifically, after receiving the business processing result from the backend, the frontend module first parses and verifies the response data, extracting key information such as business data, status codes, error messages, and metadata, and determines the success or failure status of the business operation based on the response result. Next, based on the type and content of the business processing result, the frontend module determines the specific state branch in the frontend state management container that needs to be updated, including different types of state data such as business entity data, list collections, user interface states, and global configuration information. Then, the frontend module creates a corresponding state update action object, containing action type identifiers, payload data, and optional metadata information, constructing a new state object following the principle of immutable data updates rather than directly modifying existing state data. Next, the frontend module submits the state update action through the state management container's distribution mechanism, triggering the state management container to execute the corresponding state reducer function, calculating and generating a new application state tree based on predefined state transition logic. Then, after detecting a state change, the state management container automatically notifies all UI components that have subscribed to the relevant state branch, propagating the state change event to the component instances that need updating through the observer pattern or reactive programming mechanisms. Next, the UI component that receives the state change notification executes a re-rendering process, including recalculating component properties, updating the virtual DOM tree, performing DOM difference comparisons, and applying actual DOM changes, to ensure that the user interface remains synchronized with the latest business data state.

[0101] S702: When the front-end module initiates subsequent business service calls, it reuses the stored access token and the generated front-end client class to repeatedly execute the permission verification and business processing flow.

[0102] Specifically, firstly, when the front-end module detects that a user has triggered a subsequent business operation, it retrieves the previously saved access token from local storage or memory cache, verifies the token's validity period and format integrity, and ensures that the token is still valid and has not been damaged or tampered with. Next, the front-end module retrieves an instantiated front-end client class object from the client class cache pool. This object has already completed its initial configuration during the first API call, including pre-configured information such as the basic request URL, default request headers, timeout settings, and interceptor chains. Then, the front-end module injects the retrieved access token into the request interceptor of the generated front-end client class, automatically adding `Authorization: Bearer` to the header of subsequent API requests. <token>Authentication information is processed automatically, eliminating the need for manual token transmission and formatting. The front-end module then uses the generated front-end client class to call the corresponding business API method. The client class automatically executes standardized processes such as request parameter validation, data serialization, network request sending, and response data processing, ensuring the standardization and stability of API calls. Next, upon receiving a business request with a reused access token, the back-end module repeats the previously defined permission verification process, including complete security verification steps such as token signature verification, validity period check, user identity resolution, and role-permission matching. Based on the permission verification result, the back-end module continues with the business processing flow, including obtaining the business service instance from the dependency injection container, data deserialization, business logic execution, and response data serialization. Finally, upon receiving the business processing result, the front-end module automatically parses the response data using the generated front-end client class's response processing mechanism, updates the relevant data state in the front-end state management container, and triggers a re-rendering of the UI components, achieving a complete business call loop.

[0103] The following describes an exemplary device for implementing a full-stack front-end using CellJS, as provided in an embodiment of this application. Figure 4 is a schematic diagram of an exemplary hardware structure of a device for implementing a full-stack front-end using CellJS, as provided in an embodiment of this application.

[0104] In some embodiments, the device implementing a full-stack front-end using CellJS is a computer device, or the device implementing a full-stack front-end using CellJS includes a computer device. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores data. The network interface of the computer device is used to communicate with other external terminals or servers via a network connection. In some embodiments, the network interface can be a wired network interface; in some embodiments, the network interface can also be a wireless network interface. When the computer program is executed by the processor, it implements the methods in the embodiments of this application.

[0105] Those skilled in the art will understand that the structure shown in Figure 4 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0106] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0107] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if..." or "after..." or "in response to determining..." or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining..." or "in response to determining..." or "when (the stated condition or event) is detected" or "in response to detecting (the stated condition or event)".

[0108] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0109] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.< / token>

Claims

1. A method for implementing a full-stack front-end using CellJS, characterized in that, An application is made to an electronic device, which includes a front-end module and a back-end module. The method includes: defining multiple service interfaces in a common directory shared by the front-end module and the back-end module; generating metadata files based on each service interface; when the serverless function container of the back-end module performs a cold start, the back-end module loads the metadata files to obtain a first data set containing service interface and service method mapping information; constructing an authentication and authorization module based on the first data set, the authentication and authorization module being used for token management and access control; generating front-end client classes corresponding to each service interface based on each service interface and the metadata files; when a user triggers a login operation on the front-end interface, the front-end module sends the login operation to the corresponding back-end module and generates an access token based on the authentication and authorization module and the front-end client classes; when the front-end module initiates a business service call, the back-end module performs permission verification based on the access token to obtain a verification result; performing business processing based on the verification result and returning the business processing result to the front-end module.

2. The method for implementing a full-stack front-end using CellJS according to claim 1, characterized in that, The step of constructing the authentication and authorization module based on the first data set includes: scanning service implementation classes with remote call markers, matching and verifying the service implementation classes with service interfaces in the first data set, and generating mapping relationship data; creating a dependency injection container based on the mapping relationship data, and registering the service implementation classes into the dependency injection container according to the corresponding service interfaces; creating a configuration management service instance based on the dependency injection container, performing integrity verification on the configuration management service instance, and using the verified configuration management service instance as a configuration item set; and constructing the authentication and authorization module based on the dependency injection container and the configuration item set.

3. The method for implementing a full-stack front-end using CellJS according to claim 2, characterized in that, When a user triggers a login operation on the front-end interface, the front-end module sends the login operation to the corresponding back-end module and generates an access token based on the authentication and authorization module and the front-end client class. This includes: when the user triggers a login operation on the front-end interface, obtaining the authorization code sent by the front-end module; constructing a network request message based on the authorization code and the front-end client class; and sending it to the corresponding back-end module; the back-end module parses the route identifier from the network request message; obtains an authentication service instance from the dependency injection container based on the route identifier; and generates an access token based on the authentication service instance and the authentication and authorization module.

4. The method for implementing a full-stack front-end using CellJS according to claim 3, characterized in that, The authentication and authorization module includes an external authentication client submodule and a token processing submodule. Generating an access token based on the authentication service instance and the authentication and authorization module includes: obtaining a first access token from an external authentication server using the authorization code through the external authentication client submodule based on the authentication service instance; obtaining a user identifier using the first access token based on the authentication service instance; and reading a set of roles associated with the user identifier from the permission storage based on the user identifier. The token processing submodule writes the user identifier and the set of roles into a JSON Web Token payload, generates a second access token using the token signing key provided by the configuration management service instance, and encapsulates the second access token as login response data and returns it to the frontend module.

5. The method for implementing a full-stack front-end using CellJS according to claim 4, characterized in that, When the front-end module initiates a business service call, the back-end module performs permission verification based on the access token to obtain a verification result. This includes: when the front-end module initiates a business service call, the front-end module parses and stores the second access token from the login response data; constructs a business request data object based on the request data type of the business service interface corresponding to the business service; attaches the second access token to the header of the business network request message of the business request data object through the front-end client class corresponding to the business service interface and sends it to the corresponding back-end module; the back-end module uses the verification key in the configuration management service instance to perform signature verification and validity period verification on the second access token through the token processing submodule to obtain a verification result.

6. The method for implementing a full-stack front-end using CellJS according to claim 5, characterized in that, The step of performing business processing based on the verification result and returning the business processing result to the front-end module includes: when the verification result is successful, parsing the user identifier and the current role set from the payload of the second access token; constructing a remote procedure call routing table based on the routing identifier in the first data set and the current role set; searching for the role set required by the business network request message in the remote procedure call routing table based on the business routing identifier in the business network request message; comparing the current role set with the required role set to obtain the business processing result; obtaining the corresponding business service instance from the dependency injection container based on the business processing result; deserializing the request body of the business network request message into a business data object that matches the corresponding request data type in the public directory; obtaining a business processing result data object based on the business data object and the business service instance; and serializing the business processing result data object according to the corresponding response data type and returning it to the front-end module.

7. The method for implementing a full-stack front-end using CellJS according to claim 1, characterized in that, After returning the business processing result to the front-end module, the method further includes: the front-end module updates the business data status in the front-end status management container according to the business processing result, and triggers the corresponding interface components to re-render to display the business processing result; when the front-end module initiates subsequent business service calls, it reuses the stored access token and the generated front-end client class to repeatedly execute the permission verification and business processing process.

8. A device that implements a full-stack front-end using CellJS, characterized in that, The device implementing a full-stack front-end using CellJS includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the device implementing a full-stack front-end using CellJS to perform the method as described in any one of claims 1-7.

9. A computer program product containing instructions, characterized in that, When the computer program product is run on a device that implements a full-stack front-end using CellJS, the device that implements a full-stack front-end using CellJS performs the method as described in any one of claims 1-7.

10. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is run on a device that implements a full-stack front-end using CellJS, the device that implements a full-stack front-end using CellJS performs the method as described in any one of claims 1-7.

Images