Cross-technology stack application system data synchronization method and system based on responsive hook and data chain

Abstract

This invention provides a method and system for data synchronization across technology stack application systems based on reactive hooks and data chains, relating to the field of distributed system data interaction. The method constructs a data chain hub as an intermediate layer for data synchronization between cross-technology stack application systems, introducing the data chain as an abstract channel for data transmission. In front-end applications supporting reactive hooks, declarative data subscription and automatic updates are achieved by calling reactive hooks. Any connected application system can publish data changes to the data chain, and the hub automatically broadcasts them to all subscribers. This invention employs a version vector mechanism to detect concurrent conflicts and supports multiple conflict resolution strategies, including last-write-wins, automatic merging, and manual resolution. This invention extends the reactive programming paradigm of React to cross-technology stack application systems, solving the problems of high coupling, high development complexity, and lack of conflict detection mechanisms in existing cross-technology stack data transmission.

Description

Technical Field

[0001] This invention relates to the field of distributed system data interaction technology, specifically to a cross-technology stack application system data synchronization method and system based on reactive hooks and data chains. Background Technology

[0002] As enterprises deepen their digital transformation, modern information system architectures are becoming increasingly complex. Within the same organization, there are often multiple application systems developed using different technology stacks, such as front-end applications based on the React framework, management back-ends based on Vue.js, mobile applications based on Angular, and back-end microservices built using languages ​​such as Java, Python, and Go. These cross-technology stack application systems require frequent data exchange and state synchronization.

[0003] However, different technology stacks have fundamental differences in their state management philosophies: 1. React uses unidirectional data flow and a functional programming paradigm, managing component state through `useState` and `useReducer`. 2. Vue uses a reactive proxy mechanism, achieving two-way data binding through `ref` and `reactive`. 3. Angular uses the RxJS observer pattern, processing asynchronous data through Observable streams. 4. Backend services rely on middleware such as message queues and caching systems for state management. This technological heterogeneity leads to the need to write a large amount of adaptation code when transmitting data between systems, resulting in high system coupling and high maintenance costs.

[0004] With the increasing popularity of micro-frontend architectures, an enterprise portal may simultaneously host multiple sub-applications developed by different teams using different frameworks. For example, the order module might be developed using React, the inventory module using Vue, and the reporting module using Angular, with close data dependencies between these modules. When inventory data changes, it needs to be synchronized in real time to the inventory display area of ​​the order module, the statistical charts in the reporting module, and the caching layer of the backend service. Traditional solutions require developers to manually manage these cross-system data flows, which not only increases development complexity but also easily introduces the risk of data inconsistency.

[0005] Therefore, there is an urgent need for a solution that can shield the differences in underlying technologies and provide a unified data transfer abstraction, enabling developers to achieve real-time data synchronization between application systems across technology stacks in a declarative and reactive manner. Summary of the Invention

[0006] Purpose of the invention: The purpose of this invention is to propose a data synchronization method and system for cross-technology stack application systems based on reactive hooks and data chains. By introducing a new technical abstraction layer of data chains, the reactive programming paradigm of React (useState / useEffect) is extended to cross-technology stack application systems.

[0007] In a first aspect, the present invention proposes a data synchronization method for cross-technology stack application systems based on reactive hooks and data chains, the method comprising: Step S1: Deploy the data chain hub service in a distributed environment as the core intermediate layer for data synchronization across technology stack application systems, and establish and maintain the data chain registry. Step S2: Implement data link adapters that conform to a unified interface specification for application systems with different technology stacks, and connect the heterogeneous application systems to the data link hub service through the data link adapters; Step S3: In the front-end application, subscribe to the specified data chain identifier by calling a reactive hook, which encapsulates the subscription logic and creates a local state copy; Step S4: Any application system that has been connected to the data chain hub service publishes data changes to the target data chain through its corresponding data chain adapter, triggering the data chain hub service to execute the change processing procedure and broadcast the current data changes to all subscribers; Step S5: The data chain hub service detects concurrent conflicts through the version vector mechanism and handles them according to the preset conflict resolution strategy to ensure data consistency.

[0008] As a preferred embodiment of the first aspect, in step S1, the data chain registry uses the data chain identifier as the key, and each key corresponds to a data chain instance containing data snapshots, version vectors, subscriber sets, conflict resolution strategies, and change history.

[0009] As a preferred embodiment of the first aspect, in step S2, the data link adapter implements a unified interface specification, which includes at least the core capability interfaces for connecting, subscribing, unsubscribing, publishing, and obtaining snapshots.

[0010] As a preferred embodiment of the first aspect, in step S3, the responsive hook combines the state management hook, the lifecycle hook, and the context acquisition hook to automatically update the local state copy and trigger component re-rendering when it receives the change data broadcast by the data chain hub service.

[0011] As a preferred embodiment of the first aspect, in step S3, after the component is mounted, the reactive hook initiates a subscription request to the data chain hub service through the data chain adapter and obtains the current initial snapshot of the data chain for the first rendering.

[0012] As a preferred embodiment of the first aspect, in step S4, the change processing flow includes: verifying the publisher's permissions, updating the data snapshot of the data chain instance, incrementing the version vector component corresponding to the publisher, recording the change event to the history array, and traversing the subscriber set to execute callback broadcasts.

[0013] As a preferred option in the first aspect, the specific detection logic of step S5 is as follows: Compare the version vector carried in the request with the version vector of the current system. If all components of the request vector are greater than the corresponding components of the current vector, it is determined to be a sequential write. If all components of the request vector are less than the corresponding components of the current vector, it is determined to be an expired request and rejected. Otherwise, it is determined to be a concurrent conflict (i.e., the components in the request vector contain both those greater than the corresponding components of the current vector and those less than the corresponding components of the current vector).

[0014] As a preferred embodiment of the first aspect, the conflict resolution strategy includes a last-write-wins strategy, an automatic merging strategy, and a manual resolution strategy.

