Online car-hailing background-oriented low-code development method and storage medium

Abstract

The invention discloses an online car-hailing background-oriented low-code development method and a storage medium. The invention relates to the technical field of low-code development platforms. And when the client initiates the connection, establishing the connection with the server through the WebSocket API. In the process, the client sends an upgrading request containing initial authentication information (Token) to a specified WebSocket endpoint. And after the server receives the connection request, the server responds to an HTTP (Hyper Text Transport Protocol) response containing the Sec-WebSocket-Accept head so as to complete the handshake process of the WebSocket protocol. According to the low-code platform, the complexity of traditional programming is remarkably reduced, a developer is allowed to quickly construct and deploy functions through a graphical interface, a preset module and a small number of user-defined codes, the time from demand analysis to online is greatly shortened, and the product iteration speed is increased. When specific industry functions need to be added or modified, a development team can quickly insert or adjust corresponding components without affecting stable operation of the whole system.

Description

Technical Field

[0001] The present invention relates to the technical field of low-code development platforms (LCDPs), and specifically to a low-code application development framework for online ride-hailing platforms, and in particular to a low-code development method and storage medium for online ride-hailing backends. Background Art

[0002] Against the backdrop of accelerating digital transformation, the ride-hailing industry, a prime example of the sharing economy, is experiencing unprecedented market expansion and technological innovation. This sector not only meets the public's urgent need for convenient and efficient travel services, but also faces multi-faceted challenges from policies and regulations, market competition, and technological innovation. Growing market demand requires ride-hailing platforms to rapidly respond to the diverse needs of passengers and drivers, providing a more personalized and intelligent service experience. At the same time, the evolving regulatory landscape, particularly regarding data security, privacy protection, and rising service quality standards, compels ride-hailing companies to demonstrate a high degree of flexibility and compliance, ensuring their software systems can promptly adapt to new regulations and requirements.

[0003] In this environment driven by both technology and the market, low-code development platforms, as innovative achievements in software engineering, provide an effective approach to addressing these challenges. By abstracting complex programming processes and leveraging graphical interfaces, drag-and-drop components, and a rich set of pre-set templates, low-code development platforms significantly lower the technical barriers to application development. This development model not only significantly shortens the product design-to-deployment cycle but also effectively controls development costs, enabling companies to bring innovative features to market more quickly. More importantly, it breaks down the barriers of traditional software development, enabling non-professional developers, such as business analysts and product managers, to participate in the application creation process, promoting cross-departmental collaboration, accelerating iteration, and improving the overall agility of the enterprise.

[0004] However, while low-code development platforms demonstrate strong versatility and potential for efficiency improvements, their limitations in specific industries cannot be ignored. This is especially true for industries like ride-hailing, which place stringent demands on real-time performance, security, and high performance. Existing low-code solutions often lack deep customization capabilities, high concurrency processing, and the integration of industry-specific features.

[0005] To this end, the present invention proposes a low-code development method and storage medium for the online car-hailing backend. Summary of the Invention

[0006] In view of this, the present invention hopes to provide a low-code development method and storage medium for the backend of online ride-hailing services to solve or alleviate the technical problems existing in the prior art, namely, how to solve the technical problems of lack of customized functions for specific industries and high concurrency processing on the basis of a low-code development platform, and at least provide a beneficial option for this. The technical solution of the present invention is implemented as follows:

[0007] (1) Overview:

[0008] Real-time, efficient, and secure data transmission is ensured through protocols such as WebSocket and gRPC, providing technical support for the real-time location updates and rapid response requirements unique to the ride-hailing industry. Pre-installed functional modules tailored to the ride-hailing industry utilize a microservices architecture and Docker containerization to achieve efficient operation and horizontal scalability of business logic and data processing. Integrated message queues handle asynchronous tasks, enhancing the system's concurrent processing capabilities. The entire development process begins with request reception, transmits via secure communication protocols, performs real-time data processing and analysis at the component layer, executes complex business logic and data operations at the engine layer, and ultimately transmits processing results back to the front end through the platform layer.

[0009] (2) Hierarchical structure:

[0010] The platform provided by the present invention includes the following hierarchical structure from top to bottom:

[0011] 2.1 Protocol layer:

[0012] Responsible for defining data exchange formats and communication protocols to ensure data compatibility and security across different systems. For the ride-hailing industry, particular emphasis is placed on the efficiency and security of real-time data transmission, using protocols such as WebSocket and gRPC for real-time communication while ensuring encrypted data transmission (such as TLS / SSL) to protect user privacy.

