I am a Software developer with a love for OpenSource, Networking, Cloud and electronics. I work at Grace Health.
I am proficient as a Backend Engineer with the following Languages: NodeJS, Typescript, GoLang, Python. Cloud services: Heroku, AWS, Azure
Remote collaborations and Jobs.
Thank you for your questions. I will get to the developer of Durator and Metaworka to fix those. The cache is basically the same redis instance and storage. In order to make the design more linear and straight forward, I chose to use them as separate blocks of the same colour. This is great for explaining that a cache is a storage that is read before any process is started. In a bigger project, you might not have the luxury of having redis serve as both volatile storage and cache. Hence, it's great to point that out from the offset. With regards to your second question, if we know that the cache and the redis storage are one and the same, what you describe is exactly what was shown in the diagram. Get the URL, check if it exists as a key in the cache. If it does, get the uuid stored as a value and check if it also exists as a key in that same cache. If it does, return the result. If not, queue it and wait for it to complete. Any failure will also queue the request. I agree that the drawings could be better and I hope it was at least good enough to pass the information through. Thanks
Thanks for reading. Concerning the need to encrypt ones JWT, I believe there is no right or wrong answer as it can be platform and developer specific. However, if anyone chooses to encrypt their JWTs, it is only natural that they give an alternative source of the information that would be otherwise extracted from the JWT. To conclude, too little security is always more of a concern than too much. In the case where there is no need for the front-end to decode the JWT for any information, I believe there is no such thing as too much security. Thanks