[0015] A second aspect of the present invention provides a cross-technology stack application system data synchronization system, which can execute the cross-technology stack application system data synchronization method based on reactive hooks and data chains disclosed in the first aspect and its preferred embodiments. The system includes: The data chain hub module is used to deploy the data chain hub service in a distributed environment, serving as the core middleware for data synchronization across technology stack application systems, and to establish and maintain the data chain registry. The unified adapter module is used to implement data link adapters that conform to the unified interface specification for application systems with different technology stacks, and to connect heterogeneous application systems to the data link hub module through the data link adapters. The responsive subscription module is used to call a responsive hook in the front-end application to subscribe to a specified data chain identifier. The responsive hook encapsulates the subscription logic and creates a local state copy. Any application system that has been connected to the data chain hub module publishes data changes to the target data chain through its corresponding data chain adapter, triggering the data chain hub to execute the change processing flow and broadcast the changes to all subscribers. The conflict management module is used to call the concurrent conflict detected by the data link hub module and resolve the concurrent conflict according to the preset conflict resolution strategy.

[0016] As a preferred option in the second aspect, the synchronization system supports real-time data synchronization between front-end frameworks including React, Vue, and Angular, as well as back-end microservices.

[0017] Compared with the prior art, the technical solution of the present invention has the following technical effects: (1) The distributed data transmission is abstracted into the concept of a "chain". Each data chain represents a data channel that can be subscribed to and published by multiple cross-technology stack application systems. Existing technologies such as message queues, WebSocket, and EventBus do not provide this level of abstraction. The data chain completely decouples where the data is stored from how the data is used. Developers do not need to care about the technology stack from which the data comes; they only need to declare the data chain identifier.

[0018] (2) Extends React's useState / useEffect reactive programming paradigm to cross-technology stack scenarios, with the API format being completely consistent with useState. React's official useState is limited to the state within a component, useContext is limited to the state within the same application, and useSyncExternalStore is limited to a single external storage. This solution is the first to achieve reactive state synchronization across technology stacks and application boundaries, with zero learning cost for developers.

[0019] (3) Provide a unified IDataChainAdapter interface specification for different technology stacks such as React, Vue, Angular, and backend services. Existing micro-frontend solutions (single-spa, qiankun) have different communication mechanisms and cannot interoperate with the backend. The unified interface defined in this solution allows any technology stack to access the data chain ecosystem simply by implementing this interface, greatly reducing integration costs.

[0020] (4) Introduce the version vector mechanism of distributed systems into the front-end field to achieve professional-grade concurrent conflict detection in the browser environment. Existing front-end solutions generally adopt a simple last-write-overwrite strategy, which cannot detect and handle concurrent conflicts. This solution provides three detection results (SEQUENTIAL / STALE / CONFLICT) and multiple solution strategies to ensure data consistency.

[0021] (5) Developers only need one line of code: `const [data, update] = useDataChain(chainId)` to complete all the work of subscription, state management, and resource release. Using WebSocket requires manually managing connection, listening, reconnection, and cleanup logic. Using message queues requires writing producer / consumer and serialization / deserialization code. This solution significantly reduces complexity.

[0022] (6) Automatically unsubscribe when a component is uninstalled to prevent memory leaks and updates to the state of uninstalled components. Manually managing the subscription lifecycle is a common pain point and source of bugs in front-end development. This solution uses React's useEffect cleanup mechanism to achieve automatic resource release and completely eliminate this problem.

[0023] (7) All data changes are recorded with publisher ID, publisher type, timestamp, and version vector, supporting complete audit traceability. Existing solutions generally lack change tracking capabilities. The historical record mechanism of this solution facilitates problem investigation and compliance auditing, and has significant value in highly regulated industries such as finance and healthcare. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating the data synchronization method for cross-technology stack application systems based on reactive hooks and data chains, as described in this invention. Detailed Implementation

[0025] In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without one or more of these details. In other instances, certain technical features well-known in the art have not been described in order to avoid obscuring the invention.

[0026] To facilitate understanding of the specific implementation methods that follow, some existing technologies will be described first.

[0027] Existing distributed data synchronization solutions mainly focus on the backend system level. For example, CRDT, Conflict-free Replicated Data Types, has achieved significant results in the field of distributed databases, but its implementation complexity is high and it is difficult to apply directly to frontend development scenarios. Version Vector technology is widely used in distributed storage systems, such as conflict detection in Amazon DynamoDB and Apache Cassandra, but there is still no mature solution to introduce it into frontend reactive frameworks.

[0028] In the industry, cross-framework communication in micro front-end architecture mainly relies on the following methods: (1) WindowCustomEvents custom events, which require manual registration / removal of listeners and are disconnected from React lifecycle management; (2) window global variable sharing, which lacks type safety and change tracking; (3) parcel communication mechanism provided by orchestration frameworks such as single-spa, but it is limited to use within the framework and cannot be extended to backend services.

[0029] Message queues (RabbitMQ / Kafka). Based on the producer-consumer pattern, they use middleware to broker message delivery. However, they have the following problems: front-end applications cannot directly integrate them, requiring back-end services to relay messages, increasing system complexity; message queues are designed for asynchronous communication between back-end services and lack integration capabilities with front-end reactive frameworks; they cannot trigger automatic re-rendering of React / Vue components, requiring manual polling or the establishment of additional push channels; configuration is complex, with a steep learning curve, making them unsuitable for direct use by front-end developers.

[0030] RESTful APIs are based on the HTTP request-response model, where the client actively initiates data requests. This approach has the following problems: it is essentially a pull model, making it impossible for the server to proactively push data changes; a polling mechanism is required to obtain real-time data, resulting in numerous invalid network requests and wasting bandwidth and server resources; the polling interval is difficult to balance—too long an interval leads to data latency, while too short an interval results in performance overhead; and data consistency between multiple clients cannot be guaranteed, posing a risk of race conditions.

[0031] WebSocket, based on a full-duplex communication protocol, establishes persistent connections for bidirectional communication. However, it suffers from the following problems: it only provides a low-level communication channel, lacking upper-level data protocol specifications, requiring developers to design message formats and routing mechanisms themselves; connection state management is complex, requiring handling issues such as reconnection after disconnection, heartbeat keep-alive, and connection pool management; it is disconnected from the state management systems of frameworks like React / Vue, failing to automatically trigger reactive component updates; and it lacks version control and conflict detection mechanisms, potentially leading to data overwriting during concurrent writes from multiple clients.

[0032] BroadcastChannel. Based on the browser's native API, it broadcasts messages between pages from the same origin. It has the following problems: strict same-origin policy restrictions prevent cross-domain and cross-port communication; it only supports browser environments, and backend services cannot be integrated; it lacks fine-grained control over subscription / publishing, resulting in all pages from the same origin receiving the broadcast; and it lacks data persistence capabilities, causing state loss upon page refresh.

