search

aerogo / aero

:bullettrain_side: High-performance web server for Go (2016). New alpha (2024) with even better performance is currently in development at https://git.akyoto.dev/go/web
MIT License
572 stars 33 forks source link

Proposal: Alternative handler signature #9

Closed akyoto closed 5 years ago

akyoto commented 5 years ago

I'd like to know what people's thoughts are on changing the aero.Handle signature from returning a string to returning an error object.

Since most people are calling ctx.HTML before returning the http body we can adjust ctx.HTML to return an error object alongside the other content types and people would have no troubles adopting the new signature. A search and replace would do the job.

The advantage is that the error return type feels more like idiomatic Go code whereas the string type forces us to do things like return "" on not-in-memory responses like ctx.File or ctx.EventStream. return nil feels a little cleaner.

Thoughts?

akyoto commented 5 years ago

I have performed the changes in a separate branch, see the commit https://github.com/aerogo/aero/commit/a0c598048d730caec117da69872bd6327b7ae009.

We end up with quite a few code deletions and overall cleaner code. I believe this is a step in the right direction.

soulcramer commented 5 years ago

I think this change is great, it does look more idiomatic but as you said this change will break on the client side. Maybe it's the occasion to add two or three other breaking changes so the user have to handle these only in the next version?

I like where you're going with aerogo 😄

akyoto commented 5 years ago

Normally, breaking changes can easily be handled by a major version upgrade in the semver number.

In the case of Go, however, this would cause everyone to start using "/v2" suffixed import paths in every single import which I vehemently disagree with. Import paths declare which library I'm using, not at which (major) version I am using it. Import paths should not be doing something they are not concerned with. We have a go.mod file to do versioning for us.

Using the version that is explicitly stated in the go.mod should be the default behaviour, that means no suffix should ever be required for importing the exact version that is stated in the go.mod file.

For this reason, I will have to resort to a minor version upgrade for breaking changes, even if it does not adhere to semver rules.

This is sad but I don't see another solution within the current state of Go modules.

akyoto commented 5 years ago

Further discussion around this topic can be seen here: https://groups.google.com/forum/#!msg/golang-dev/MNQwgYHMEcY/ScU6RIgICwAJ