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.

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.

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.

[1] https://twitter.com/dan_abramov/status/1104414469629898754

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.

Comments URL: https://news.ycombinator.com/item?id=30680035

Points: 9

# Comments: 1

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.

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!

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.

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.