[0033] Redux / Zustand / Pinia is a centralized state management library based on the Flux architecture. It suffers from the following problems: its design goal is state management within a single application, making it unable to pass state across application boundaries; React's Redux, Vue's Pinia, and Angular's NgRx are isolated and cannot communicate with each other; state is stored in JavaScript runtime memory, making it impossible to share between different browser tabs or application instances; and it lacks network transmission capabilities, preventing direct communication with backend services.

[0034] In summary, current technologies have not yet provided a solution that can extend React's reactive programming paradigm to cross-technology stack application systems, achieving a loosely coupled, declarative, and traceable data synchronization solution. Existing technologies face the following pressing technical challenges in the field of cross-technology stack application system data synchronization: 1. Limitations of the reactive programming paradigm. The reactive mechanisms (useState / useEffect) of front-end frameworks such as React are limited to state management within a single application and cannot achieve reactive data synchronization across application boundaries and technology stacks.

[0035] 2. Inconsistent interfaces across technology stacks. React, Vue, Angular, and backend services each use different state management paradigms and communication protocols, lacking a unified data transfer interface specification, resulting in high complexity in system integration and high maintenance costs.

[0036] 3. The lack of declarative data subscription. Existing solutions (WebSocket, message queues, etc.) all adopt an imperative programming style, requiring developers to manually manage low-level details such as connection establishment, subscription registration, and resource release, resulting in verbose and error-prone code.

[0037] 4. Lack of concurrent conflict detection mechanism. Existing front-end solutions generally lack a professional concurrent write conflict detection mechanism, which may lead to data overwriting and inconsistency when multiple application systems modify the same data at the same time.

[0038] 5. Insufficient traceability of data changes. The existing solution lacks a complete record of the source, time, and version of data changes, making it difficult to support audit traceability and problem investigation.

[0039] To this end, this invention discloses a data synchronization method for cross-technology stack application systems based on reactive hooks and data chains. By introducing a new technical abstraction layer, data chains extend React's reactive programming paradigm (useState / useEffect) to cross-technology stack application systems, including the following steps: Step S1: Construct the Data Chain Hub and establish a data chain registry. Deploy the data chain hub service in a distributed environment. This service serves as the core middleware layer for data synchronization across application systems using different technology stacks. It is responsible for maintaining the data chain registry, managing the data chain lifecycle, and handling data publishing and broadcasting. The data chain hub adopts a centralized architecture design, with all heterogeneous application systems connecting to the hub service through their respective adapters. Internally, the hub maintains a data chain registry, which is a Map data structure with the chain identifier (chainId) as the key. Each key corresponds to a complete data chain instance. When an application system requests to create a new data chain, the hub allocates a new entry in the registry. When all subscribers unsubscribe, the hub can selectively reclaim the data chain resource.

[0040] Step S2: Heterogeneous Application Systems Connect to the Data Chain Hub (Unified Adapter Integration). Implement data chain adapters conforming to a unified interface specification for application systems with different technology stacks. The adapter is the bridge connecting heterogeneous applications and the data chain hub; it encapsulates the underlying communication protocol and provides standardized API interfaces. The Adapter Pattern is the core design pattern of this step. Regardless of whether the underlying technology stack is React, Vue, Angular, or a Java backend service, its adapter must implement the unified IDataChainAdapter interface. This design allows the data chain hub to be unconcerned about the technology implementation of the connected parties, only needing to process requests according to the interface specification. For React applications, the adapter is injected into the component tree through the Context mechanism; for Vue applications, the adapter is injected through the provide / inject mechanism; for Java backend services, the adapter is provided as an SDK.

[0041] Step S3: React applications subscribe to data chains via reactive hooks (Reactive Hook Subscription). In React applications, developers subscribe to a specified data chain by calling a custom hook, useDataChain(chainId). This hook encapsulates all the logic, including subscription, state management, automatic updates, and resource release, allowing developers to achieve cross-system data synchronization with just one line of code. useDataChain is the core innovation of this solution. It extends React's useState semantics (declarative state management) to cross-system scenarios. Traditional useState can only manage the internal state of components, while useDataChain can subscribe to data changes from any heterogeneous system. Its underlying implementation cleverly combines four core React hooks: (1) useContext, which obtains the data chain adapter instance, serving as the entry point to the central hub; (2) useState, which creates a local copy of the state, storing the data obtained from the data chain; (3) useEffect, which handles the subscription lifecycle, including subscription creation and cleanup; and (4) useCallback, which caches the dispatch method to avoid unnecessary re-rendering.

[0042] Step S4: Cross-Stack Data Publishing – Any heterogeneous application publishes data changes to the data chain. Any application system connected to the data chain hub, whether it's a React application, a Vue application, or a Java backend service, can publish data changes to the data chain through its respective adapter. The publishing operation triggers a series of processing flows in the hub, ultimately broadcasting the changes to all subscribers. The publishing operation is one of the core functions of the data chain hub. When an application system calls `adapter.publish(chainId, data)`, the hub receives a `PUBLISH` type Action. The Reducer then executes the following processing logic in sequence: permission verification, snapshot update, version vector increment, history check, and broadcast notification. This process ensures the atomicity, consistency, and traceability of data changes.

[0043] Step S5: Conflict Detection and Resolution (Version Vector Conflict Resolution). Conflicts may occur when multiple heterogeneous application systems concurrently publish changes to the same data chain. This step detects conflicts using a version vector mechanism and resolves them according to a preset strategy. Version vectors are a classic data structure used in distributed systems to track causal relationships and are widely used in distributed databases such as Amazon DynamoDB and Apache Cassandra. This solution innovatively introduces version vectors into the front-end domain to detect concurrent write conflicts between application systems across different technology stacks. A version vector is a mapping with node ID as the key and version number as the value. Each node increments its version component when publishing data. By comparing two version vectors, the causal relationship between the two operations can be determined.

[0044] In a further embodiment, the specific details of step S1 are disclosed: Step S1.1: Define the DataChainInstance interface. The DataChain is the core abstraction of this solution. Each data chain represents a data channel that can be subscribed to and published by multiple cross-technology stack application systems. The core principle is that the data chain decouples where the data is from how it is used. Application systems do not need to care whether the data originates from a React application or a Java service; they only need to subscribe to the corresponding chain identifier.

