I'm saying that, at least as described in the blog post, the Azure function is unnecessary because that decision can be made on the frontend (or in the API clie

I'm saying that, at least as described in the blog post, the Azure function is unnecessary because that decision can be made on the frontend (or in the API client). Here is how it sounds like it works now when someone visits https://haveibeenpwned.com/Passwords https://haveibeenpwned.com/Passwords 1) User enters abc123 in the form 2) The frontend translates that to the hash prefix 61ee8 3) The frontend interpolates that into the URL for the function, https://api.pwnedpasswords.com/range/{hashPrefix} https://api.pwnedpasswords.com/range/{hashPrefix} 4) The frontend requests https://api.pwnedpasswords.com/range/61ee8 https://api.pwnedpasswords.com/range/61ee8 5) The Azure function interpolates the hash prefix into the URL for the response in blob storage, something like http://pwnedpasswords.blob.core.windows.net/foo/{hashPrefix}.txt http://pwnedpasswords.blob.core.windows.net/foo/{hashPrefix}... 6) The Azure function requests http://pwnedpasswords.blob.core.windows.net/foo/61ee8.txt http://pwnedpasswords.blob.core.windows.net/foo/61ee8.txt 7) The Azure function returns that to the frontend Here is what I was proposing 1) User enters abc123 in the form 2) The frontend hashes that to 61ee8 3) The frontend interpolates that into the URL for the response in blob storage, something like http://pwnedpasswords.blob.core.windows.net/foo/{hashPrefix}.txt http://pwnedpasswords.blob.core.windows.net/foo/{hashPrefix}... 4) The frontend requests http://pwnedpasswords.blob.core.windows.net/foo/61ee8.txt http://pwnedpasswords.blob.core.windows.net/foo/61ee8.txt