[0013] 2.2 Component layer:

[0014] It provides reusable functional modules for the ride-hailing industry, such as map service components, real-time positioning components, scheduling algorithm components, and billing logic components. These components are available to developers through APIs or SDKs, reducing the difficulty of custom development.

[0015] This includes developing standardized interfaces that allow low-code developers to easily integrate map services (such as the Google Maps API) for route planning through drag-and-drop operations. It also includes designing pre-built real-time positioning service components that support real-time collection and processing of GPS data.

[0016] 2.3 Engine layer:

[0017] It includes a business logic engine and a data processing engine, responsible for executing business processes and data operations. For high-concurrency processing, it introduces distributed processing technology and a microservices architecture, improving the system's processing power and response speed through load balancing and horizontal expansion.

[0018] It adopts a microservice architecture, splitting core functional modules (such as order processing and payment services) into independent services for easy individual expansion and maintenance.

[0019] At the same time, an integrated message queue (RabbitMQ) is used to process asynchronous tasks, reduce the pressure on the main database, and improve the system response speed.

[0020] Use Docker containerization technology for service orchestration to achieve automatic expansion and contraction of services.

[0021] 2.4 Platform layer:

[0022] Provides a user interface and development environment, including a graphical drag-and-drop editor, workflow designer, and version control system. This allows non-technical personnel to participate in application development while ensuring efficiency and collaboration throughout the development process.

[0023] (3) Technical solution:

[0024] Based on the above hierarchical structure, the development method of this technical solution includes the following steps:

[0025] 2.1 Step S1, receiving a request:

[0026] When the protocol layer receives a request, it is securely transmitted to the backend via the WebSocket protocol;

[0027] 2.1.1 Step S100, development request reception initialization:

[0028] When a client initiates a connection, it establishes a connection with the server through the WebSocket API. During this process, the client sends an upgrade request containing preliminary authentication information (token) to the specified WebSocket endpoint.

[0029] 2.1.2 Step S101, develop secure handshake and verification:

[0030] When the server receives the connection request, it responds with an HTTP response containing a Sec-WebSocket-Accept header to complete the WebSocket protocol handshake process.

[0031] The TLS / SSL protocol can be integrated at this stage to ensure the security of the handshake and subsequent data transmission.

[0032] 2.1.3 Step S102, development data frame construction and transmission:

[0033] Allows the client to send actual data frames via WebSocket. The data frames can include the request type (location update and order request), user ID, and geographic location information.

[0034] 2.1.4 Step S103, back-end receiving and decoding:

[0035] S1030, backend monitoring: the backend server continuously monitors message events on the WebSocket connection;

[0036] S1031, decoding processing: After receiving the data frame, the server decodes it, parses the data frame structure of the WebSocket protocol, and restores the original request data.

[0037] 2.2 Step S2, development positioning:

[0038] The real-time positioning component of the component layer can obtain the passenger location in real time, and the scheduling algorithm component can assign the nearest driver based on the location information and driver status.

[0039] 2.2.1 Step S200, develop real-time location data collection:

[0040] The passenger-side App uses GPS or other positioning technologies to continuously collect location information, and sends the location coordinates and timestamp data to the backend through a WebSocket connection at preset time intervals (such as every second or every 5 seconds).

[0041] 2.2.2 Step S201: Develop data storage and cache:

[0042] Use a NoSQL database to store the received passenger location data in real time. And cache the latest location information in the Redis in-memory database.

[0043] 2.2.3 Step S202: Develop Query and Calculation:

[0044] Use the dispatch algorithm component to periodically query the cache or database for the latest passenger location, combined with the driver's current location and status (such as idle, carrying passengers, and available soon) to filter a list of nearby drivers;

[0045] GeoHash spatial database indexing technology is introduced to calculate the distance between passengers and candidate drivers.

[0046] 2.2.4 Step S203: Develop the logic for issuing allocation instructions:

[0047] The backend system sends a task notification to the selected driver's app, including passenger information, boarding location and estimated arrival time.

[0048] 2.3 Step S3, development and processing business:

[0049] Use the business logic engine in the engine layer to develop order creation and billing logic, while letting the data processing engine handle logging and data analysis asynchronously through message queues.

[0050] 2.3.1 Step S300, develop order creation logic:

[0051] When the driver accepts the task, he receives confirmation information from the front-end or driver-side application, including driver ID, passenger ID, pickup location and destination.

[0052] The business logic engine of the engine layer generates an order record based on the received information, including the order number, itinerary details, estimated cost, creation time, etc., and saves it to the order data.

[0053] Update the order status in the passenger and driver apps, notifying both parties that the order has been successfully created.

[0054] 2.3.2 Step S301: Develop real-time billing logic:

[0055] Calculate the estimated fare for the trip based on the trip distance, estimated travel time, and time-of-day rate. This logic is encapsulated in the billing component. After the trip is complete, the fare is finalized based on the actual trip data, triggering the payment process.

[0056] 2.3.3 Step S302: Asynchronous processing of log and data analysis:

[0057] When executing steps S300 to S301, log messages are sent through the RabbitMQ message queue. The data processing engine, as a consumer of the message queue, asynchronously receives and processes these log messages and persists the data in a log database or data warehouse.

[0058] 2.4 Step S4, developing information processing logic:

[0059] Let the processing results be returned to the platform layer through the engine layer, and let the platform layer update the front-end UI.

[0060] 2.4.1 Step S400, development data packaging and verification:

[0061] After completing the business logic processing (including the above-mentioned order creation, billing calculation or status update), the engine layer organizes and standardizes the processing results into JSON format.

[0062] 2.4.2 Step S401: Develop an asynchronous communication mechanism:

[0063] Establish real-time communication channels between the backend and frontend using Websockets, Server-Sent Events (SSE), or polling technologies. These mechanisms proactively push updates to the frontend when new data or status changes are available. For non-real-time requests, respond to frontend queries via a RESTful API, returning the latest business data.

[0064] 2.4.3 Step S402: Developing platform layer data processing logic:

[0065] Use state management tools (such as Redux or Vuex) to maintain the global state of the application so that UI components can be updated according to the latest data status.

[0066] 2.4.4 Step S403: Front-end UI update:

[0067] Based on the data processed by the platform layer, the front-end components automatically or manually trigger re-rendering to update the page display content, including order lists, itinerary details and payment status.

[0068] (IV) Mechanisms for resolving technical issues:

[0069] 4.1 Receiving requests and secure communication:

[0070] Secure data transmission via the WebSocket protocol is a key option for ride-hailing applications with high real-time requirements. Steps S100-S103 detail the entire process, from connection initialization, secure handshake verification, data frame construction and transmission, to back-end reception and decoding. This ensures efficient and secure data transmission, particularly through enhanced communication security through TLS / SSL integration.

[0071] 4.2 Real-time positioning and intelligent scheduling:

[0072] Steps S200-S203 cover the entire process, from real-time collection, storage, and caching of passenger location data to the use of a dispatch algorithm to screen nearby drivers and issue task notifications. The application of GeoHash technology, in particular, improves the efficiency of geolocation calculations.

[0073] 4.3 Efficient business processing and data analysis:

[0074] The engine layer handles complex business logic and data processing, including order creation, real-time billing, and asynchronous processing of log and data analysis. Step S302 utilizes the RabbitMQ message queue to process log and analysis tasks, avoiding the performance bottlenecks caused by direct database operations and ensuring the system's high concurrent processing capabilities.

[0075] 2.4 Information processing and front-end update:

[0076] Step S4 ensures that the results of backend processing are reflected in the front-end UI in real time and accurately, enhancing the user experience. Steps S400-S403 cover data standardization, the establishment of asynchronous communication mechanisms, the use of state management tools, and finally the UI update, forming a closed loop and ensuring the smooth transmission and presentation of information.

[0077] (5) Compared with the prior art, the beneficial effects of the present invention are:

[0078] (1) Accelerate the development and deployment cycle: The low-code platform of the present invention significantly reduces the complexity of traditional programming, allowing developers to quickly build and deploy functions through a graphical interface, preset modules and a small amount of custom code, greatly shortening the time from demand analysis to launch, and accelerating product iteration. Moreover, through componentized design and modular service architecture, this solution makes the system easier to expand and maintain. When it is necessary to add or modify specific industry functions, the development team can quickly insert or adjust the corresponding components without affecting the stable operation of the entire system. In addition, the adoption of the low-code platform reduces dependence on senior developers, allowing non-technical personnel to participate in the development of applications, reducing labor costs, and also providing a more convenient path for the digital transformation of enterprises.