[0045] Step S1.1.1: Define a unique chain identifier, chainId, in the DataChainInstance interface. The format is: Business Domain: Self-Descriptive Entity ID, such as: inventory:SKU-001.

[0046] Step S1.1.2: Define a subscriber collection (subscribers) in the DataChainInstance interface. The subscriber collection is a Map structure, using the subscriber ID as the key to store subscriber information and callback functions.

[0047] Step S1.1.3: Define the current snapshot in the DataChainInstance interface to store the latest data value on the data chain.

[0048] Step S1.1.4: Define a version vector (versionVector) in the DataChainInstance interface for causal tracking and conflict detection in a distributed environment.

[0049] Step S1.1.5: Define the conflict resolution policy configuration `conflictPolicy` in the DataChainInstance interface to determine how to handle conflicts during concurrent writes.

[0050] Step S1.1.6: Define the deliveryPolicy configuration in the DataChainInstance interface to determine how data is delivered to subscribers (synchronous / asynchronous / batch, etc.).

[0051] Step S1.1.7: Define a change history array `history` in the DataChainInstance interface to record all data change events and support audit traceability.

[0052] Step S1.1.8: Define the data chain creation timestamp createdAt in the DataChainInstance interface.

[0053] Step S1.1.9: Define the last update timestamp updatedAt in the DataChainInstance interface.

[0054] Step S1.2: Define a version vector type, VersionVector. A version vector is a data structure used in a distributed system to track causal relationships. Each node maintains a logical clock counter, incrementing its counter when it publishes data. By comparing two version vectors, the order of two operations or the existence of concurrent conflicts can be determined. Example: { "react-app-1": 3, "vue-app-2": 5, "java-service": 2}, indicating that react-app-1 was published 3 times, vue-app-2 was published 5 times, and java-service was published 2 times.

[0055] Step S1.3: Define the conflict resolution strategy by enumerating ConflictPolicy. When two application systems simultaneously publish data to the same data chain, the data chain hub needs to decide how to handle this concurrent conflict based on the policy.

[0056] Where: LAST_WRITE_WINS indicates that the last write wins, FIRST_WRITE_WINS indicates that the first write wins, MERGE indicates that non-conflicting fields are automatically merged, and MANUAL_RESOLVE indicates that manual resolution is required.

[0057] Step S1.4: Define the delivery policy enumeration DeliveryPolicy. Different business scenarios have different real-time requirements for data delivery. By configuring the delivery policy, a balance can be achieved between real-time performance and performance.

[0058] Where: SYNC indicates synchronous transmission, ASYNC_BATCH indicates asynchronous batch transmission, DEBOUNCE indicates debouncing transmission, and THROTTLE indicates throttling transmission.

[0059] Step S1.5: Define the state change action type DataChainAction.

[0060] Step S1.5.1: Define the data chain creation action CREATE_CHAIN ​​in the state change action type DataChainAction. When the first application system attempts to subscribe to a data chain, if the chain does not exist, the creation action is triggered. The input parameters are: the unique identifier of the data chain chainId, the initial data snapshot of the data chain initialData, and the conflict resolution policy conflictPolicy.

[0061] Step S1.5.2: Define the `SUBSCRIBE` action in the state change action type `DataChainAction`. Corresponding to step S3, the heterogeneous application initiates a subscription request to the data chain hub through the adapter. The execution timing is when the React component mounts and calls `useDataChain`; the Hook internally sends the subscription request to the hub through the adapter. The callback mechanism is that after successful subscription, any change to the data chain will trigger a callback. The React component updates its local state in the callback, thereby triggering a re-render. The input parameters are: the data chain identifier `chainId` to be subscribed to, the subscriber's unique identifier `subscriberId`, and the data change callback function `callback`.

[0062] Step S1.5.3: Define the unsubscribe action UNSUBSCRIBE in the state change action type DataChainAction. When the React component is unloaded, the cleanup function of useEffect is called, triggering the unsubscribe action and removing the subscriber from the subscriber list. The input parameters are: the chain identifier chainId to be unsubscribed from and the subscriber identifier subscriberId to be removed.

[0063] Step S1.5.4: Define the data publishing action PUBLISH in the state change action type DataChainAction. Corresponding to step S4, any heterogeneous application publishes data changes to the data chain. The execution flow is as follows: verify publisher permissions, update the current data snapshot of the data chain, increment the version vector component corresponding to the publisher, record the change event to the history array, and broadcast the change to all subscribers. The input parameters are: target data chain identifier chainId, data content to be published data, publisher identifier publisherId, and publisher type identifier publisherType (REACT / VUE / BACKEND, etc.).

[0064] Step S1.5.5: Define the ADD_LOG event log action in the DataChainAction state change action type. This records data chain operation logs, allowing developers to visualize data chain subscription, publishing, broadcasting, and other operations during development and debugging, thus helping them understand data flow.

[0065] Step S1.5.6: Define the connection status setting action SET_CONNECTED in the state change action type DataChainAction. This identifies the connection status with the data chain hub and triggers reconnection logic upon disconnection.

[0066] In a further embodiment, specific details of step S2 are disclosed: Step S2.1: Define the Unified Adapter Integration for Heterogeneous Application Systems Accessing the Data Chain Hub. Implement data chain adapters conforming to a unified interface specification for application systems with different technology stacks. The adapter acts as a bridge connecting heterogeneous applications and the data chain hub, encapsulating the underlying communication protocol and providing standardized API interfaces. The Adapter Pattern is the core design pattern of this step. Regardless of whether the underlying technology stack is React, Vue, Angular, or a Java backend service, the adapter must implement the unified IDataChainAdapter interface. This design allows the data chain hub to be unconcerned about the technology implementation of the connected parties, only needing to process requests according to the interface specification. For React applications, the adapter is injected into the component tree through the Context mechanism; for Vue applications, the adapter is injected through the provide / inject mechanism; for Java backend services, the adapter is provided as an SDK.

[0067] The execution process for heterogeneous application systems to access the data chain hub is as follows: (1) When the application system starts, it instantiates the data chain adapter corresponding to the technology stack. (2) The adapter establishes a connection with the data chain hub through WebSocket or HTTP long polling. (3) The adapter sends a registration request to the hub, carrying the node identifier and supported capabilities. (4) The hub confirms the registration and returns a connection success confirmation. (5) The application system performs subsequent subscription / publishing operations through the API provided by the adapter.

