Preface

In the formal access to Easy-Es to the production environment before, you must have a variety of concerns, including but not limited to performance, security, scalability, etc. ... After all, we are not Spring open source nor Alibaba open source, what makes the user trust us? These relate to the survival of a framework, as EE authors, These issues I considered before the development, but the user does not know, so I am here to help you crush these concerns. If your team leadership does not agree to access Easy-Es in the project, you may want to give this PPT (opens new window) a look before making a decision, Guan Yu was just a horse archer when he killed Hua Xiong with wine.

1. Performance

In the formal access to Easy-Es to the production environment before, you will certainly be worried about a problem, is the use of this framework, the system's query efficiency will become lower? system resource overhead will become larger? How much negative impact there is? These issues are related to the survival of a framework , as EE authors , these issues I considered before the development , but the user does not know , so I am here to help you crush these concerns .

Let’s first take a look at what EE did during the entire query process? The core matters can be summarized in 2 things (of course, it is only abstracted to facilitate your understanding. The actual complexity will only be known after you have read the source code or developed with ES native API. experience):

1. convert the MySQL syntax (Mybatis-Plus syntax) entered by the user into RestHighLevel syntax, and then call RestHighLevelClient to execute the query

2. convert the query result into the format the user wants: e.g. List<T> and return.

• In this case, the syntax conversion is done according to the relationship between MySQL and EE syntax comparison. This conversion actually consumes very little performance because even if you use RestHighLevelClient directly for the query, you still need to create a termQueryBuilder and a BoolQueryBuilder. The only difference is that I put the query condition eq entered by the user into the queue, and then pass the queue FIFO (except for the case where the query For most of the query statements, the query conditions are not too many, so the number of elements in the queue will be less than 10 in most cases, and I only store the enumerations and parameters in the queue, which will not take up too much memory and will not consume much performance because of the queue traversal. For modern computers, let alone traversing 10 small data, that is, hundreds of thousands of milliseconds, so this performance loss is basically negligible

• Say the results of parsing, the results of parsing is actually the call to RestHighLevelClient returned SearchResponse in the hits out and fastJson into an array, this process even without EE, you directly use RestHighLevelClient is also this step, so this step does not have too much loss, even if I used reflection, field reflection and annotation information, are loaded into memory at the start of the framework, do jvm cache, so this loss is negligible.

Of course, as above is based on theoretical analysis, in the test module Performance test class, you can see that I made different dimensions of performance testing for CURD , the actual test results are also good evidence of my theoretical analysis above, EE in addition to the query will be an average of 10-15 milliseconds slower than the direct use of RestHighLevelClient, Add, delete, and change API is no difference, and with the increase in the amount of query data, the entity field cache takes effect, the query difference will be further reduced to almost negligible. The sacrifice of 10 milliseconds, the user is not perceptible, but for development, you can save a lot of code and time, I think it is worth it, basically no ORM framework is not loss of performance, weighing the pros and cons, the Lord's psychology should have the answer.

2. Security

We have access to OSCS Murphy security scan, ee source code has not been scanned for any risk items (beyond 100% of the project), to ensure that animals and humans are harmless! You can rest assured that you can use , of course, if you are still unsure , we recommend that you download the ee source code before using to read some of them personally , we are 100% open source , whether there is a risk you will know. In addition, all three parties in this framework depend on the elastic search official es suite of operations and RestHighLevelClient, Ali's fastJson, SpringbootAutoConfig, Apache commons-codec and Lombok, no two-party dependencies, empty mouth yellow teeth, mouth, you can click on the maven central repository, see for yourself: maven central repository (opens new window) Even if you don't use EE, you will use the above packages in your actual development, and they are all official, so you don't need to worry. So is it possible that EE has security problems? After all, it is written by individual developers, without the strong endorsement of the previously mentioned framework. First of all, I think any framework may have security risks, even if there is a strong corporate endorsement, such as a while ago Ali FastJson security vulnerabilities. For EE, I personally believe that there will not be particularly serious security problems, EE framework of the core principles of the above chart has been listed, EE's core principle is only conversion, equivalent to a translation or intermediary, and no other operations involving security classes, plus the EE framework itself is very lightweight, did not introduce any redundant class libraries, all tool classes are their own package, the package also refers to the apache tool classes , so there is reason to believe that the use of EE is relatively safe , unless the official downstream dependency itself has a security hole . In addition, FastJson has been controversial, its performance is indeed the current market deserves a brother, indeed fast enough, the security aspects of the words before because of AutoType problems and hackers staged a story of the magic high road high, so many people mistakenly believe that it is full of holes, in fact, it is not so bad, before the frequent vulnerability is essentially a problem. Ali internal still so many projects in the use of FastJson, as long as its community is active, and actively deal with, can be considered for use, after all, no framework can guarantee that there is no vulnerability, but has not been found. The current reliance on fastjson for its latest version, Murphy scan without any vulnerabilities. Our unit test cases comprehensive coverage rate of more than 95%, all the features that have gone live have test case coverage, and after the production environment and open source community to verify the use of a large number of users, please feel free to use .

3. Extensibility

EE underlying the official RestHighLevelClient provided by Es, we only enhance the RestHighLevelClient , and did not change to reduce or weaken its original function , so you do not need to worry about scalability . The use of any framework will reduce the flexibility of the system, because the framework is dead, the use of some scenarios will inevitably encounter the framework can not meet the need for custom development, or short-term you do not understand the framework itself, do not dare to use, or how to encounter problems later? In order to solve the above problem, I specifically left in the framework of mixed query and native query Currently all the APIs provided by EE can cover 99% of the actual development needs, when a very small probability of 1% of the needs can not be covered, you can use a mixed query, that is, the statements supported by EE generated, can not support the statements directly with RestHighLevelClient syntax, and then through the native interface to complete the query, both simple and trouble-free. Of course, if you do not like this "hybrid" approach, you can also directly use the native query interface to complete the query, and directly using RestHighLevelClient the same. Of course, if you really do not want to use any of the methods provided by EE, EE can still be used as an automatically configured version of RestHighLevelClient, directly injecting RestHighLevelClient where needed to use it, EE has helped you to RestHighLevelClient in accordance with your configuration file specified in the configuration, automatically assembled into SpringBean, so in any case, you can be very confident and comfortable, as directly using the official RestHighLevelClient, simply do not need to worry about the day the problem how to do, the big deal is not to use EE, just use it as a tool for introducing dependencies and automatic configuration. And the possibility of this is also very low, we have a special Q&A group to give you free online support, your reasonable needs will also be the first to respond and arrange for the implementation. EE is transparent to all projects, zero code intrusion, the introduction of your current project does not affect all the features, you can still use RestHighLevelClient after the introduction of all the features, and you can enjoy a variety of EE provides you with out-of-the-box features and intelligent suite of free hands.

4. Team and community activity

The team currently recruited to 5 people, I call it "five tigers", from 0.9.5 + version after the start of TeamWork, the future with the development of the project will recruit more aspiring people to join, the community is currently active, will issue many versions each year, and constantly improve the user experience, for users to mention the demand will respond within a week, a reasonable project will be established within a month, the development will be completed within three months online. Issue problems will be solved within two weeks after confirmation and go online.

5. Access advantages

• I don't need to tell you how easy it is to use and how efficient it is, MyBatis-Plus users know it all! Save a lot of time and do... What you love to do, smells good!
• Lower the threshold of use, even if you just do not know Es white, you can also use EE to develop a variety of functions
• Significantly reduce the amount of code, enhance code readability, reduce the amount of repetitive code, improve code quality
• Professional answer team, worry-free after-sales service
• Free of charge forever

...

Conclusion

The new energy car just came out, the gas car owners are still waiting, the first on the car has experienced the sweet, good or bad use will know, as for those so-called problems, will be solved with time, try more new things, embrace change, do not stick to the old, do not use the same ideas to see the ever-changing world, in order to be invincible.