The normal way? You can implement whatever kind of index you like — b-tree index, bitmap index, hash index are all useful and conceptually simple if you're familiar with the backing data structures.
For example, if you want to index a "foreign key" id stored in each "record" in a JSON array of objects, you build a hash table from the FK id values to the JSON array indices of the objects that have that id. It can be as stupid simple as an `fk_index = defaultdict(set)` somewhere in your program, to use a Pythonism.
Now when someone wants JSON objects in that array matching a given FK id, they can just O(1) look in the index to know the position of records that match. Much better than an O(N) scan of every item in the array.
Of course you have to to maintain the index as writes to the JSON happen, but that's not bad once you understand how things work. No real secret sauce.
I don't regret putting it off until my 40s because it let me find a person I want to have a family with
Thank you for including this tidbit. I'm a man in my early 30s interested in having kids and recently discovered that I've poorly vetted my 5+ year SO's interest in having kids. Her "yeah, I'm hypothetically interested" has become "hard not interested".
The requirement to break up with her if I want kids is deeply painful, but the real source of my dread is the feeling that I won't then be able to find someone good in time. I'm very glad you found someone good to have a family with.
I'll give you my answers to your questions as someone writing production JS/TS. Answering your questions is precisely illustrative of why hooks issues are hard to catch.
unexpected null/undefined values
This is an issue and has led to bugs. Switching to TS and making the compiler flag them fixed it.
mistyping variable or attribute names
Not an issue. Code obviously breaks if you have incorrect names.
using the wrong number of equal signs
This is an issue but causes few bugs. Linting generally catches it, though cute boolean punning still bites us.
failing to catch errors and handle rejected promises, etc.
This is an issue and has led to bugs.
Pretty much anything where there's some implicit details that the compiler or linters can't reason about programmers find a way to get wrong. One thing I like about the hooks linter setup is that what it encourages you to do by default will prevent most bugs, only lead to potential performance issues, unnecessary rerenders, unnecessary refetches.
I'm curious if you've used useDeepCompareEffect, the use-deep-compare-effect npm package? I've found that it is pretty reasonable foolproofing for many of these identity questions. I'm well aware of Dan Abramov's objections to the deep equality checking [1] but I still find it a bit easier for me and other devs to reason about when doing things like data fetching.
Polymatter recently had a great video on the way the college ranking system is a hustle for foreign student money, and just how heavily it distorts colleges incentives: https://www.youtube.com/watch?v=cQWlnTyOSig
I don't want to be dismissive, but I hate deploying my applications for this reason. I'm an application developer. I'm not averse to infrastructure as code, and containerization, and I'm happy to do ops for my preferred stack. But I can't learn all this stuff too.
Gassée also started Be Inc which created BeOS. Beyond being great in and of itself, BeOS was also slated to be the successor to Mac OS 9. If you're an operating system or file system nerd, you will find it very worth looking into BeOS. Gassée overplayed his hand and Apple's acquisition of Be Inc fell through.
Apple ultimately went with the NeXT / Steve Jobs combo, quite wisely, but for a long time there was a whole gang of BeOS fanboys lamenting that decision.
I've always had a soft spot in my heart for PHP style "raw query in the template". Even as we've moved away from that I feel like GraphQL recapitulates a lot of the reasons why having queries tightly bound to views is convenient.
It feels like "put the template in the query" is a great Uno reverse to "put the query in the template" and the associated issues it brings, but I'll have to think on the consequences more. Thought provoking article!
It's been a long time since I was there, but I thought there were plenty of 15,000 call site refactorings done in a single final CL. Not that the Linux kernel should do the same!
No shenanigans for any library-ish code with few dependencies that targets relatively modern Python.
I've had one or two fundamental version conflicts with a 5+ year old application with 100+ dependencies and a decent amount of legacy stuff. They were a pain in the ass, and the sdispater's stance on not allowing overrides is a pain in the ass. We ended up forking the upstream libraries to resolve the version conflict.
With all of that, poetry is amazing and a huge step forward. I'd advocate it wholeheartedly.
For those who are into this kind of thing, here's a 25 minute mini-documentary of the US electrical system's history and problems. It's more focused on wiring, but has a lot to say on plugs: https://youtu.be/K_q-xnYRugQ
I think the GitHub GraphQL API docs are particularly badly organized and basically show the API as a bucket of stuff, rather than as CRUD entities (which is how it's actually organized). I don't think this a GraphQL issue.
In a GraphQL API, tools such as Dataloader allow you to batch and cache database calls. But in some cases, even this [isn't] enough and the only solution is to block queries by calculating a maximum execution cost or query [depth]. And any of these solutions will depend on the library you’re using.
For example, if you want to index a "foreign key" id stored in each "record" in a JSON array of objects, you build a hash table from the FK id values to the JSON array indices of the objects that have that id. It can be as stupid simple as an `fk_index = defaultdict(set)` somewhere in your program, to use a Pythonism.
Now when someone wants JSON objects in that array matching a given FK id, they can just O(1) look in the index to know the position of records that match. Much better than an O(N) scan of every item in the array.
Of course you have to to maintain the index as writes to the JSON happen, but that's not bad once you understand how things work. No real secret sauce.