[0068] Step S2.1.1: Define the unified interface IDataChainAdapter for the data chain adapter. This interface defines the five core capabilities that a data chain client must possess: connect, subscribe, unsubscribe, publish, and get snapshot.

[0069] Step S2.1.2: Define the connection to the data chain hub service `connect` in the `IdataChainAdapter` interface. This is executed when the application system starts, establishing a persistent connection with the hub. The underlying implementation uses WebSocket for full-duplex communication, with the input parameter being the data chain hub's connection address `hubUrl`, such as `wss: / / datachain.example.com`.

[0070] Step S2.1.3: Define the `subscribe` function in the `IdataChainAdapter` interface to subscribe to the specified data chain. This function is executed when the application system needs to monitor changes to a particular data chain. The callback is triggered when new data is published on the data chain. Input parameters include: the unique identifier of the data chain (e.g., `inventory:SKU-001`) and the callback function that occurs when data changes.

[0071] Step S2.1.4: Define the unsubscribe function in the IdataChainAdapter interface to unsubscribe from the specified data chain. This is called when the application system no longer needs to listen to a particular data chain. After unsubscribing, the subscriber will no longer receive change notifications. The input parameter is the chainId identifier of the data chain to be unsubscribed from.

[0072] Step S2.1.5: Define the `publish` function in the `IdataChainAdapter` interface to publish new data to the data chain. This function is called when the application system needs to update data on the data chain. The broadcast mechanism ensures that after successful publication, the central hub will broadcast the new data to all subscribers. Input parameters are: the target data chain identifier (`chainId`) and the data object to be published (`data`).

[0073] Step S2.1.6: Define the `getSnapshot` function in the `IdataChainAdapter` interface to retrieve the current data snapshot of the data chain. This is executed after subscribing to the data chain and obtaining the latest data. The application scenario is when a component needs to display the current data immediately upon mounting, rather than waiting for the next change. The input parameter is the data chain identifier (`chainId`).

[0074] Step S2.1.7: Define the `getVersion` vector to retrieve the current version of the data chain in the `IdataChainAdapter` interface. This is called when a data version check or conflict detection is needed. The application scenario is optimistic locking, checking for version expiration before release. The input parameter is the data chain identifier `chainId`.

[0075] Step S2.2: Define the React application access method. The core principle is: using the typical Provider pattern of React Context, by wrapping the Provider at the top level of the component tree, child components at any depth can access the data chain adapter through useContext without passing props layer by layer.

[0076] Step S2.2.1: Define the DataChainProvider component. Input parameters are: child components (children), the WebSocket address of the data chain hub (hubUrl), and the unique identifier of the current node (nodeId).

[0077] The usage method is as follows: <datachainprovider huburl="wss: / / ..." nodeid="react-app-1"> <app / > < / datachainprovider> ; Step S2.2.2: Define a global state method in the DataChainProvider component that uses `useReducer` to manage the data chain hub. The data chain hub undergoes various state changes, such as creating a chain, publishing data, subscribing, and unsubscribing. Managing these changes with `useReducer` provides clearer management. `state` represents the current state of the data chain hub, `dispatch` represents the dispatch function, `dataChainReducer` represents the state handler, and `initialState` represents the initial state.

[0078] Step S2.2.3: Define a method in the DataChainProvider component that uses useRef to save the latest state reference.

[0079] Step S2.2.4: Define a method in the DataChainProvider component to update the ref to the latest state each time it is rendered.

[0080] Step S2.2.5: Define an adapter instance in the DataChainProvider component, implementing the unified data chain adapter interface IDataChainAdapter. The adapter instance depends on an empty array to ensure that the adapter instance is created only once.

[0081] Step S2.2.6: Define the `connect` method in the `adapter` instance to establish a connection with the central hub. The input parameter is the WebSocket address of the data link central hub.

[0082] Step S2.2.7: Define the `subscribe` method in the adapter instance to register a subscription with the central hub. The input parameters are: the unique identifier of the data chain to be subscribed to (`chainId`) and the callback function for data changes.

[0083] Step S2.2.8: Define the unsubscribe method in the adapter instance. The input parameter is the identifier of the data chain to be unsubscribed from.

[0084] Step S2.2.9: Define the `publish` method in the adapter instance. The input parameters are: the target data chain identifier (`chainId`) and the data object to be published (`data`).

[0085] Step S2.2.10: Define the `getSnapshot` method in the adapter instance. The input parameter is the data chain identifier (chainId).

[0086] Step S2.2.11: Define the `getVersion` method in the adapter instance. The input parameter is the chain identifier (`chainId`).

[0087] Step S2.2.12: Inject the adapter and state into the component tree in the component DataChainProvider using Context.Provider.

[0088] This design perfectly embodies the innovative aspect of unified access in this solution. Components from different technology stacks can access the data chain through a unified Context, without needing to concern themselves with the specific implementation of the underlying adapter. All functions, including data retrieval, change subscription, automatic updates, and resource management, can be accomplished with a single line of code using `useDataChain(chainId)`. This is the core innovation of declarative programming in this solution, and the key architectural design for achieving unified data synchronization across technology stacks is the use of the Context mechanism.

[0089] In a further embodiment, specific details of step S3 are disclosed: Step S3.1: Define the React application's subscription data chain via reactive hooks (Reactive HookSubscription) In React applications, developers subscribe to a specified data chain by calling a custom Hook, useDataChain(chainId). This Hook encapsulates all the logic, including subscription, state management, automatic updates, and resource release. Developers only need one line of code to achieve cross-system data synchronization. useDataChain is the core innovation of this solution. It extends React's useState semantics (declarative state management) to cross-system scenarios. The traditional useState can only manage the internal state of a component, while useDataChain can subscribe to data changes from any heterogeneous system. Its underlying implementation cleverly combines four core React Hooks: (1) useContext: Gets the data chain adapter instance, which is the entry point to the hub. (2) useState: Creates a local copy of the state and stores the data obtained from the data chain. (3) useEffect: Handles the subscription lifecycle, including subscription establishment and cleanup. (4) useCallback: Caches the dispatch method to avoid unnecessary re-rendering.

