Beego is no longer Go
Any HYIP is very funny when you look at it from the side. Less fun when you get involved in it directly.
HYIP Go came somewhere in 2014, when the authors of the applications who had 1000RPM (requests per minute) on the force suddenly decided that they urgently needed concurrency, because their 1000RPM was about to become 1000RPS (which is also not so much in fact).
The result of HYIP was that many people accustomed to the application's MVC architecture, Go to Spring, Django or Ruby on Rails, joined Go. And this architecture, like an owl on a globe, they began to pull on Go. So there were cadavres like Beego and Revel . Revel died safely, although he is still trying to pump out. But I want to talk about Beego separately.
')
Richard Eng has contributed a lot to the Beego promotion among the masses with his series of articles “A word the Beegoist” . Virtually the "Gospel of Richard." Ironically, despite the fact that Richard is frantically promoting Go, he himself does not write on it.
In my turn, with Go, and even worse, with Beego, I worked quite a bit. And I can say that this is clearly not the way the development on Go should go.
Let's take a look at a few basic aspects of Beego, and why they contradict the various best practices in Go, and indeed in the industry as a whole.
Robert C. Martin, better known as Uncle Bob , has repeatedly voiced the idea that the structure of an application should convey its essence. He is extremely fond of giving an example from the cathedral, which can be viewed from above, and immediately understand that this is a cathedral.
Robert has repeatedly criticized Ruby on Rails for its folder structure - controllers, models, views, that's all. The problem with this approach is that the socks “top” app will look just like a food ordering app. And in order to understand the essence of the application, you will need to climb into some models folder, and see which entities we end up with.
This is exactly the Beego's sick behavior. While the same Spring has gone in the direction of Domain Driven Design and the structure of the folder transmitting the essence, Beego imposes the use of a structure that has already become an antipattern.
But the problem is even more serious. For Go there is no separation between the folder structure and the package structure (package). Therefore, in Beego and UsersController and OrdersController will be under the same package of controllers. And if you have two types of controllers, those that serve UI and those that are used for the API, with the latter in a decent society, it is customary to version? Then get ready for freaks like apiv1.
Oddly enough, Beego, being an unlucky clone of Ruby on Rails, does not use the ActiveRecord pattern. Its ORM is an extremely strange sight. If for quite basic operations, like reading a line / writing a line, it is still suitable, then, for example, what a simple sample looks like (here and further examples are taken directly from the documentation):
But the main problem with Beego ORM is not even that you need to fight with proprietary language, but that it uses all of Go’s worst practices, be it import side effects:
Or registration of models in init ():
Do yourself a favor, even if you still decide for some inexplicable reason to work with Beego, do not use Beego ORM. If you don’t live without ORM (what are you doing in the world of Go, my dear?), Use GORM . He even supported. Otherwise, “database / sql” will help you.
From Ruby on Rails copied the same command line tool, which is called simply Bee . If only in the RoR world there were rails and rake, then bee is such a trashcan for everything. He and MVC application for 'boostrap', and migration will run, and file watcher will launch. In the latter lies another problem. After all, what is one of the main advantages of Go? What runs locally is as close as possible to what runs in production. If you do not use bee, of course.
Go is a strongly typed language that does not support either generics or annotations. How to make a MVC framework like this? By reading the comments and generating files, of course.
It looks like this:
Evidence, as can be seen, is zero. The Post () function receives nothing at all and does not return. http.Request? No, not heard.
Well, how does all routing work? When you run the notorious bee, another file is generated, commentsRouter_controllers.go, which contains an example of such wonderful code:
See, do not forget to regenerate and “combine” this file after each change. Until recently, the situation was even sadder, and during the tests this file was generated automatically, so you found out about the problems already in production. It seems in recent versions this strange behavior has been fixed.
And so we approach the topic of testing. Go, unlike most other programming languages, comes with a test framework out of the box. In general, the Go philosophy is that the test should sit next to the test file. But we are in the world of MVC, spit on the Go philosophy, right? So please put all your tests in the daddy / test, as DHH has bequeathed to us.
And this is not such a trifle, because, I remind you, in Go package == folder. And if a test located in the same package can call a private method, then a test located in another package will no longer exist.
But okay, everything would be limited to the folder structure. Beego code is in principle very difficult to test, since everything in it is a side effect.
This is how Beego requests routers:
The same story with middlewares, and with controllers, which I mentioned earlier.
This is for me, as a software architect, a cherry on a cake. The documentation in BeeGo is as good as your Chinese. No, two comments have already gotten rid of comments in Chinese inside the code over the past year.
Now only some pull requests remain in Chinese:
And especially in issues:
If you have a team of Ruby / PHP / Python code writers, and you urgently want to translate them to Go, the worst thing you can do for them is to get them to go to the MVC framework for Go. MVC as a whole is so-so an architectural pattern, and in Go it is completely out of place. Or, if you are absolutely sure that nothing but Go will not save you, let them retrain and write as Go is accepted - as flat and explicit as possible. Or, perhaps, they know best, with the help of a tool to solve the tasks assigned to them?
HYIP Go came somewhere in 2014, when the authors of the applications who had 1000RPM (requests per minute) on the force suddenly decided that they urgently needed concurrency, because their 1000RPM was about to become 1000RPS (which is also not so much in fact).
The result of HYIP was that many people accustomed to the application's MVC architecture, Go to Spring, Django or Ruby on Rails, joined Go. And this architecture, like an owl on a globe, they began to pull on Go. So there were cadavres like Beego and Revel . Revel died safely, although he is still trying to pump out. But I want to talk about Beego separately.
')
Richard Eng has contributed a lot to the Beego promotion among the masses with his series of articles “A word the Beegoist” . Virtually the "Gospel of Richard." Ironically, despite the fact that Richard is frantically promoting Go, he himself does not write on it.
In my turn, with Go, and even worse, with Beego, I worked quite a bit. And I can say that this is clearly not the way the development on Go should go.
Let's take a look at a few basic aspects of Beego, and why they contradict the various best practices in Go, and indeed in the industry as a whole.
Folder structure
Robert C. Martin, better known as Uncle Bob , has repeatedly voiced the idea that the structure of an application should convey its essence. He is extremely fond of giving an example from the cathedral, which can be viewed from above, and immediately understand that this is a cathedral.
Robert has repeatedly criticized Ruby on Rails for its folder structure - controllers, models, views, that's all. The problem with this approach is that the socks “top” app will look just like a food ordering app. And in order to understand the essence of the application, you will need to climb into some models folder, and see which entities we end up with.
This is exactly the Beego's sick behavior. While the same Spring has gone in the direction of Domain Driven Design and the structure of the folder transmitting the essence, Beego imposes the use of a structure that has already become an antipattern.
But the problem is even more serious. For Go there is no separation between the folder structure and the package structure (package). Therefore, in Beego and UsersController and OrdersController will be under the same package of controllers. And if you have two types of controllers, those that serve UI and those that are used for the API, with the latter in a decent society, it is customary to version? Then get ready for freaks like apiv1.
ORM
Oddly enough, Beego, being an unlucky clone of Ruby on Rails, does not use the ActiveRecord pattern. Its ORM is an extremely strange sight. If for quite basic operations, like reading a line / writing a line, it is still suitable, then, for example, what a simple sample looks like (here and further examples are taken directly from the documentation):
qs.Filter("profile__age__gte", 18) // WHERE profile.age >= 18 But the main problem with Beego ORM is not even that you need to fight with proprietary language, but that it uses all of Go’s worst practices, be it import side effects:
import ( _ "github.com/go-sql-driver/mysql" _ "github.com/lib/pq" _ "github.com/mattn/go-sqlite3" ) Or registration of models in init ():
func init(){ orm.RegisterModel(new(User)) } Do yourself a favor, even if you still decide for some inexplicable reason to work with Beego, do not use Beego ORM. If you don’t live without ORM (what are you doing in the world of Go, my dear?), Use GORM . He even supported. Otherwise, “database / sql” will help you.
Bee tool
From Ruby on Rails copied the same command line tool, which is called simply Bee . If only in the RoR world there were rails and rake, then bee is such a trashcan for everything. He and MVC application for 'boostrap', and migration will run, and file watcher will launch. In the latter lies another problem. After all, what is one of the main advantages of Go? What runs locally is as close as possible to what runs in production. If you do not use bee, of course.
Automatic routing
Go is a strongly typed language that does not support either generics or annotations. How to make a MVC framework like this? By reading the comments and generating files, of course.
It looks like this:
// @Param body body models.Object true "The object content" // @Success 200 {string} models.Object.Id // @Failure 403 body is empty // @router / [post] func (this *ObjectController) Post() { var ob models.Object json.Unmarshal(this.Ctx.Input.RequestBody, &ob) objectid := models.AddOne(ob) this.Data["json"] = map[string]string{"ObjectId": objectid} this.ServeJson() } Evidence, as can be seen, is zero. The Post () function receives nothing at all and does not return. http.Request? No, not heard.
Well, how does all routing work? When you run the notorious bee, another file is generated, commentsRouter_controllers.go, which contains an example of such wonderful code:
func init() { beego.GlobalControllerRouter["github.com/../../controllers:ObjectController"] = append(beego.GlobalControllerRouter["github.com/../../controllers:ObjectController"], beego.ControllerComments{ Method: "Post", Router: `/`, AllowHTTPMethods: []string{"post"}, MethodParams: param.Make(), Filters: nil, Params: nil}) ... } See, do not forget to regenerate and “combine” this file after each change. Until recently, the situation was even sadder, and during the tests this file was generated automatically, so you found out about the problems already in production. It seems in recent versions this strange behavior has been fixed.
Component testing
And so we approach the topic of testing. Go, unlike most other programming languages, comes with a test framework out of the box. In general, the Go philosophy is that the test should sit next to the test file. But we are in the world of MVC, spit on the Go philosophy, right? So please put all your tests in the daddy / test, as DHH has bequeathed to us.
And this is not such a trifle, because, I remind you, in Go package == folder. And if a test located in the same package can call a private method, then a test located in another package will no longer exist.
But okay, everything would be limited to the folder structure. Beego code is in principle very difficult to test, since everything in it is a side effect.
This is how Beego requests routers:
import ( _ "github.com/../../routers" ) The same story with middlewares, and with controllers, which I mentioned earlier.
Documentation
This is for me, as a software architect, a cherry on a cake. The documentation in BeeGo is as good as your Chinese. No, two comments have already gotten rid of comments in Chinese inside the code over the past year.
Now only some pull requests remain in Chinese:
And especially in issues:
Instead of conclusion
If you have a team of Ruby / PHP / Python code writers, and you urgently want to translate them to Go, the worst thing you can do for them is to get them to go to the MVC framework for Go. MVC as a whole is so-so an architectural pattern, and in Go it is completely out of place. Or, if you are absolutely sure that nothing but Go will not save you, let them retrain and write as Go is accepted - as flat and explicit as possible. Or, perhaps, they know best, with the help of a tool to solve the tasks assigned to them?
Source: https://habr.com/ru/post/444022/
All Articles