Which web framework should Gitea switch, Gin or Chi?

[lunny]

I have sent an expirement PR to switch from Macaron to Gin #7177.
But I know some body wants to use Chi (@tboerger @vtolstov).
So I think a vote is meaningful, but I have to say this will not decide which one we will use finally.

👍 Gin

❤️ Chi

[mrsdizzie]

If there could be a list of reasons why one is better than the other for Gitea from anybody who has an opinion/experience with them that would be helpful!

[tboerger]

For those who want to know the differences if they do not already know that: Please look at the code, look at the examples!

I personally prefer Chi because it includes lesser magic, is more idiomatic Go, is simple as the stdlib with some additional sugar. That's why I fell in love with it and using it for all my projects.

[vtolstov]

Agree with @tboerger chi is powerful like gin, but simple as stdlib.
About performance i think that both have good enough for gitea.

[appleboy]

See the all router benchmark results.

[zeripath]

Ok, I think we need to be clear about what we think are the problems with macaron, what we use in macaron and what we would like to use in future. There's a cost to every framework not just in terms of performance but in terms of refactoring and architecture and we should be careful about what we choose to do.

If it's just a case of macaron is dead so let's move off it then we should consider a fork or even drop to basic go. If it's a case of macaron makes poor architectural choices then that's a better reason to move but it will certainly cost and we should be certain that we want that architecture.

[zeripath]

Problems I see with macaron:

• One maintainer model
• Questionable escaping and previous security practices
• Panic in init if working directory not readable (!)
• routes.go is handwritten and has to be updated manually - it would be excellent if this could be generated
• Encourages manual URL writing - this tightly binds our URL structure to the current form.
• JSON encoder actually stores object completely in memory before generating response which is also stored in memory before being transmitted.
• i18n framework has a number of issues - the biggest being a requirement to list which languages are available and then panicking if you get it wrong.
• I had to rewrite the gzip handler
• I had to bodge the session handler
• Architecture likely caused template helper to become the monster it is today.
• Architecture likely caused the structure of our special rendering architecture to become the way it has.
• There is an intermittent bug with uploads that we have been unable to find or fix. This might be go related but is hopefully fixed in other frameworks.

[coolaj86]

Better URL Branding

While this is being reworked I'd suggest considering how to have personally branded URLs.

Project URLs

Instead of

• https://code.example.com/exampleco/my-project

Being able to have

• https://code.example.com/my-project

Forks

Instead of

• https://code.example.com/otheruser/my-project

perhaps forks could be handled as

• https://code.example.com/my-project/forks/otheruser (I think I like this the best for branding)

or

• https://code.example.com/forks/otheruser/myproject

or even

• https://forks.example.com/otheruser/myproject

Reasoning

I think the aspects of ownership and control are what draw a lot of people to platforms like Gitea - personal. However, it doesn't make a lot of sense to me to always have "organizations" in the traditional sense of what GitHub and GitLab do, for self-hosted git platforms. It should be possible to have more controlled branding.

Also, as a service offering, branded Git would be unique.

[tboerger]

I dislike changing the url schema, I'm organizing a lot based on orgs.

Beside that, this is not related to choosing one of the frameworks.

[coolaj86]

I'm not saying that it should be the default for everyone. I'm saying it should be possible.

If all of the URL routing is being rewritten, it's an absolutely perfect time make it flexible to allow for prettier URLs.

[lunny]

We should keep URL compatible on 1.x even if we changed a web framework. It will broken all the references.

[coolaj86]

I'm not saying that it should be the default for everyone. I'm saying it should be possible.

[sapk]

I would say gin because I have better experience with it and like it but the big deps for msgpack and protobuf are kind of bad currently. I haven't use chi so I can't comment on it.

[lunny]

A problem is gin or chi 's routers maybe not powerful enough to satisfy gitea's requirements.

[coolaj86]

A problem is gin or chi 's routers maybe not powerful enough to satisfy gitea's requirements.

Can you give an example?

[lunny]

One example:

/:username/:reponame/wiki/*page/_revision
The page may have a slash because we would like to support sub page.

[tamalsaha]

I am coming here from #7670 issue. I think before framework is switched, it might be worth asking what changes at the framework level is desired. Macaron has been stable for a while and seem to get the job done (with the caveat that I am not aware of any prior conversation).

Switching framework seems like a lot of work. If the primary reason for switching framework is that macaron does not accept/merge any prs and there is no desire to make any other major changes to macaron by Gitea project, forking might be less work. Hence probably a better choice.

[lunny]

@tamalsaha I have created fork organization, please resend your pull requests to https://gitea.com/macaron .

[coolaj86]

/:username/:reponame/wiki/*page/_revision

@lunny That appears to be supported as per https://godoc.org/github.com/go-chi/chi

"/user/{name}" matches "/user/jsmith" but not "/user/jsmith/info" or "/user/jsmith/"
"/user/{name}/info" matches "/user/jsmith/info"
"/page/*" matches "/page/intro/latest"
"/page/*/index" also matches "/page/intro/latest"
"/date/{yyyy:\\d\\d\\d\\d}/{mm:\\d\\d}/{dd:\\d\\d}" matches "/date/2017/04/01"

"/page/*" matches "/page/intro/latest"

[lunny]

Does "/page/*/index" match /page/myintro/intro/index?

[sapk]

@lunny it seems to support custom regex so we could match thoses cases.

[sapk]

I am tempted to do a POC with chi to learn it

[lafriks]

@sapk that would be great, would love to see that. My experiment with chi somehow was not so sucessful

[sapk]

We should maybe try to make sub function that are router independent first.

[dunderpate]

Of the two, I really like Chi... In fact, I stopped reading Gin's example code after:

r := gin.Default()

Since that would mean nothing to someone who was just familiarizing themselves with the project and didn't know about Gin, or web-frameworks, etc. It's a classic 101 no-no for method naming. Chi's was much better:

r := chi.NewRouter()

I happily read through almost all the example code for Chi with nothing jumping out at me as annoying, incorrect, or confusing. Chi 🥇

[sapk]

After playing with chi, I like the KISS feel but it seems to miss some middleware implementation. I am not against implementing them but that will need some work.

[tboerger]

You can always create a pr for useful middlewares which aren't part of chi middleware package

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[lunny]

Closed by #7420