[0090] The execution flow of a React application subscribing to a data chain via reactive hooks is as follows: (1) When the component is rendered for the first time, useDataChain is called; (2) The adapter in DataChainContext is obtained through useContext; (3) Local state data is created using useState, with an initial value of null; (4) useEffect is executed after the component is mounted, calling adapter.subscribe() to subscribe to the data chain; (5) After successful subscription, the initial snapshot is obtained and set; (6) When new data is published on the data chain, the callback function is triggered, calling setData() to update the local state; (7) React detects the state change and automatically re-renders the component; (8) When the component is unloaded, the cleanup function of useEffect is executed, calling adapter.unsubscribe() to cancel the subscription.

[0091] Step S3.1.1: Define a reactive data chain subscription Hook, useDataChain. The generic parameter T represents the data type in the data chain. The input parameter is the data chain identifier, chainId.

[0092] Example of use: Subscribing to the inventory data chain: const [inventory, updateInventory] = useDataChain <inventorydata>('inventory:SKU-001'); Data used: Current inventory: {inventory?.quantity} Update data (published to the data chain, received by all subscribers): updateInventory({...inventory, quantity: 100}); Step S3.1.2: Obtain the data chain adapter. Obtain the adapter instance injected by DataChainProvider through the React Context mechanism. The adapter is the bridge connecting the component and the data chain hub.

[0093] Step S3.1.3: Define the local state `data`. Use `useState` to create a copy of the local state `data` to store data retrieved from the data chain. When `setData` is called, React will automatically trigger a component re-render.

[0094] Step S3.1.4: Establish a subscription. Use `useEffect` to handle the subscription lifecycle: establish the subscription, retrieve initial data, and clean up the subscription. The dependency array is the data chain identifier `chainId` or the data chain adapter `adapter`. This step is repeated whenever any element in the array changes.

[0095] Step S3.1.5: Generate a unique subscriber ID in useEffect. The subscriber ID is used to uniquely identify this subscription instance in the hub, and its format is: subscriber-timestamp-random string.

[0096] Step S3.1.6: Define the data change callback function handleDataChange in useEffect. When new data is published in the data chain, the central hub will call this callback. Inside the callback, setData is called to update the local state, triggering React to re-render.

[0097] Step S3.1.7: In useEffect, initiate a subscription request to the data chain hub. Call the adapter's subscribe method to register the callback function handleDataChange with the hub. Afterward, any publish to this data chain will trigger handleDataChange.

[0098] Step S3.1.8: Obtain an initial snapshot of the data chain in useEffect. Upon successful subscription, immediately retrieve the latest data for the component's initial render. This ensures that the component displays the latest data upon mounting, rather than waiting with a blank screen.

[0099] Step S3.1.9: Return the cleanup function in useEffect. React calls the cleanup function to unsubscribe when the component is unloaded or dependencies change.

[0100] Step S3.1.10: Define the `dispatch` method to create a data publication in the `useDataChain` subscription hook of the reactive data chain. Call the `publish` method of the adapter to send the data to the data chain hub. Upon receiving the data, the hub will update the snapshot, increment the version, and broadcast it to all subscribers. Use `useCallback` to cache the `dispatch` function, avoiding the creation of a new function for each render, which would cause unnecessary re-rendering of dependent child components. The dependency array is either `chainId` or `adapter`, and it is recreated whenever either element in the array changes.

[0101] Step S3.1.11: Define the return data and update method in the reactive hook useDataChain. The return format is exactly the same as useState, which is: [current value, update function]. This design allows developers to use cross-system data in a familiar way.

[0102] In a further embodiment, specific details of step S4 are disclosed: Step S4.1: Define Cross-Stack Data Publishing for arbitrary heterogeneous applications publishing data changes to the data chain. Any application system connected to the data chain hub, whether it's a React application, a Vue application, or a Java backend service, can publish data changes to the data chain through its respective adapter. The publish operation triggers a series of processing flows in the hub, ultimately broadcasting the changes to all subscribers.

[0103] The publish operation is one of the core functions of the data chain hub. When an application system calls adapter.publish(chainId, data), the hub receives an Action of type PUBLISH. The Reducer executes the following processing logic in sequence: (1) Permission verification: Verify whether the publisher has the right to publish data to the data chain; (2) Update snapshot: Update the currentSnapshot of the data chain to the new data; (3) Increment version vector: Increment the version component corresponding to the publisher by 1; (4) Record history: Create a ChangeEvent object and append it to the history array; (5) Broadcast change: Traverse the subscriber list and call the callback function of each subscriber.

[0104] Step S4.1.1: Define the PUBLISH Action method for the data chain hub to handle publish requests. Deconstruct the various parameters of the publish request from the Action payload, where: chainId is the target data chain identifier, data is the new data to be published, publisherId is the publisher identifier, used for version vectors, and publisherType is the publisher type (REACT / VUE / BACKEND).

[0105] Example of an Action object structure: { type: 'PUBLISH', payload: { chainId: string, data: any, publisherId: string, publisherType: string}}; where type is the action type and payload is the payload data.

[0106] Step S4.2: Define the method for updating data snapshots Step S4.2.1: Create a shallow copy of the data chain instance to avoid directly modifying the original object.

[0107] Step S4.2.2: Update the current snapshot with the newly published data.

[0108] Step S4.2.3: Update the last modified timestamp.

[0109] Step S4.3: Define an incrementing version vector. A version vector is an object with node ID as the key and version number as the value. Each node increments its corresponding version component when publishing data. For example: { "react-app": 3, "vue-app": 2} -> { "react-app": 4, "vue-app": 2}; Step S4.4: Define record event changes Step S4.4.1: Create a change event object changeEvent, which contains complete change context information.

[0110] Step S4.4.2: Create a new change event record in the changeEvent object. The specific attributes of the record include: a unique identifier for the change event, changeId: generateId(), the changed data content, version vector snapshot at the time of the change, timestamp: Date.now(), publisher identifier, and publisher type.

[0111] Step S4.4.3: Append the change event to the history array (immutable update).

[0112] Step S4.5: Broadcast the change to all subscribers Step S4.5.1: Iterate through the subscriber Map, call the callback function registered by each subscriber, and pass in the latest data. For React components, the callback will call setData internally, triggering a re-render. The core mechanism of the data chain to achieve reactivity is: publisher publishes -> central broadcast -> subscriber callback -> React state update -> component re-render.

[0113] Step S4.5.2: Create a new Map object newChains so that React can detect state changes.

[0114] Step S4.5.3: Put the updated data chain instance into the new Map object newChains.

