50 karma · joined January 31, 2022
Maybe "nested acronym" is a better term?
It would be difficult to come up with something you could reasonably ask an account holder to figure out on their own that also wasn't easy to randomly guess.
Not among my peers. Facebook is seen as a way to communicate with older and tech-challenged relatives. It's in the same category as LinkedIn -- a social network whose content is mostly cringe and that you're only on as a means to an end, not because it's a good product.
AWS IAM is interesting in that IAM resources are provisioned within a subscription. You can use IAM as an identity solution, giving everyone a user account and password, but you don't have to. Internally at AWS, we never used IAM users, but instead had an enterprise AD deployment that we used to log in to our computers and internal systems. One of those internal systems kept a list of AWS subscriptions and IAM roles you had access to, and would trade your AD credentials for temporary AWS credentials scoped to a role. It was pretty slick, but it's not inherent to IAM, so you typically need a third party service to do this for you. (At the job I had in between AWS and Microsoft, we used CloudTamer, and before that, we just had to keep track of 20 different username/password pairs.)
AAD on the other hand is a full blown identity platform that incidentally can also be used to log in to Azure. That means it integrates nicely with on-prem AD deployments and, more importantly, lets users log in once and navigate the subscriptions to which their account has been granted access. So it's actually simpler to use if you just need to be able to log in to multiple subscriptions, but you can run into cases where you need to operate on AAD resources in ways that aren't supported through Azure APIs. This primarily comes up if you need to grant a non-Azure permission as part of an Azure deployment. E.g., if you want to give a managed identity permission to read AAD metadata like service principal IDs, you can't do it from within ARM.
The neat thing about PHP and the + operator is that you can sometimes trick the interpreter into doing math on the underlying bytes of the string: http://dominic-mulligan.co.uk/wp-content/uploads/2015/05/SRE...
Identity and authentication is honestly the one area where the popular cloud platforms differ the most. I used to work for AWS and currently work for Azure, and the switch from IAM to AAD caused more cognitive dissonance than any other difference between the platforms' respective offerings.
But I'd say it's more common to just use "private" cache headers in this case for any page that differs for logged in vs unauthenticated users. The user's browser will still serve as a full page cache, but shared caches will ignore those pages.
This can be a great strategy when you're dealing with bounded data that's not sensitive, but it's important to recognize that this approach is often inappropriate. A web app may be allowing users to wander around terabytes of data, or it may need to make highly consistent authorization determinations before allowing a user to see specific data, or you may need to keep a highly detailed audit log of who requested what when (e.g., if the app targets healthcare or government users), which aggressive preloading would render useless.
You can do that with HTTP/2 server push on a multi-page app, too. The main difference is that with an SPA, you get to reinvent it all yourself.
Yeah, but full page caching is a thing, and in my experience, teams writing traditional server-rendered pages are much more aggressive in their use of response caching than are teams writing JSON APIs. Honestly, a Rails/Django/Laravel app with smart caching headers and a Varnish instance in front feels more reliably instantaneous than the bespoke caching solutions each SPA seems to invent for itself.