I read this book too and it really drove things home. I remember after feeling a little bit unsure about the relevance of orthogonal systems, feeling the thrill of beginning to see and anticipate where the argument was going. It felt like I was discovering it for myself. I think there are lot of good math and physics books from the Soviet era.
If they are limited to 1, then they are not appropriate to use as a deployment mechanism. Do you only have one change being worked at a time? On my team, there's typically at least have a dozen different stories being worked in parallel.
I corrected my comment, it's supposed to be "active" feature flags, so only one enabled one. Thinking is that once you've enabled one in production, it should be stable enough that you should be able to clean it up. Would still enable multiple flags existing so different features can be in progress (and locally you'd only have the one you're working on active).
Bias is how all electric components work. All they know about is the difference in voltage between their electrodes, not any absolute voltage w.r.t the rest of the circuit.
Yes yes yes. You're not going to get much appreciation of this from newer devs. They've only known one thing. I shudder at all the human-hours spent on duplicative tasks related to the artificial frontend/backend separation.
Can you explain what this looks like? So each application that authenticates its requests using the jwt subscribes to a message queue and replicates the data in some database local to it? Then it checks that database each time a new request comes in?
Pretty much, with the type of local db/cache changing based on the amount of concurrent invalidation you expect.
The theory is that your list of prematurely invalidated tokens (expired by user before the token's own expiry date) is much, much lower than your active tokens, so you only have to check a requests JWT against this tiny subset, rather than every active session to confirm it doesn't exist.
It has its own unique failure modes where an invalidation doesn't make it to all listeners, so either you can expend effort to make it more robust (and it's again, less data to sync than the sum of all active sessions) or just live with some parts of the system allowing the token for a few minutes..I
Typically, unless you are at a very large scale, or dealing with offline clients, I'd stick to traditional cookies + session.
Honest question - What would you do to justify doing this over using cookie based sessions? Like, are there back of the napkin calculations you could do to find when one approach becomes comparable in performance to another? That's one thing in system design that I struggle with.
Depends on how many invalidations you see. Some systems can get away with a message queue with an in memory copy of whatever's still in TTL with a bloom filter in front to make for a really cheap check. If you have more invalidations than a simple library implementation can handle, you do a similar thing with a DB like Redis sitting off to the side.
It's not as if you're expected to use ORMs to do ad hoc querying of a database. Just fire up a db connection and start writing sql.
If you work on a large application with lots of transactional processing, it makes sense. I've worked on apps with 10's of 1000's of lines of Ibatis scripts. And on applications where you're expected to just invoke stored procedures for every little operation. I'll take Hibernate over that situation any day.
People really overstate the pitfalls of ORM's. If you're running reports against a data warehouse, don't use an ORM. If you are trying to optimize a complex query, don't use an ORM. For an app that is write heavy, with very many simple updates to a complicated object graph, it makes sense.
You're talking about the role that transistors play as switches in a digital logic circuit. The video is about the physical operation of, in particular, bipolar junction transistors, which are more commonly used as amplifiers.