[0115] Step S4.5.4: Return the new state object. Expand all properties of the original state and replace the original chains object with the updated newChains object.

[0116] In a further embodiment, the specific details of step S5 are disclosed: Step S5.1: Conflict Detection and Resolution (Version Vector Conflict Resolution) When multiple heterogeneous application systems concurrently publish changes to the same data chain, conflicts may occur. This step detects conflicts using a version vector mechanism and resolves them according to a preset strategy. Version vectors are a classic data structure used in distributed systems to track causal relationships and are widely used in distributed databases such as Amazon DynamoDB and Apache Cassandra. This solution innovatively introduces version vectors into the front-end domain to detect concurrent write conflicts between application systems across different technology stacks.

[0117] A version vector is a mapping where node ID is the key and version number is the value. Each node increments its version component when publishing data. By comparing two version vectors, the causal relationship between two operations can be determined, such as: Happened-Before: If all components of vector A are less than or equal to vector B, and at least one component is strictly less than, then A occurred before B. Concurrency: If neither A precedes B nor B precedes A, then the two operations are concurrent and conflict.

[0118] Step S5.1.1: Define the version vector conflict detection algorithm detectConflict. The input parameters are the current version vector currentVV of the data chain and the version vector requestVV carried in the publication request.

[0119] The comparison rules for the version vector conflict detection algorithm detectConflict are as follows: (1) If all components of the request vector are greater than the corresponding component of the current vector, then it is a sequential write (acceptable).

[0120] (2) If all components of the request vector are less than the corresponding component of the current vector, then it is an expired request (which can be rejected).

[0121] (3) Otherwise, there will be concurrent conflicts, which need to be resolved according to the strategy.

[0122] Step S5.1.2: Initialize the comparison flag isGreaterOrEqual to determine if it is greater than all current components.

[0123] Step S5.1.3: Initialize the comparison flag isLessOrEqual and check if it is less than all current components.

[0124] Step S5.1.4: Obtain the union of all node IDs, allKeys, to get all the nodes that appear in the two vectors that need to be compared.

[0125] Step S5.1.5: Traverse all nodes and compare the component versions one by one.

[0126] Step S5.1.6: In the traversal, obtain the current vector current and the corresponding component request of the request vector. If they do not exist, the value is 0.

[0127] Step S5.1.7: Update the comparison flags isGreaterOrEqual and isLessOrEqual.

[0128] Step S5.1.8: Return the collision detection result based on the comparison result and accept SEQUENTIAL. If the request is greater than the current one, sequential writes are acceptable.

[0129] Step S5.1.9: Return the conflict detection result based on the comparison result and reject STALE. If the request is less than the current one, reject the expired request.

[0130] Step S5.1.10: The remaining cases are incomparable, and the concurrency conflict CONFLICT is returned.

[0131] Step S5.2: Define conflict resolution strategy Finally, the winning data is written to LAST_WRITE_WINS. The latest timestamp change is used as the benchmark, overwriting previous data. This is suitable for scenarios where data consistency requirements are not high, such as user preference settings. Advantages: Simple implementation, no manual intervention required. Disadvantages: May lose valid updates.

[0132] Automatic MERGE. Automatically merges non-conflicting field changes; only conflicting fields require handling. Suitable for structured data scenarios where different fields are maintained by different systems. Advantages: Preserves updates from all parties to the greatest extent possible. Disadvantages: Conflicts within the same field still need to be handled.

[0133] Manually resolve MANUAL_RESOLVE. Push the conflict to manual handling. Suitable for scenarios with extremely high data accuracy requirements, such as financial data. Advantages: Ensures data accuracy. Disadvantages: Requires manual intervention, slower response time.

[0134] Step S5.2.1: Define the conflict resolver `resolveConflict`. Input parameters are: conflict resolution policy, current data snapshot `currentData`, newly released data `newData`, current version vector `currentVersion`, and new version vector `newVersion`. Returns the resolved data `newData`.

[0135] Step S5.2.2: Define the conflict resolution method based on the strategy in the conflict resolver resolveConflict definition.

[0136] Step S5.2.3: If it is: case 'LAST_WRITE_WINS'. Use the last write wins rule, compare timestamps, and keep the latest one.

[0137] Step S5.2.4: If it is: case 'MERGE', use the auto-merge rules to merge the fields of the two objects.

[0138] Step S5.2.5: If the case is 'MANUAL_RESOLVE', use the manual resolution rule to return a conflict flag for manual handling.

[0139] Step S5.2.6: The last write winner LAST_WRITE_WINS is used by default.

[0140] The following example uses the real-time inventory synchronization scenario of an e-commerce platform to illustrate how to use this method to achieve real-time inventory synchronization on an e-commerce platform. Three applications are available: React application A: A consumer-facing product details page that needs to display real-time inventory levels.

[0141] Vue Application B: An administrative backend for operations staff, which requires viewing and modifying inventory.

[0142] Java microservice C: Inventory Service, responsible for the core business logic of deducting inventory from orders.

[0143] Pain points of using traditional technologies: (1) Consumers see that the product is available on the product page, but are told that the stock is insufficient when placing an order. (2) After the operations staff modifies the inventory in the backend, the consumer cannot perceive it in real time. (3) After the order service deducts the inventory, the data updates on different display terminals are not synchronized.

[0144] Step 1: Deploy the data link hub The data link hub is initialized and configured, either on the server or in a separate process.

[0145] Step 2: Integrate the React application Define the React consumer application entry file App.tsx. Wrap DataChainProvider in the application root node, specifically in the App's return method, where ProductDetail is the product details page component.

[0146] Step 3: Subscribe to the inventory data chain Step 3.1: Define the React product details page component ProductDetail.tsx. Subscribe to the inventory data chain using useDataChain, returning the same format as useState: [current data, update method]. Where: inventory: represents the current inventory data, initially null; updateInventory: represents the method to update the inventory (publish to the data chain).

[0147] Step 3.2: Component rendering, displaying the UI based on inventory data. Add the following functionality to the `return` method of the `ProductDetail.tsx` component in the product details page: current inventory, inventory status, update time, update source, etc., as shown in the example below: Current inventory: {inventory?.quantity ?? 'Loading...'} Inventory status: {inventory?.quantity>0 ? 'In Stock' : 'Out of Stock'} Update time: {inventory?.updatedAt ? new Date(inventory.updatedAt).toLocaleString() : '-'} Update source: {inventory?.updatedByType ?? '-'} Step 4: Modify inventory in the Vue backend Step 4.1: The function to handle inventory modifications in the Vue admin backend is called when an operations staff member modifies the inventory in the backend. The input parameter is the inventory quantity, newQuantity.