[0079] (2) Improve system execution efficiency and security: This invention ensures data transmission security by integrating the WebSocket protocol with TLS / SSL encryption technology, preventing data from being stolen or tampered with during transmission, and improving user privacy protection. Furthermore, it utilizes NoSQL databases and Redis in-memory databases for real-time data storage and caching, reducing database access latency and increasing data processing speed. Combined with GeoHash technology, it achieves efficient geographic location calculation, improving the accuracy and response speed of the scheduling algorithm.

[0080] (3) Improved user experience: The real-time communication mechanism (WebSocket, SSE) of the present invention ensures instant information synchronization between passengers and drivers, reducing waiting time and improving the interactive experience. At the same time, through the global state maintained by the state management tool, the front-end UI can quickly respond to background data changes, making the user interface more smooth.

[0081] (4) Enhanced system stability and scalability: The asynchronous processing mechanism of the present invention (such as the message queue RabbitMQ) effectively disperses system pressure, avoids service crashes caused by high concurrent requests, and ensures stable system operation. As business volume grows, the system can easily cope with higher loads through horizontal expansion. BRIEF DESCRIPTION OF THE DRAWINGS

[0082] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0083] Figure 1 Schematic diagram of the method of the present invention. DETAILED DESCRIPTION

[0084] To make the above-mentioned objects, features, and advantages of the present invention more clearly understood, the following detailed description of the specific embodiments of the present invention is given in conjunction with the accompanying drawings. The following description sets forth many specific details to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways than those described herein, and those skilled in the art can make similar improvements without violating the scope of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0085] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. The devices disclosed in the embodiments are described briefly because they correspond to the methods disclosed in the embodiments. For relevant details, refer to the method description.

[0086] Example 1: Figure 1 As shown, this embodiment discloses a hierarchical structure of a development platform for online car-hailing backend, including:

[0087] Protocol layer: Real-time, two-way data transmission is ensured through data exchange formats (such as JSON) and the use of modern communication protocols such as WebSocket and gRPC. For online car-hailing scenarios, real-time and security are particularly enhanced, and real-time location updates and instant delivery of order requests are achieved through WebSocket. On this basis, TLS / SSL encryption technology is integrated to ensure that during the data transmission process, passenger privacy information (such as location data and payment information) is encrypted and protected to avoid data leakage. Its Java structure is as follows. The @ServerEndpoint annotation defines the URL path of the WebSocket service. The onOpen method is called when the client connects, and the onMessage method processes the received client messages, demonstrating how the protocol layer can securely receive and respond to client requests through the WebSocket protocol:

[0088]

[0089]

[0090] Component layer: provides reusable functional modules, including a map service component that integrates the Google Maps API, allowing developers to implement complex route planning functions through simple drag and drop operations. The real-time positioning component uses GPS data to provide accurate location information, and the scheduling algorithm component and billing logic component automatically match drivers and calculate fees based on location information and business rules. These components are exposed to the outside world through APIs or SDKs, reducing the complexity of customized development. Its Java structure is as follows, which obtains geographic location information from an external API (taking the Google Maps Geocoding API as an example), which corresponds to the function of the map service component in the component layer. Through HTTP GET requests, address information is obtained based on longitude and latitude, which demonstrates how to integrate external service components:

[0091]

[0092]

[0093]

[0094] The engine layer includes a business logic engine and a data processing engine, responsible for executing business processes and data operations. For high-concurrency processing, distributed processing technology and a microservices architecture are introduced, improving the system's processing power and response speed through load balancing and horizontal scaling.

[0095] It adopts a microservice architecture, splitting core functional modules (such as order processing and payment services) into independent services for easy individual expansion and maintenance.

[0096] At the same time, an integrated message queue (RabbitMQ) is used to process asynchronous tasks, reduce the pressure on the main database, and improve the system response speed.

[0097] Use Docker containerization technology for service orchestration to achieve automatic expansion and contraction of services.

[0098] The Java structure is as follows. The microservices architecture simplifies inter-service calls using tools like Spring Cloud Feign. The code above defines an interface that points to a remote microservice named "order-service" through the FeignClient annotation. The getOrderById method declares an HTTP GET request to retrieve order information. This approach supports high concurrency and load balancing, demonstrating the flexibility and scalability of the microservices architecture.

[0099]

[0100]

[0101] The platform layer provides a user interface and development environment, including a graphical drag-and-drop editor, a workflow designer, and a version control system. This layer supports non-technical users in application development while ensuring efficiency and collaboration throughout the development process. Its Java structure is as follows: a Spring Boot application startup class, annotated with @SpringBootApplication, automatically configures the Spring framework and quickly launches a web service. This provides a foundational service environment for building a low-code platform. Developers can then add advanced features such as graphical editors and workflow designers to support non-technical users in application development:

[0102]

[0103] Example 2: Figure 1 As shown, based on the hierarchical structure of Example 1, this embodiment further discloses a low-code development method for the backend of online car-hailing. In practical application, the following steps need to be performed:

[0104] In this embodiment, regarding step S1, receiving a request: when the protocol layer receives the request, it is securely transmitted to the backend via the WebSocket protocol;

[0105] Specifically, step S100, development request reception initialization: when the client application (such as the passenger or driver end) starts, it initiates a connection request to the server's WebSocket endpoint through the WebSocket client library (such as Java's javax.websocket client). The request carries an HTTP Upgrade header, indicating that the client intends to upgrade to the WebSocket protocol, and carries a Token as preliminary authentication information in the Upgrade header. This step ensures that only verified clients can establish a connection, thereby enhancing security. By integrating the authentication mechanism in the connection initialization phase, unauthorized access can be prevented, ensuring the security of data interaction, thereby protecting user privacy and system security.

[0106] Specifically, step S101 develops a secure handshake and verification: after receiving the Upgrade request, the server (using a Java Tomcat server in conjunction with WebSocket) verifies the validity of the Token. If the authentication is successful, the server responds with an HTTP 101 Switching Protocols response with a Sec-WebSocket-Accept header to complete the handshake process. At the same time, the TLS / SSL protocol is used to encrypt the entire handshake process and subsequent communications to ensure the confidentiality and integrity of data during transmission. Integrating TLS / SSL not only enhances the security of data transmission, but also increases users' trust in the platform, because all communication content is encrypted, effectively preventing man-in-the-middle attacks and data leakage, and providing security for the exchange of sensitive information on the online car-hailing platform.

[0107] Specifically, step S102, Developing Data Frame Construction and Transmission: This allows the client to send actual data frames via WebSocket. These data frames can include the request type (e.g., location update, order request), user ID, and geographic location information. Once the handshake is successful, the client and server can begin exchanging WebSocket data frames. The client constructs a data frame containing information such as the request type (e.g., location update, order request), user ID, and geographic location, and sends it over the WebSocket connection. The data frame format complies with the WebSocket protocol standard to ensure correct data parsing.

[0108] Specifically, in step S103, the back-end receives and decodes:

[0109] S1030, backend monitoring: The backend server uses a WebSocket framework (such as Spring WebSocket or Java WebSocket API in Java) to continuously monitor data frame events from the client.

[0110] S1031, Decoding: Upon receiving a data frame, the backend logic parses the header and payload of the WebSocket data frame to restore the original request data structure. This may involve decompression, decoding, and data formatting to ensure that the data can be understood and processed by the business logic layer.

[0111] Furthermore, the Java framework program of step S1 is as follows:

[0112]

[0113]

[0114]

[0115] Furthermore, in the above program, the @ServerEndpoint(" / ws") annotation marks that this is a WebSocket service endpoint, and the client can connect to this service through the " / ws" path. The OnOpen method is called when the client connects and is used to initialize connection-related operations, such as adding a new connection to the connection collection. The OnClose method is called when the connection is closed and is used to clean up resources, such as removing closed connections from the connection collection. The OnMessage method processes the received WebSocket message, which is a string type message here. In the backend application of the online car-hailing service, this part contains information such as location updates and order requests, which needs to be further parsed and the processRequest method is called for processing. The OnError method handles any errors that occur in the communication to ensure that the exceptions are properly handled. At the same time, the client can connect to the WebSocket server using JavaScript.

[0116] In this embodiment, regarding step S2, positioning is developed: the real-time positioning component of the component layer can obtain the passenger location in real time, and the scheduling algorithm component can assign the nearest driver based on the location information and the driver's status.

