3 ms·
We have generally followed that for years, this is great! A few big missing areas: - node is also often the best for - 'backend for your frontend' ( batching/c
by lmeyerov 5y ago
We have generally followed that for years, this is great! A few big missing areas:
- node is also often the best for - 'backend for your frontend' ( batching/caching, ...) which adds a bit more complexity
- structured logging should really be tracing given the heavy async + services nowadays
- This architecture is normally done as part of some scalable m:n mapping, which is alluded to, but can be a full article to itself (tools, patterns, manual/auto operations, ..)
We have been moving Graphistry's regular stateless web backends to python as it converges with node on async but is easier to do our GPU + AI data services (and other reasons).. but been generally keeping our 'backend for the frontend' parts here. This could have been part of a primer in our internal docs, so bravo!
- Spivak 5y ago> structured logging should really be tracing given the heavy async + services nowadays I’m a huge huge proponent of tracing but god I wish it wasn’t necessary. The inability for most programming languages to serialize and produce a sensible async stack trace is a source of constant pain that tracing bandaids over. The state is right there dammit! There’s one thread, the event order is centrally controlled and serializable, you have all the stack frames, just put them together, don’t make me keep a log just to know what actually happened in a program that isn’t at all random.