This article was first published on my wechat official account: Coder Xiaohei
Pain of service unbundling
After a service split, arguments about API granularity between the front and back end classmates become more common:
“Front-end students request two interfaces, aggregation of data on the line?” The back-end students want to only provide basic API service capabilities in the business field, while the data assembly and processing are expected to be completed by the front-end students.
“Back end aggregation, front end can have one less request, just page rendering!” The front-end students hope to be only responsible for page rendering, while the same aggregation logic of H5, APP and small program may appear in three ends, while the back-end aggregation only needs one time.
Interface aggregation services are one solution.
What is the interface aggregation service?
Interface aggregation service is a porter, just to help the front end students to aggregate the return data of multiple interfaces, after aggregation to return the result of the corresponding request to the client. We want to use the interface aggregation service as the middle layer so that the front end can get the data directly, while the back end can continue to focus on providing the underlying business domain API service capabilities.
Scenario analysis
- Scenario 1: Obtaining data in serial mode. Multiple requests are associated.
- For example, you can obtain comment information based on the product ID and user information based on the UID in the comment
- Scenario 2: Obtain data in parallel. Multiple requests without association.
- For example, obtain product information, activity information, and purchase information of current users by commodity ID
Project research
| Plan A | Plan B | |
|---|---|---|
| The caller | The client | The client |
| API-Server | Since the research | GraphQL |
| Payload | convention | GraphQL |
| Response | convention | GraphQL |
| Fault tolerance | convention | convention |
| Dynamically selected field | is | is |
Finally, we chose scheme A to solve this problem by developing A set of simple interface aggregation intermediate layer.
Hence, the interface aggregation service: apI-Aggregator. The framework has the following characteristics:
-
Core code in a thousand lines or so, lightweight implementation.
-
Non-invasive to existing code, no need to modify existing services and code adaptation, existing interface can be directly used.
-
Interface provides ApiAggregatePostProcessor expansion point to intervention at various stages of polymerization, scalable.
-
Friendly to the front end, front end students can customize the return data structure, support dynamic field selection.
-
The interface aggregation logic communicates with the API-aggregator directly through the configuration file. The new aggregation interface does not need to be published.
Api-aggregator: interface aggregation service
Api-aggregator believes that an aggregation interface should be aggregated from the return results of several interfaces, so at design time, we divide it into two parts: interface meta-information and aggregation logic between interfaces.
ApiDefinition: interface meta information
ApiDefinition not only defines the meta information of the interface, but also describes the source of the parameters required by the interface.
Api-aggregator considers that in an interface aggregation, the parameters of the meta-information interface may come from the following sources:
- It is passed directly from the client, i.e. the parameters are fetched directly from HttpRequest.
- From the return value of the previous interface. For example, you can obtain comment information based on the product ID and user information based on the UID in the comment. In this case, the UID parameter needs to be obtained from the return value of the previous interface.
ResponseDefinition: aggregation logic between interfaces
ResponseDefinition describes the aggregation logic between interfaces. Through the ResponseDefinition front end, students can customize the data structure returned by the interface or dynamically select the required fields.
Without the ResponseDefinition, the apI-Aggregator simply aggregates the data from the two interfaces horizontally (as shown in the upper left figure). Now we can use the ResponseDefinition to define the return structure to give the front-end students a better development experience (as shown above).
A brief talk about design
The configuration file is preloaded
Interface aggregation configuration information is configured by the front-end developer in the management background.
After the front-end students submit the configuration file, the API-Aggregator will do some static analysis on the configuration file: analyze the interface dependency, whether there is cyclic dependency and other problems.
To improve performance, the API-Aggregator directly caches relevant configuration information in memory after parsing it to reduce the repeated parsing of the same configuration file. Meanwhile, the API-Aggregator periodically refreshes the PUB/SUB of MQ to ensure data consistency.
Simplified HTTP request model
The API-Aggregator abstracts HttpMethodInvoker to make HTTP requests. The Supplier gets the return result, masking API differences between Http clients.
Remember the scene mentioned above?
Scenario 1: Obtaining data in serial mode. Multiple requests are associated.
Scenario 2: Obtain data in parallel. Multiple requests without association.
In apI-Aggregator, the two scenarios are simplified and combined.
First of all, when the API-Aggregator parses the configuration file to analyze the interface dependencies, it provides an OPTIMAL HTTP request flow according to the interface dependencies, rather than requests in sequence according to the interfaces defined in the configuration file.
Here’s an example:
Suppose that in an interface aggregation, you need to request interfaces A, B, and C, and the data of interface B depends on interface A. The request parameters of interface A and interface C can be obtained directly from HttpRequest.
So, in the actual interface aggregation process, the API-Aggregator would first request interface A and interface C, then block the return result of interface A, and finally request interface B.
Provide extension points
API – aggregator provides convenient ApiAggregatePostProcessor to follow-up extension.
Through ApiAggregatePostProcessor, API – aggregator can intervene the whole process of an interface polymerization, such as: cache interface information, increasing the monitor log and so on.
Although ApiAggregatePostProcessor can interface to intervene in the polymerization process, but still want to add a new Processor need to restart the API – aggregator. As an interface aggregation point, apI-Aggregator, similar to a gateway, is also a traffic concentration point. In future releases, Groovy scripts may be considered to support dynamic startup and deactivation of processors.
In the comments section, thank you for reading
Welcome to pay attention to personal public account:
