Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "what are the differences between goframe, beego, iris and gin". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Evaluation index

Index

Description

The basic introduction comes from their respective official websites. Whether the modular design supports modular plug-in design, low-coupling design between modules, and whether some of the components can be used independently. Whether the functional modules provided by the module perfection framework are rich. Whether the module can cover the daily common development requirements. Ease of use is not only about whether the value framework is easy to use, but also about whether the team can quickly access it at low cost and maintain it at low cost in the long run. Documentation integrity refers to the introductory materials provided on the official website, including but not limited to: documents, videos, examples, and case materials. At the same time, local Chinese document support is also a reference item. Whether the engineering is complete can be quickly connected to the project development, whether to provide project access specifications, design patterns, development tool chain, whether the documentation is perfect, whether the source code is easy to read, whether it is convenient for long-term maintenance. The development model that the development pattern framework applies to, or the development model that is officially recommended. Engineering specification the development specification when the project is connected, such as catalog specification, design specification, coding specification, naming specification, etc. Community active whether it is convenient for officials to communicate with the community, whether questions can be answered quickly, and whether BUG can respond quickly. Development tool chain CLI development tools used in project development, such as initialization of the project, cross-compilation, code generation, swagger, hot compilation capabilities, and so on. Web: performance testing

Source third party evaluation https://github.com/the-benchmarker/web-frameworks.

Web: whether there is a good solution when there is a route registration conflict is common in the development of business projects. Web: whether the domain name supports Web routing, or even multiple domain name binding. Web: whether the file service Web service provides access to static resources. Web: graceful restart / shutdown of the Web service will not affect the execution of the request when it is restarted. When it is closed, it will wait for the ongoing request to be processed, and the new request will no longer be accessed. Whether the ORM framework comes with ORM components, the ORM component is the core component of the business project. Whether it is self-developed or introduced through third-party components. Whether the Session framework provides session management components, whether they are general-purpose Session components or Session components for Web services only. I18N supports internationalization component support (common but not core components). Configuration management is also the core component capability of the framework. Logging component is also a core component capability that the framework needs to be complete. Data verification is also the core component capability of the framework. Cache management is also the core component capability of the framework. Whether it is memory or Redis, whether it is self-developed or introduced through third-party components. Resource packaging supports compiling dependent file resources, such as static resources, configuration files, and other fixed files into executable files. Framework components automatically support resource retrieval. Whether the link tracking framework has the ability of distributed link tracking or not, distributed tracking is an essential capability in the micro-service architecture. Test whether the framework supports unit test access and provides unit test access specifications. Whether using a standard library or a third-party testing framework. Highlight several advantages that are more obvious. Highlight several shortcomings that are more obvious. Horizontal comparison

The following section compares the parameters related to the part of the score, and the full score is based on a total of 10 points.

If the part marked "-" indicates that it is not supported or needs to introduce third-party plug-in support.

The following features provide the address of the document directly if the document is provided on the official website. I can't find the document, but I know it will be easily marked.

The implementation of the functional features of each "framework" is different, and there are great differences in documents, functions and ease of use. Friends can check the links on their own.

GoFrame

Beego

Iris

Gin

Comparative version of v1.15.2v1.12.3v12.0.2v1.6.3 project type open source (domestic) open source (domestic) open source (overseas) open source agreement MITApache-2BSD-3-ClauseMIT framework type modular framework Web framework Web "framework" Web "framework"

Basic introduction

The project is complete, easy to use, modular, high-quality, high-performance, enterprise-level development framework. The most easy-to-use enterprise Go application development framework. The fastest growing Go Web framework at present. Provide complete MVC functionality and look forward to the future. A HTTP Web framework written in Go. It provides Martini-style API and has better performance. Project address

Github.com/gogf/gf

Github.com/beego/beegogithub.com/kataras/irisgithub.com/gin-gonic/gin official website address goframe.orgbeego.meiris-go.comgin-gonic.com

Modular design

Yes-module perfection 10642

Ease of use

99910

Document perfection

