Join 📚 Josh Beckman's Highlights
A batch of the best highlights from what Josh's read, .
One of the most common mistakes when starting with Domain Events and with DDD in general is to not go the whole way and figure our what is actually going on in the domain. It is easy to fall into the trap of naming all events SomethingCreated, SomethingUpdated and SomethingDeleted. While not a problem in itself it does not make use of the powerful thing we get by adding the context and meaning to the actual change that the Domain Event represent. You lose the intent of the event and reading the event log later will not provide that much value.
What Are Domain Events? | DDD | Serialized
serialized.io
The love is not the love one feels for a job or a lover or any of the loci of intensity that most of us choose to say we love. It’s the sort of love you see in the eyes of really old people who’ve been happily married for an incredibly long time, or in religious people who are so religious they’ve devoted their lives to religious stuff: it’s the sort of love whose measure is what it has cost, what one’s given up for it. Whether there’s *“choice*” involved is, at a certain point, of no interest… since it’s the very surrender of choice and self that informs the love in the first place.
String Theory
David Foster Wallace
The generation of a cache key is always important, but even more so with GraphQL. The dynamic nature of GraphQL queries is such that even a white space in the query could affect the key and cause a miss, even though it was the same query in the first place. A good cache key should generally contain at least:
User information (if authenticated API).
A query hash, which should be normalized as much as possible.
The variables hash (we would not want queries with different variables to be cached as the same thing).
The operation name
A cache-busting element.
Production Ready GraphQL
Marc-Andre Giroux
...catch up on these, and many more highlights
Readwise