[0117] Specifically, step S200 is to develop real-time location data collection: integrate GPS positioning services in the passenger-side App, such as Android's Location API or iOS's CoreLocation framework, to continuously monitor and obtain the real-time geographic location information of passengers. Set a scheduled task (such as using Handler or Timer on Android, or using NSTimer on iOS) to collect location coordinates and timestamp data at fixed time intervals (such as every 5 seconds). Afterwards, through the established WebSocket connection, these data are encapsulated into a unified JSON format and sent to the back-end server. Through continuous and regular location data collection, it is ensured that the online car-hailing platform can grasp the location changes of passengers in real time and provide basic data for subsequent rapid scheduling. The balance between real-time and frequency (such as once every 5 seconds) not only ensures the timeliness of location information, but also avoids excessive consumption of device resources and network bandwidth. The choice of the WebSocket protocol, due to its full-duplex communication characteristics, ensures low latency and high efficiency of data transmission, thereby improving the passenger experience.

[0118] Specifically, step S201 develops data storage and caching: after the back-end server receives the location data, it uses a NoSQL database (such as MongoDB) for real-time storage. This type of database is suitable for processing high-concurrency writes and massive data, and is very suitable for storing semi-structured data such as location. At the same time, in order to quickly query and reduce database access pressure, the latest location information is stored in the Redis memory database. Redis's high-performance read and write capabilities make querying location data extremely fast. Combining the NoSQL database with the Redis cache strategy ensures persistent storage and high-speed access to data. The flexibility of the NoSQL database adapts to the diversification and rapid growth of location data, while the Redis cache mechanism significantly improves query performance and reduces the load on the main database, thereby improving the response speed and processing power of the entire system.

[0119] Specifically, step S202, develop query and calculation: the scheduling algorithm component regularly queries the latest passenger location information in Redis, and performs matching calculations in combination with the driver's status information (such as real-time location and status updates reported by the driver's side). Using GeoHash technology, the longitude and latitude coordinates are converted into string codes, which facilitates the establishment of spatial indexes in the database, so as to quickly find nearby drivers. Combined with the driver's real-time status (such as idle, carrying passengers), a list of qualified drivers is screened out. GeoHash technology maps two-dimensional geographic location coordinates to one-dimensional strings, making spatial location queries efficient and easy to index. In this way, the scheduling algorithm can quickly locate the nearest available driver, improving scheduling efficiency and accuracy. Combined with real-time updates of driver status, the immediacy and rationality of scheduling decisions are ensured, and the passengers' riding experience is improved.

[0120] Specifically, step S203 develops the logic for issuing assignment instructions: based on the calculation results, after selecting the most suitable driver, a task notification message is constructed through the background system, including passenger information, boarding location, estimated arrival time, etc., and sent to the driver-side App through WebSocket or message queue (such as RabbitMQ). After the driver receives the task notification, it updates the UI to prompt the driver to accept the order and navigate to the passenger's location. The use of instant messaging technology (WebSocket) or reliable message queues ensures the immediate transmission of task assignment instructions, avoids delays, and improves the driver's response speed. This instant feedback mechanism simplifies the driver's operating process, improves service response efficiency, and also enables scheduling decisions to be quickly implemented, improving overall service quality and operational efficiency.

[0121] Furthermore, the Java framework program for step S2 is as follows, where the client (such as an Android or iOS app) uses the corresponding positioning API to obtain location information and then sends it to the backend server via WebSocket. This part requires the Java backend to prepare a WebSocket service to receive this data:

[0122]

[0123]

[0124]

[0125]

[0126] In the above program, the client sends real-time location data via WebSocket, and the Java backend receives and stores it in MongoDB (persistence) and Redis (cache) to ensure data immediacy and query efficiency. GeoHash and spatial indexing technology are used to quickly find drivers near the passenger, and the best match is found through algorithm sorting to improve scheduling efficiency. The scheduling decision results are pushed to the driver in real time via WebSocket or message queue to ensure immediate response of the service. The combination of these links makes full use of various libraries and technologies in the Java ecosystem, such as Lettuce (Redis client), Spring Data MongoDB (MongoDB operations), JTS Topology Suite (geospatial computing), and WebSocket to build an efficient and scalable online car-hailing backend system.

[0127] In this embodiment, regarding step S3, the processing business is developed: the business logic engine in the engine layer is used to develop the order creation and billing logic, while the data processing engine is allowed to asynchronously process log records and data analysis through the message queue.

[0128] Specifically, in step S300, develop order creation logic:

[0129] (1) Front-end interaction design: Use the form and event handling components of the low-code platform to design the driver confirmation interface and collect driver ID, passenger ID, boarding location and destination information.

