Practice of ELE. me in API — build API Everything framework

To put it simply, back-end services are exposed in the form of apis and serve as the front end to access the middle layer of the back end. API Everything ADAPTS SOA service interfaces to external parties for access.

In our previous development, there was no layering at the back end, instead we wrote the business logic directly in the Web API layer and even accessed the database directly. However, the style of Web API is different, which is not conducive to communication and collaboration between teams.

API documentation is also prone to obsolescence and does not reflect code changes in a timely manner. Another common problem is that front-end and back-end development is out of sync, with the front-end waiting for back-end API development to complete.

The most fundamental principles we established when building the API Everything framework were stability, performance, high availability, and fault tolerance. In addition, the DevOps hub is configured into the framework to enable business teams to resolve problems they encounter using API Everything themselves.

Other principles include automation, code as documentation, user experience, and functional requirements. The code, called documentation, extracts comments from the code, eliminating the need for developers to create additional API documentation. The user experience is designed for developers to make the development process easier.

In addition to product principles, we also need to consider the entire API life cycle. As the middle layer between SOA and the front end, API Everything’s life cycle generally consists of PROCESSES such as API development, API management, API gateway, AND API operation and maintenance. The figure above lists the details that need to be considered in each life cycle, for example, documents and mocks should be taken into account during API development, and access rights, stream limiting and gray scale issues should be considered during API management.

Based on the consideration of product principles and life cycle, we put forward a sound product planning. API Portal is responsible for extracting documents from code, API mocks, access permissions, limiting greyscale, and API splicing, primarily defining the API.

After the definition is complete, Stargate Cluster implements functions, including authentication, protocol installation, alarm monitoring, deployment and expansion, and API clipping. MockServer contains an implementation of Mock functionality, not just a Mock API but also a Mock SOA, which can be implemented before the SOA is ready. The final API, Robot, is mainly test related functionality.

The front end reaches the circle SOA service through Nginx access, where gray indicates normal access to the service and red indicates Mock access through query String first. Stargatecluster will invoke SOA services relative to the API Portal prepared API definitions. API Robot consumes API definitions for API testing and regression testing.

• API document generation automation: After code comments and annotations are written, the code is submitted and the API documentation is available.

• Automatic API code generation: SOA interfaces are automatically mapped to Http interfaces through annotations, and code is generated.

• API deployment automation: Automatically deploys corresponding Web apis when SOA services are deployed.

• API Mock automatic generation: Mock data is automatically generated based on the API Model, supporting functions.

• API automatic alarm monitoring: The system automatically monitors and alarms all links for each application.

Stargate Cluster runs on docker. The ELESS in the upper right corner of the figure is the internal release environment of Ele. me. When the SOA environment is released, Stargate_core will be called, and then MaxQ will be consumed by Stargate operation management service, and finally Stargatenodes will be notified for analysis.

The figure shows the specific deployment environment of Stargate Cluster. Traffic reaches Nginx from f5apI-xxx.ele. Me and then reaches Docker through upstream.

Here are some logs of the deployment, including deployment messages, whether the deployment was successful, and changes.

This document is relatively front-end friendly, and the back end may prefer the intuitive presentation of data. There will be some discussion, versioning, change comparison and so on.

After the API is committed to Git, the publishing system creates a build. When the BUID is complete, the API documentation is automatically generated. Through the public APIs in the figure, relevant people can be notified of the message completed by the API. The person receiving the message can come to the API interface to discuss and leave a message, which will be forwarded to the API developer.

The ServiceProvider in the figure needs to rely on the following services, which you can Mock using the Mock Server.

Once you put the dependency into the Mock, the Mock Server automatically resolves the method contained in the dependency or API package and can add the Mock case itself.

Earlier we talked about stargate Luster, API Portal, Mock Server, and other tools that can be used independently. These tools will work well together in the practice of back-end development separation. This is a flow chart of the development process, showing how all the pieces fit together.

Our front end is basically Mock related through the API Portal. The back end, originally intended to write Web Controllers and their corresponding tests, can now automate the generation of Web apis through the Stargate Cluster. In the previous development, it was often the case that some functions were left to be developed during the joint commissioning, so that the joint commissioning time became longer. Now the front and back ends are developed independently, and the joint tuning time is significantly reduced.

The API Everything framework seems to solve all the problems, but there are still some shortcomings.

We envision API Robot recording online traffic and then playing it back. The recorded traffic is played back to the new system to test for problems with the new system.

Many things need to be recorded to perform regression testing, including SOA1 and SOA2 dependencies, third-party applications, Redis, and Database. Bottom-up requests from the client also need to be recorded according to the time point, and then the appropriate sequence, namely Case, is extracted through integration analysis. The whole process is quite complicated.

That’s all for today’s sharing, thank you!