Huge dependency

[john8329]

Using go 1.12, latest version of gin to date, I analysed my executable and I see that 11MB are occupied by the dependency github.com/ugorji/go/codec. Does really gin need all of this package?

[tqcenglish]

some result through goweight

[sairoutine]

github.com/ugorji/go/codec is used to output msgpack.
It is huge because codec supports not only msgpack but also cbor, json.

It should be better we thinking to use other msgpack libraries instead of it.

[Hades32]

Just realized just the same thing. That's ridiculously large for a hello world http server.

I would argue that MsgPack support shouldn't be part of core Gin anyway. It's not a super common format like Json. Some goes probably for github.com/golang/protobuf ~2MB...

IMHO it would make more sense to have a gin-msgpack and gin-protobuf dependency. Looking at it this would probably require making default content-type bindings and renderers plugable, but this seems to be a good idea anyway...

[ravener]

i agree, those dependencies should be someway optional or as another plugin package, in most cases i don't think a user would need those dependencies.

[john8329]

Good frameworks are built up in modules. As we don't expect gin to have other useful stuff like jwt, it shouldn't include by default a relatively more obscure encoding for no reason, in my own opinion.

[dmarkham]

So go in general is just a little over the top in executable size. If we were all prioritizing saving 2MB we would be writing in rust or c.

I don't really like the build tags option either. Last thing I want to think about is all the build tags we end up adding add then having to support in the future.

Now that binding has been refactored into a nice interface. Seems like we should be able to get all none builtin encoding's moved out into something that registers itself with gin on a per app basis maybe similar to how sql drivers do it. We can do better!

[sapk]

@dmarkham the build flag is mainly to have non-breaking optimization but a system like sql drivers should be better and should not be that difficult to setup. The most difficult point would be the current select of content-type in the binding module. The rest could already be 'pluggable' but that would break reverse compat with older version and would need a v2 versioning.

[dmarkham]

@sapk technically I don't think msgpack / protobuff have been in a released yet. They are being proposed to be included in v1.4.0 and that is not out yet. Maybe they should be the first to use a new ''pluggable" version, vs the first to to start a trend on being excluding via tags?

With that being said, I don't feel super strongly about it, and I guess I would been better if i thought about it back when #1479 was getting talked about.

[guonaihong]

If you remove github.com/ugorji/go/codec, it will automatically build faster for me.

[thinkerou]

About the issue, I may remove binding/msgpack and binding/protobuf, etc, and render/msgpack and render/protobuf, etc. And then we may have two method to solve the change:

1. add gin-gonic/gin-binding and gin-gonic/gin-render, it will like Modular deps for binding and render #1856
2. not add gin-gonic/gin-binding and gin-gonic/gin-render, user realizes Binding interface and Render interface.

[thinkerou]

And gin.Context not use render.MsgPack and binding.MsgPack directly.