document-library-microservice.js VS update-lambda-edge

That means Auth services, including Authress don't necessarily care where the public/private key pair comes from. Any pair can be used, so long as it provides modern asymmetric cryptography. For Authress, this means you can generate your own EdDSA keys or even bring your AWS Key Management Service (KMS) keys to use with Authress. For this, only updating the public key is required and can be done as part of your CI/CD process or via the the Authress Service Client API.

In our products Authress and Standup & Prosper we take great pride in having everything self-service, that also means our products' features are discoverable by every user. Users don't read documentation. That's a fact, and they certainly don't file support tickets. That's why every feature has a clear name and description next to it to explain what it does. And you never have to jump to the docs, but they are there if you need them. We would never hide a feature behind a hidden flag that only our support has access to.

I bring up this topic as it is one that frequently occurs and seams to not have any concrete and satisfiable answer yet. It's also incredibly relevant for my teams in building Authress, which focuses on providing user identity and access control. We care about making Authress as secure as possible to protect our customers' users. So you can imagine questions about security are always present in our conversations.

Having built many Product APIs in my experience for multiple companies, there are a number of Myths we've come to learn about APIs in general. Here are some of the more interesting ones we've learned through building Authress, which is an AuthN + AuthZ solution. For reference here is the Authress API.

The biggest example of the tests tests that make no sense is "testing user login". We never need to test user login, because if it doesn't work we can know immediately. Since every change an engineer makes needs login to work. Further, we have monitoring up and running that if login doesn't work, we'll know. Also let's take a look at login. Your team didn't write login, your company didn't even write it. You used a third party product to handle 99% of your login needs, be it Auth0 in the B2C space or Authress for example in the B2B space.

Authress — login authentication and access control, unlimited identity providers for any project. Facebook, Google, Twitter and others. The first 1000 API calls are free.

I also wouldn't recommend it, as there are a number of reliability and security concerns here, such as abusing your S3 bucket and costing you a lot. Preferably a better solution might be one that utilizes CloudFront and Lambda@Edge to serve a globally distributed service with first-class permissions. One example of this would be: https://github.com/Authress/document-library-microservice.js

In my organisation for the deployment of the latest version of code running on lambda@edge, we have written a script which uses update-lambda-edge npm package to deploy the latest code of lambda and also attach the latest version of it to different CacheBehaviours of CDN. The CLI utility allows only a single CacheBehaviour in single command while attaching the lambda to triggers so for multiple paths we run the command in the loop, till now things were fine, but since yesterday it started failing frequently, upon debugging I found that it was failing on the 5th entry of CacheBehaviour, if we're trying to update 4 behaviours it works fine.