[0148] Step 4.2: In the handleUpdateStock method, construct a new inventory data object newInventory.

[0149] Step 4.3: Publish the new inventory object to the data chain. The `updateInventory` method comes from `useDataChainHook`. After it is called, the data chain hub will broadcast the new data to all subscribers. React application A will automatically receive the update, triggering a UI re-render.

[0150] Step 5: Java service processes order deductions Step 5.1: The Java inventory service handles the order deduction logic. After a user successfully places an order, the order service calls the `handleOrderDeduction` method. The input parameter is the order quantity `orderQuantity`.

[0151] Step 5.2: In the handleOrderDeduction method, construct the deducted inventory data object newInventory.

[0152] Step 5.3: Publish the inventory data object `newInventory` to the data chain via the adapter. The Java service uses the backend adapter (`DataChainClient`). After successful publication, both the React and Vue applications will receive the deducted inventory data.

[0153] The implementation results are verified as follows: (1) When a user browses products on React application A, the component subscribes to the inventory data chain through useDataChain('inventory:SKU-001'); (2) The operations staff modifies the inventory to 1000 units in Vue application B and calls publish to release the change; (3) The data link hub receives changes, updates the snapshot, increments the version vector, and broadcasts it to all subscribers; (4) The useDataChain callback of React application A is triggered, and setData updates the local state; (5) React detects the state change and automatically re-renders the ProductDetail component, displaying the current inventory as 1000 on the page; (6) When a user places an order for 5 items, Java service C deducts the inventory and publishes a new snapshot with a quantity of 995. (7) React application A and Vue application B receive the change at the same time, and the interface is automatically updated to 995.

[0154] As described above, although the invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the invention itself. Various changes in form and detail may be made without departing from the spirit and scope of the invention as defined in the appended claims.< / inventorydata>

Claims

1. A data synchronization method for cross-technology stack application systems based on reactive hooks and data chains, characterized in that, Includes the following steps: Step S1: Deploy the data chain hub service in a distributed environment as the core intermediate layer for data synchronization across technology stack application systems, and establish and maintain the data chain registry. Step S2: Implement data link adapters that conform to a unified interface specification for application systems with different technology stacks, and connect the heterogeneous application systems to the data link hub service through the data link adapters; Step S3: In the front-end application, subscribe to the specified data chain identifier by calling a reactive hook, which encapsulates the subscription logic and creates a local state copy; Step S4: Any application system that has been connected to the data chain hub service publishes data changes to the target data chain through its corresponding data chain adapter, triggering the data chain hub service to execute the change processing procedure and broadcast the current data changes to all subscribers; Step S5: The data chain hub service detects concurrent conflicts through the version vector mechanism and handles them according to the preset conflict resolution strategy to ensure data consistency.

2. The data synchronization method for cross-technology stack application systems based on reactive hooks and data chains according to claim 1, characterized in that, In step S1, the data chain registry uses the data chain identifier as the key, and each key corresponds to a data chain instance containing data snapshots, version vectors, subscriber sets, conflict resolution strategies, and change history.

3. The data synchronization method for cross-technology stack application systems based on reactive hooks and data chains according to claim 1, characterized in that, In step S2, the data link adapter implements a unified interface specification, which includes at least the core capability interfaces for connecting, subscribing, unsubscribing, publishing, and obtaining snapshots.

4. The data synchronization method for cross-technology stack application systems based on reactive hooks and data chains according to claim 1, characterized in that, In step S3, the reactive hook combines state management hooks, lifecycle hooks, and context acquisition hooks to automatically update the local state copy and trigger component re-rendering when it receives change data broadcast by the data chain hub service.

5. A data synchronization method for cross-technology stack application systems based on reactive hooks and data chains according to claim 4, characterized in that, In step S3, after the component is mounted, the reactive hook initiates a subscription request to the data chain hub service through the data chain adapter and obtains the current initial snapshot of the data chain for the first rendering.

6. The data synchronization method for cross-technology stack application systems based on reactive hooks and data chains according to claim 1, characterized in that, In step S4, the change processing flow includes: verifying publisher permissions, updating the data snapshot of the data chain instance, incrementing the version vector component corresponding to the publisher, recording change events to the history array, and traversing the subscriber set to execute callback broadcasts.

7. A cross-technology stack application system data synchronization method based on reactive hooks and data chains according to claim 1, characterized in that, The specific detection logic for step S5 is as follows: The version vector carried in the request is compared with the version vector of the current system. If all components of the request vector are greater than the corresponding components of the current vector, it is determined to be a sequential write; if all components of the request vector are less than the corresponding components of the current vector, it is determined to be an expired request and rejected; otherwise, it is determined to be a concurrent conflict.

8. A data synchronization method for cross-technology stack application systems based on reactive hooks and data chains according to claim 1, characterized in that, The conflict resolution strategies include the last-write-wins strategy, the automatic merging strategy, and the manual resolution strategy.

9. A cross-technology stack application system data synchronization system, used to execute the cross-technology stack application system data synchronization method based on reactive hooks and data chains as described in any one of claims 1 to 8, characterized in that, include: The data chain hub module is used to deploy the data chain hub service in a distributed environment, serving as the core middleware for data synchronization across technology stack application systems, and to establish and maintain the data chain registry. The unified adapter module is used to implement data link adapters that conform to the unified interface specification for application systems with different technology stacks, and to connect heterogeneous application systems to the data link hub module through the data link adapters. The responsive subscription module is used to call a responsive hook in the front-end application to subscribe to a specified data chain identifier. The responsive hook encapsulates the subscription logic and creates a local state copy. Any application system that has been connected to the data chain hub module publishes data changes to the target data chain through its corresponding data chain adapter, triggering the data chain hub to execute the change processing flow and broadcast the changes to all subscribers. The conflict management module is used to call the concurrent conflict detected by the data link hub module and resolve the concurrent conflict according to the preset conflict resolution strategy.

10. A cross-technology stack application system data synchronization system according to claim 9, characterized in that, This synchronization system supports real-time data synchronization between front-end frameworks including React, Vue, and Angular, as well as back-end microservices.

Images