Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace encoding/json with jsoniter #68

Closed
lggomez opened this issue Aug 3, 2021 · 3 comments
Closed

Replace encoding/json with jsoniter #68

lggomez opened this issue Aug 3, 2021 · 3 comments
Labels

Comments

@lggomez
Copy link
Member

lggomez commented Aug 3, 2021

Migrated from dgrijalva/jwt-go#358:

fredbi commented on Sep 3, 2019

github.com/json-iterator/go is currently one of the fastest libs available to process json.
Besides, it is a simple drop-in replacement for the standard lib, without much code change.

I am proposing PR #357 to validate the concept and expose benchmarks on signing and parsing methods.

NOTE: due to some changes in the order of marshalled claims, testable examples verifying the value of the signed string have been adapted to check for decoded claims instead.

@lggomez
Copy link
Member Author

lggomez commented Aug 3, 2021

fredbi commented on Sep 6, 2019

Attention: notice that this breaks compatibility with older golang versions.
I don't think that keeping a compatibility promise back to versions older than 1.7 brings much value.
This PR imposes golang 1.7+.

@oxisto
Copy link
Collaborator

oxisto commented Aug 3, 2021

Thanks for all the effort @lggomez :)

I am inclined to close this as "won't fix". I would argue that keeping this library with 0 dependencies is one of the best, not the best feature of this library. Especially looking at the other libraries that tend to have quite a few deps.

@lggomez
Copy link
Member Author

lggomez commented Aug 3, 2021

Thanks for all the effort @lggomez :)

Thanks! trying to get rid of some management debt in here since I'm not very active on the repo due to schedule

I am inclined to close this as "won't fix". I would argue that keeping this library with 0 dependencies is one of the best, not the best feature of this library. Especially looking at the other libraries that tend to have quite a few deps.

I agree that possibly the best feature is the premise of strict stdlib dependency but I still found this issue interesting to discuss. The json marshaler overhead is almost neglegible on signing time since all of that CPU load goes to crypto but it'd be interesting to see how the parser performs (I see there aren't any benchmarks on that part yet)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants