1. Performance

Before formally connecting Easy-Es to the production environment, you will definitely worry about a question, that is, after using this framework, will the query efficiency of the system decrease? Will the system resource overhead increase? How much is the negative impact? These problems are related to the survival of a framework. As an EE author, I have considered these problems before development, but users do not know, so I will help you to crush these concerns one by one.

Let's first look at what EE does in the entire query process? To sum up, there are 2 things:

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: such as List<T> and return it.

• Among them, the syntax conversion is performed according to the relationship between [MySQL and EE syntax comparison] (/pages/6fe140/). This conversion actually consumes very low performance, because even if you use RestHighLevelClient to query directly, you still need to create a termQueryBuilder and BoolQueryBuilder. The only difference is that I put the query conditions eq entered by the user into the queue, and then convert them one by one in the order of the FIFO in the queue (except when there is an or in the query conditions). For most query statements, query There are not too many conditions, so the number of elements in the queue will be less than 10 in most cases, and I only store enumerations and parameters in the queue, which will neither take up too much memory, nor will it be consumed by the traversal of the queue. How much performance. For modern computers, let alone traversing 10 small pieces of data, hundreds of thousands of pieces of data are in milliseconds, so this performance loss is basically negligible

• Let's talk about the result parsing. The result parsing is actually to take out the hits in the SearchResponse returned by calling RestHighLevelClient and convert it into an array with fastJson. Even if EE is not used in this process, you will have this step if you use RestHighLevelClient directly, so there is not too much loss in this step. , even if I use reflection, the reflection and annotation information of the field are loaded into the memory when the framework starts, and the jvm cache is done, so this loss is negligible.

Of course, the above are all based on theoretical analysis. In the Performance test class of the test module, you can see that I have made performance tests of different dimensions for CURD. The actual test results also confirm my theoretical analysis above. EE Except that the query will be 10-15 milliseconds slower than using RestHighLevelClient directly, there is no difference in adding, deleting or modifying the API, and as the amount of query data increases, after the entity field cache takes effect, the query difference will be further reduced, almost negligible. Sacrifice 10 Milliseconds are imperceptible to users, but for development, it can save a lot of code and time. I think it's worth it. Basically, there is no ORM framework that will not deplete performance. Weigh the pros and cons. Lords Psychology should have the answer.

2. Safety

All three-party dependencies of this framework include the es operation suite and RestHighLevelClient officially provided by elastic search, Ali's fastJson, Spring's official SpringbootAutoConfig, Apache's commons-codec and Lombok. Click on the maven central warehouse and check it out for yourself: maven central warehouse (opens new window) Even if the above kits do not use EE, you will use them in actual development, and they are all official products, so you don't need to worry about them. So is it possible that EE has security issues? After all, it is written by individual developers and is not endorsed as strongly as the aforementioned frameworks. First of all, I think that any framework may have security risks, even if there are strong company endorsements, such as the former For a while now, there is a security vulnerability in Ali FastJson. For EE, I personally think that there are no particularly serious security problems at present. The core principle of EE framework has been listed in the figure above. The core principle of EE is only conversion, which is equivalent to a translation or intermediary , there are no other operations involving security classes, and the EE framework itself is very lightweight, without introducing any redundant class libraries, all tool classes are encapsulated by themselves, and the apache tool class is also referenced when encapsulating, so it is reasonable to think that using EE is relatively safe, unless the downstream official dependencies themselves have security vulnerabilities. If you doubt that the framework itself has security problems, you can download the source code and read it to see if there are any vulnerabilities. In addition, there has been a lot of controversy about FastJson. Its performance is indeed a well-deserved brother on the market. It is indeed fast enough. In terms of security, because of the AutoType problem and the hacker's story, many people mistakenly believe that It is full of loopholes, but it is actually not that bad. The frequent loopholes in the past are essentially a problem. There are still so many projects using FastJson in Alibaba. As long as the community is active and actively dealt with, they can be considered for use. Which framework can guarantee that there are no vulnerabilities at all, but it has not been discovered yet.

3. Extensibility

The bottom layer of EE uses the RestHighLevelClient officially provided by Es. We only enhanced RestHighLevelClient, and did not change or weaken its original functions, so you don't need to worry about scalability. The use of any framework will reduce the flexibility of the system, because the framework is dead. After using it, it will inevitably encounter some scenarios that the framework cannot satisfy, and need to be customized. Use it, otherwise what should I do if I encounter problems in the future? In order to solve the above problems, I specially left Mixed Query and Origin Query in the framework At present, all APIs provided by EE can cover 99% of the actual development requirements. When 1% of the requirements cannot be covered in a very small probability, you can use mixed query, that is, the statements that can be supported are generated by EE, and the statements that cannot be supported can be generated by EE. Just use the syntax of RestHighLevelClient directly, and then complete the query through the native interface, which is simple and hassle-free. Of course, if you don't like this "hybrid" method, you can also directly use the native query interface to complete the query, and directly Same as using RestHighLevelClient. Of course, if you really don't want to use any of the methods provided by EE, EE can still be used as an auto-configured version of RestHighLevelClient. You can directly inject RestHighLevelClient where you need it for use. EE has already helped you configure RestHighLevelClient as you specified in the configuration file. , is automatically assembled into SpringBean, so in any case, you can be confident and calm, just like using the official RestHighLevelClient directly, you don't need to worry about what to do if something goes wrong one day, don't use EE, just treat it as a A tool that introduces dependencies and automatic configuration. And this possibility is very low. We also have a dedicated Q&A group to give you free online support, and will respond to your reasonable needs as soon as possible and arrange the landing.

4. Team and community activity

The team has recruited 5 people, which I call "Five Tiger Generals". TeamWork has been started since version 0.9.5+. In the future, as the project develops, more people with lofty ideals will be recruited to join. The community is currently active and will meet every year. Release many versions to continuously improve the user experience. We will respond to the needs of users within a week. If it is reasonable, the project will be established within one month, and the development and launch will be completed within three months. Issues will be resolved within two weeks after confirmation. online.

5. Access advantage

• Simple, easy to use and efficient, I don't need to say more, MyBatis-Plus users know everything! Save a lot of time, do...the things you love to do, it's really fragrant!
• The threshold for use is lowered, even if you are a novice who just doesn't understand Es, you can use EE to develop various functions
• Significantly reduce the amount of code, improve code readability, reduce the amount of repetitive code, and improve code quality
• Professional Q&A team, worry-free after-sales
• Free forever

...

6. Conclusion

When the new energy vehicle first came out, the owners of the gas truck were still waiting and watching. Those who got on the car first had already experienced the sweetness. You will know if it is good or not. As for those so-called problems, they will be solved with time. Try new things more, Only by embracing change, not conforming to the old ways, and looking at the ever-changing world without immutable concepts, can you be invincible.