Given the audience, a link to the github repo would be more appropriate (GPL3 license) [1]. It's an interesting idea.
Also worth noting the backend does seem to be Java based.
[1] https://github.com/bastillion-io/Bastillion
The only implementations of JWT I've actually seen in the wild, or would actually support are using asynchronous RSA public/private key signing. This allows you to have a trusted signing authority, which is imho better than a shared secret between two systems.
Also, only use trusted authorities where the actual public key is side-loaded from an internalized resource. Do *NOT* trust/use the header portion of JWT for this part.
The article itself is a bit too shallow and doesn't really discuss how this can work in access infrastructure, which becomes more common in a corporate or larger social interaction. There's also how to develop/design services to consider.
Beyond this are considerations for token duration, refresh and revocation.
NOTE: currently working on an access/identity management system centered around JWT tokens for multiple applications.
Most of this advice is not just for Angular development. It's also a bit thin...
Suggested reading from Steve Souders, some of this is a bit older, but most still applies. Some of the DOM quirky issues are significantly different, but general optimizations and suggestions around actually testing for performance metrics apply.
High Performance Web Sites: https://www.amazon.com/gp/product/0596529309
Even Faster Web Sites: https://www.amazon.com/Even-Faster-Web-Sites-Performance/dp/0596522304
Steve Souders' Blog: https://www.stevesouders.com/blog/
Beyond this, there's also the issues of perceived performance, you can actually be too fast, when people expect a spinner or loading screen, they may not believe something is actually done.
There are a lot of counter-examples for performance in design. It's a matter of actually developing for some optimal paths without investing too much time before you need to.
NOTE: make sure to encrypt your app keys for anything public facing, or limit their visibility to only CI/CD platforms. For travis, on open repos, definitely don't accidentally commit this in the open.
It looks like a homegrown CI/CD type agent and not a bad idea.
> We can also attribute the origin of this “JS revolution” to the release of ECMAScript 6
I'd disagree with this one. I feel that node+npm is the real launching point of the "JS revolution." Because it did something that hadn't come before. It allowed for modular, reusable code. At least once bundlers were available on the platform, AMD options and Browserify in particular. Which pre-dates and informs ES6 Module syntax, which still doesn't have very broad adoption. Though a lot of source uses ESM style while still relying on node/cjs convensions, which will probably adapt over time.
I think it largely comes down to a few different bits. Interest in more interactive engineering efforts on the client-side combined with in-language tooling that Node itself brought. Like a blacksmith, JS developers can actually make their own tools. npm allows unlimited sharing of these tools for reuse and optimization. Github rised around the same time and allowed for greater collaboration than ever before. In the end it has been a near perfect storm, so to speak. This has all lead to JS as "the one language to rule them all."
JS is not the best language at anything imho. But it's good enough for almost everything and thanks to npm and node, it's often the fastest to done option. These are the reasons why I will almost always push for the first version of everything be in JS/Node.