10864 Engineering complete 10851 Community active 910910 development mode module introduction, three-tier architecture, MVCMVCMVC- engineering specification hierarchical design, Object design project structure-- Development tool chain gf tool chain bee tool chain-- Web: performance testing 10889Web: HTTPSHTTPS & TLS support CustomHttpConfiguration support Web: HTTP2-- support Web: WebSocketWebSocket Service has-Web: packet routing Registration-packet routing NamespaceGroupingRoutes has Web: routing conflict handling has-have-Web: domain name binding-- Web: file service static file service static text Component processing ServingStaticFiles includes Web: multi-port / instance multi-port snooping, Multi-instance monitoring-RunMultipleServiceUsingIris-Web: graceful restart / shutdown smooth restart feature hot upgrade GracefulShutdownOrRestartGracefulRestartOrStopORMORM documents ORM documents-SessionSessionSession has-i18N support i18NLocalization-template engine View design TemplateRenderingHtmlRendering configuration management configuration management parameter configuration-CustomHttpConfig log component log component Logging-- data verification form data verification-CustomValidators cache management cache management Cache-- resource packaging resource management bee tool bale life TestingTesting: link tracking, testing framework, unit testing, outstanding advantages of goframe, mainly engineering and enterprise direction. In particular, the idea of modular design and engineering design is very good. For business projects, it provides development specifications, project specifications, naming conventions, design patterns, development tool chains, rich modules, high-quality code and documents, and the community is active. The author is also a senior PHP developer, PHP to Go partners will feel more cordial. Beego open source is relatively early, and the earliest Golang development framework with more comprehensive functions has always had a great influence in the field of Golang. Author Xie Da has organized domestic GopherCN activities with greater influence for many years. Beego has relatively rich development modules and can be used out of the box. It provides a project structure and development tool chain based on MVC design pattern. It is mainly located for Web development. Of course, it can also be used for non-Web project development. Iris mainly focuses on Web development, providing a series of functional components of Web development, based on MVC development model. Iris this year relatively rapid development, from a Web Server component, but also slowly towards the direction of beego design. Gin focuses on lightweight Web Server, relatively simple, easy to understand, routing and middleware design is good, can be seen as an alternative to the standard library net/http.Server routing enhanced version of web server. Dedicated to friends who love to build wheels. Outstanding shortcomings open source time is late, the promotion is too Buddhist, at present, mainly for domestic users, not overseas promotion. It started early, but it has developed slowly in recent years since Xie University started its business. Non-modular design is more dependent on third-party heavyweight modules.

It claims to be the strongest in performance, and the result is mediocre. Non-modular design. In the last two years, it began to develop in the direction of beego, but the overall framework capacity is not complete and needs refueling.

The function is simple and easy to use, which is both an advantage and a disadvantage. Experience sharing

There are different choices for different demand scenarios. Choose the right tool to solve the right problem.

There is no difference between good and bad in open source, and it is very difficult and commendable that open source authors can share technical achievements for learning and use in the spirit of open source.

Finally, I would like to share with you the situation of my team and the detours taken in the transformation process of Golang technology stack. I hope I can give you some reference in the link of framework selection.

The initial pain point of the team

Some background for the team to transform the Golang technology stack. The main points are:

The initial main technology stack of the team back-end is PHP, which is transformed into micro-services due to the needs of business development. The first version of the microservice uses the communication mode of PHP+JsonRpc.

As the number of projects increased, the company also composed its own DevOps team, the underlying deployment turned to the Docker+Kubernetes container architecture, and introduced the Golang technology stack.

Due to some pain points, after comparing PHP with Golang for a period of time, the team decided to quickly transform the Golang technology stack. The main pain points are as follows:

The development and maintenance cost of PHP project in the middle and later stage of the project is on the high side as a whole after the business is complex. The main reasons are its high flexibility, unstructured variable design and uneven quality of developers.

After cloud containerization deployment, the DevOps efficiency of PHP is too low. Complex Composer version management and large Docker image size all affect the efficiency of DevOps. Comparatively speaking, Golang is extremely efficient.

Under the design of JsonRpc communication protocol, the interface has high expansibility and flexibility, but it is difficult to quickly determine the input and output definition of the interface between services, so it can only be docked and maintained according to documents and examples. Due to the separation of code and documentation, interface document maintenance often lags behind interface changes in most scenarios. With the continuous increase of services, unstructured communication protocol management further increases the cost of development and maintenance of service interfaces.

The communication protocol of JsonRpc is essentially based on HTTP1.x+Json, and its execution efficiency is too low to be regarded as a real micro-service communication protocol, so it is difficult to connect with the mainstream service governance framework. Compared with gRPC protocol based on HTTP2.x, it has mature micro-service development framework and service governance solution.

The consideration of business carding and the migration from PHP to Golang technology stack is actually an opportunity for technology reconfiguration. In the process of technology reconfiguration, it also rearranges the design of business system and pays off the technical debt.

Further pain points

Golang is really simple enough, compared with other interpretive development languages, there are not too many syntax sugars and language features, so the team got started quickly and quickly completed the technical refactoring of part of the business system. But then comes a more serious pain point. The main points are:

Too many wheels: Golang is so simple that our team members broke out in a pent-up commotion for a long time, gave full play to the wheel-building spirit of "building regardless of", and developed / encapsulated many large and small wheels. These wheels can meet the most basic functions, such as logging, configuration, caching, and so on. However, the wheel is not a semi-finished product to achieve a basic function, it needs to ensure functionality, stability, expansibility and maintainability, to be able to combine with more production practice verification, but also need to be able to long-term maintenance, continuous iterative improvement. Otherwise, it will be a bunch of adult toys of different sizes. Build the wheel for a moment and maintain the crematorium. Until now, we are still suffering from the unification of dozens of adult toys scattered in more than 100 Golang projects. Of course, this problem also has a lot to do with organizational structure and team management.

Disorganized:

We firmly believe that a package only does one thing, and specifically uses the form of a single warehouse package for package management, which is equivalent to each package is an independently maintained git repository. In fact, single warehouse package and package design is not necessary, on the contrary, independent single warehouse package increases the maintenance cost of components and frameworks.

This kind of single warehouse package design is difficult to form a technical system, and it is difficult to form a unified technical framework in team technical management. Single warehouse package appears to be very isolated, and the establishment of a technical system not only requires the establishment of norms and standards, but also needs a technical framework to accurately land. A systematic and unified technical framework involves at least dozens of basic technical components and cannot be designed in isolation. The implementation of the basic functions of each package is very simple, but how to be organized together is not a simple task, which requires that the technical managers of the team need to have a certain technical background, pattern and foresight, rather than being limited to package itself as ordinary developers do.

This isolated single warehouse package design does not have strong normalization constraints for business projects, each component can be replaced independently, and the problem of pain Point 1 is becoming more and more serious (even several sets of log components, although all meet the basic log specification design). In the end, the single warehouse package design that we were proud of at first turned into a pile of loose sand. For example, even if a standardized link tracking function is needed, the cost of improvement is extremely high because the single warehouse package is too scattered and inconsistent.

In addition to making the technical system difficult to establish and the technical specification difficult to accurately land, the ease of use of each component is also poor. For example, our log component, cache component, database component and HTTP/gRPC Server component all need to interface with the configuration management function, and the single warehouse package needs to ensure low coupling design, so developers need to manually read the configuration, convert it to the target configuration object, and inject it into the corresponding component initialization method before applying the object to the business logic. Several business items repeat this step. In fact, the ease of use design of goframe in this piece is quite good. Of course, each package is designed independently. Under the unified technical framework, we independently provide a coupled singleton module to encapsulate commonly used objects and automatically realize configuration reading, configuration object transformation, configuration object injection and component object initialization. Developers only need to call a singleton method. This commonly used singleton module has become a part of our technical framework, which greatly improves the efficiency of business project development and maintenance.

Version inconsistencies: with the increasing number of business projects, wheel version inconsistencies become more and more obvious. What is version inconsistency? For instance. We have a wheel called httpClient, which has released a total of about 10 versions; we have a total of more than 100 Golang projects, almost every version is in use. We submitted a bug fix, but it was difficult for all projects to be updated. The same is true for other wheels, and we also have dozens of wheels that are used independently by each project.

After reflection and summary, the following points are summarized:

The team needs a unified technical framework, not a patchwork of single warehouse packages.

We only need to maintain one version of the framework, not dozens of single warehouse packages.

The components of the framework must be modular and low-coupling design to ensure that internal components can also be referenced independently.

Single warehouse package design is strictly prohibited for core components and must be maintained uniformly by the framework.

The final choice

After so many detours, we are determined to build a systematic Golang development framework. In addition to requiring the team to learn quickly, the maintenance cost is low, and our main demand is that the core components cannot be semi-finished, and the framework must be mass-produced, stable and mature. As a result, we re-evaluated the popular technical frameworks in the industry, including those mentioned above. The original intention is to unify the internal wheels into a systematic framework and find some valuable references in open source projects.

Later, I found goframe, carefully evaluated and studied the framework design, and found that the framework design ideas and our experience are like a summary!

An embarrassing thing has to be mentioned here. In fact, before the very beginning to Golang (mid-2019) also did some research, then the goframe version is not high, and we are responsible for the evaluation of the team members have a preconceived idea, to see so many modules and documents, feel that it should be very complex, performance should not be high, so did not look at PASS. Later, I chose some seemingly simple open source wheels to do some secondary packaging.

After a period of careful investigation and source code study, we have come to the conclusion that the framework, modularization and engineering design ideas of the goframe framework are very good, the execution efficiency is very high, and the modules are not only rich, but also of high quality. It's nothing compared to the semi-finished wheels we wrote before. After stepping on the pit for more than a year, the team found that the team really needed a unified technical framework rather than a bunch of fragmented wheels. in fact, they had already given a bright road and had been working silently ahead.

After research and discussion within the team, we decided to use goframe to gradually restructure our business project. Because goframe is modular, we can also make necessary replacements for some modules. The refactoring process is relatively smooth, and the refactoring of the basic technical framework will not have any impact on the business logic. on the contrary, through the engineering idea of goframe and the great development tool chain, after unifying the technical framework, the efficiency of project development and maintenance has been greatly improved, so that the team can concentrate on business development, and the department has produced more output one after another. At present, we already have a large number of business projects dedicated to goframe. The daily traffic level of the platform is ten million.

This is the end of the introduction of "what are the differences between goframe, beego, iris and gin". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.