var jwt = require('jsonwebtoken');
var token = jwt.sign({ foo: 'bar' }, 'shhhhh');
var token = jwt.sign({ foo: 'bar' }, 'shhhhh', function(err, token) {
console.log(token);
);
I want to know , is it bad to use Synchronous way , in express js server? is there any benefit with Asynchronous mode? As I think there is no I/O and just CPU usage, So Asynchronous and Synchronous must b same, just syntax is different
@ziluvatar , @MitMaro can you help me?
Hello???????????
:-((
https://medium.com/@patrykcieszkowski/jwt-authentication-in-express-js-ee898b87a60 section Verifying the Token may help you
@wjureczkaPracuj as I understand, in point of performance there is no different I use sync or async mode, and it is safe to use sync mode in server too
in point of performance there is no different I use sync or async mode, and it is safe to use sync mode in server too
Correct. Although if you use the sync way be sure you wrap it with try-catch.
If there is no perf difference, why does the library offer an async alternative?
TL;DR; To allow consumers load keys from filesystem or any other source of ReadStream without blocking event loop. Not to actually perform the signing.
I've been digging into git history and jws implementation to understand why the library provided the async functionality for signing:
jws implemented streaming for sign/verify: https://github.com/brianloveswords/node-jws/commit/ad80a8ac9fdea2de59b607ea8f556451053af145jws library provides streaming for payload and secret, that way you could load those from the file system or any source that provided a NodeJS stream interface, like we can see in jws: https://github.com/brianloveswords/node-jws/blob/ad80a8ac9fdea2de59b607ea8f556451053af145/test/jws.test.js#L132Honestly, not sure if that streaming is a desired feature by consumers, we'd need to update the README to make it clear.
@ziluvatar That sounds like some serious coding archaeology... well done! :wink:
Most helpful comment
TL;DR; To allow consumers load keys from filesystem or any other source of ReadStream without blocking event loop. Not to actually perform the signing.
I've been digging into git history and jws implementation to understand why the library provided the async functionality for signing:
jwsimplemented streaming for sign/verify: https://github.com/brianloveswords/node-jws/commit/ad80a8ac9fdea2de59b607ea8f556451053af145jwslibrary provides streaming for payload and secret, that way you could load those from the file system or any source that provided a NodeJS stream interface, like we can see injws: https://github.com/brianloveswords/node-jws/blob/ad80a8ac9fdea2de59b607ea8f556451053af145/test/jws.test.js#L132Honestly, not sure if that streaming is a desired feature by consumers, we'd need to update the README to make it clear.