[0130] (2) Business logic definition: In the business logic engine, drag and drop to configure the "order creation" process. Define a trigger to automatically execute a series of actions when receiving the confirmation information submitted by the front end:

[0131] (2.1) Call the built-in function to generate a unique order number.

[0132] (2.2) Based on the information received, fill in the trip details such as starting point, destination, estimated distance and time.

[0133] (2.3) Apply built-in or custom billing rules to preliminarily calculate estimated costs.

[0134] (2.4) Use data manipulation components to persist order records to the database.

[0135] (2.5) Trigger the front-end and back-end communication modules, update the order status of the passenger and driver applications, and push notifications of successful order creation.

[0136] Specifically, step S301 involves developing real-time billing logic: Pre-create or integrate a billing component in the low-code platform's component library, which embeds a distance-, time-, and time-slot-based billing algorithm. During order creation, the billing component is called, the trip parameters are passed in, and the estimated cost is calculated in real time. At the end of the trip, the same component is called based on actual driving data (such as GPS trajectory) to complete the final cost settlement and trigger the payment process.

[0137] Specifically, step S302, asynchronous processing of logs and data analysis: During steps S300 to S301, log messages are sent via the RabbitMQ message queue. The data processing engine, acting as a consumer of the message queue, asynchronously receives and processes these log messages, persisting the data in a log database or data warehouse.

[0138] In this embodiment, regarding step S4, an information processing logic is developed: the processing result is returned to the platform layer through the engine layer, and the platform layer updates the front-end UI.

[0139] Specifically, step S400, Development Data Encapsulation and Verification: At the engine level, after business logic processing is complete (e.g., order creation success, billing calculation completion, or order status change), the results are automatically encapsulated into a unified JSON format using a pre-defined data model. This step may involve data validation to ensure that the output data conforms to the expected structure and data type requirements, such as using the Joi library to ensure data accuracy and consistency.

[0140] Specifically, step S401 involves developing an asynchronous communication mechanism. For scenarios requiring high real-time performance, such as instant order status updates, Websocket or Server-Sent Events (SSE) technology is used to establish a persistent, two-way communication channel. Once a status change occurs in the backend, it can be immediately pushed to the frontend via these channels, achieving real-time data synchronization.

[0141] For non-real-time query needs, a RESTful API interface is provided, and the front end can obtain the latest data through HTTP requests, such as order history query.

[0142] Specifically, step S402 involves developing platform-layer data processing logic. This involves utilizing the Redux state management tool to maintain the application's global state, enabling UI components to update based on the latest data. When new data received from the engine layer reaches the platform layer, the state stored in the store is updated using Redux's actions and reducer mechanisms. This centralized state management makes state changes predictable and traceable, making UI update logic clearer, easier to maintain, and easier to debug, while also improving the efficiency and consistency of data flow.

[0143] Specifically, step S403, front-end UI update: Based on modern front-end frameworks such as React or Vue, UI components automatically trigger re-rendering by subscribing to state changes in the Redux store. When data such as order lists, itinerary details or payment status is updated, the relevant components will automatically refresh the view to display the latest information. For scenarios where manual control of update logic is required, you can use React's useState and useEffect hooks (or Vue's corresponding lifecycle hooks) to listen to specific state changes and update the interface on demand. This mode ensures instant synchronization between the user interface and background data, providing a smooth user experience. Through the componentized automatic update mechanism, the front-end logic is simplified, the error rate is reduced, and the development efficiency is improved.

[0144] Furthermore, the Java execution program of step S4 is as follows:

[0145] (1) Define a Data Transfer Object (DTO) to encapsulate the data processed by the business logic and use JavaBean Validation for validation:

[0146]

[0147] (2) Use Spring WebFlux to build asynchronous responsive services, such as the following Websocket processor:

[0148]

[0149]

[0150] (3) The platform layer responds to REST requests through Spring's Controller and uses state management tools.

[0151] (4) The front-end UI is updated using a JavaScript framework. Once the back-end sends an update via Websocket, the front-end listens to the message and triggers UI re-rendering:

[0152]

[0153] As you can understand, data encapsulation and validation ensure the consistency and reliability of backend processing results, and Bean Validation simplifies validation logic. The asynchronous communication mechanism utilizes WebSockets for real-time, two-way communication, and the non-blocking nature of the Spring WebFlux framework supports efficient processing in high-concurrency scenarios. While the platform-level data processing logic is not fully presented, it is crucial that the backend be designed to be responsive, capable of handling asynchronous events and maintaining application state to ensure smooth data flow. Front-end UI updates utilize WebSockets to listen for update events pushed by the backend. Combined with the responsive nature of the front-end framework, this enables instantaneous refreshes of the user interface, enhancing the user experience.

[0154] All of the above embodiments merely represent implementation methods of the present invention in practical applications. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the scope of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the appended claims.

[0155] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0156] At the same time, those skilled in the art will understand that all or part of the processes in all the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. A low-code development method for online car-hailing backend, characterized in that: The development steps include: S1, receiving the request: When the protocol layer receives the request, it is securely transmitted to the backend via the WebSocket protocol; S2, develop positioning: enable the real-time positioning component of the component layer to obtain the passenger location in real time, and allow the dispatch algorithm component to assign the nearest driver based on the location information and driver status; S3, development and processing business: Use the business logic engine in the engine layer to develop order creation and billing logic, and let the data processing engine asynchronously process logging and data analysis through the message queue; S4, develop information processing logic: let the processing results be returned to the platform layer through the engine layer, and let the platform layer update the front-end UI.

2. The low-code development method according to claim 1, characterized in that: The implementation process of S1 is as follows: S100, development request reception initialization: when the client initiates a connection, a connection is established with the server through the WebSocket API; during this process, the client sends an upgrade request containing preliminary authentication information to a specified WebSocket endpoint; S101, develop secure handshake and verification: when the server receives a connection request, it responds with an HTTP to complete the handshake process of the WebSocket protocol; S102, developing data frame construction and transmission: allowing the client to send actual data frames through WebSocket; the data frames may include request type, user ID and geographic location information.

3. The low-code development method according to claim 2, characterized in that: In the S1, the back-end receiving and decoding are also included: S1030, backend monitoring: the backend server continuously monitors message events on the WebSocket connection; S1031, decoding processing: after receiving the data frame, the server decodes it, parses the data frame structure of the WebSocket protocol, and restores the original request data.

4. The low-code development method according to claim 1, characterized in that: The implementation process of S2 is as follows: S200, develop real-time location data collection: let the passenger-side App use GPS or other positioning technology to continuously collect location information, and send the location coordinates and timestamp data to the backend through a WebSocket connection at a preset time interval; S201, develop data storage and cache: use NoSQL database to store the received passenger location data in real time in the database, and cache the latest location information in Redis memory database; S202, develop query and calculation: use the dispatch algorithm component to regularly query the cache or database for the latest location of the passenger, and combine the driver's current location and status to filter out a list of nearby drivers; S203, develop the logic for issuing allocation instructions: send a task notification to the selected driver-side App through the background system, including passenger information, boarding location and estimated arrival time.

5. The low-code development method according to claim 4, characterized in that: In the S202, GeoHash spatial database indexing technology is also introduced to calculate the distance between the passenger and each candidate driver.

6. The low-code development method according to claim 1, characterized in that: The implementation process of S3 is as follows: S300, develop order creation logic: When the driver accepts the task, he receives confirmation information from the front-end or driver-side application, including driver ID, passenger ID, pickup location and destination; S301, develop real-time billing logic: calculate the estimated cost of the trip based on the trip distance, estimated driving time and time period rate.

7. The low-code development method according to claim 6, characterized in that: In the S3, log and data analysis are also processed asynchronously: When executing S300 to S301, log messages are sent through the RabbitMQ message queue. The data processing engine, as a consumer of the message queue, asynchronously receives and processes these log messages and stores them in a log database.

8. The low-code development method according to claim 1, characterized in that: The execution flow of S4 is as follows: S400, development data encapsulation and verification: After the engine layer completes the business logic processing, it organizes and standardizes the processing results into JSON format; S401, develop asynchronous communication mechanism: use polling technology to establish a real-time communication channel between the backend and the frontend; S402, develop platform layer data processing logic: use state management tools to maintain the global state of the application so that UI components can be updated according to the latest data state.

9. The low-code development method according to claim 8, characterized in that: In S4, the method for updating the front-end UI is: based on the data processed by the platform layer, the front-end component automatically or manually triggers re-rendering to update the page display content, including the order list, itinerary details and payment status.

10. A storage medium, characterized in that: The storage medium stores program instructions that can implement the low-code development method as described in any one of claims 1-9.

Images