There isn't much information about correlation. What are the state-of-the-art tools and techniques for observability in stateful use cases?
Let's take the example of an SFU-based video conferencing app, where user devices go through multiple API calls to join a session. Now imagine a user reports that they cannot see video from another participant. How can such problems be effectively traced?
Of course, I can manually filter logs and traces by the first user, then by the second user, and look at the signaling exchange and frontend/backend errors. But are there better approaches?
In good hands, any product development process works well; in bad hands, any product development process fails. It is not about processes, methodologies, or frameworks - it is about people and what people do.
> they basically disqualified themselves from the start by nerfing the "core" version so bad it was useless
Ran the core version for around 3 years in production for a smart city project. The company I worked for has been running it for around 6 years. Not sure what you are talking about. Of course, we would love to use features like stale replicas for exports. But this isn't something we absolutely need.
At large? As you can see, there is room for a community with a different view on that. My personal definition of an "open source license" is that, as the name implies, I can access the code, preferably without much gatekeeping (e.g., creating a free account in a private GitLab instance). And, to be honest, I prefer the BSL with an Additional Use Grant over any other license, because this is the most reliable option to ensure that the project has a future and won’t be abandoned because no one wants to invest their time for free.
+1. It even looks very similar to TypeScript. Why not use TypeScript as a description of APIs in the first place? Get TypeScript types and even generate OpenAPI schema on the fly to serve it at `/openapi`?
Some commands are used so often that it makes sense to further shorten them by placing them in `.bash_aliases` or a similar file for your favorite shell:
If I understand it correctly, it exchanges execution speed (by not using JIT) for faster starts. Instead, they could pick up the old FB project https://prepack.io/ to optimize both start AND execution speed. It would be very interesting to see it together with node's snapshots: https://blog.logrocket.com/snapshot-flags-node-js-v18-8/, which reduces the start significantly.
I'd like to highlight dprint [0]. It is not as opinionated as Prettier, and its AST-node-specific configuration is awesome [1]. Deno uses it under the hood for `deno fmt` (and switched from Prettier [2]), and the TypeScript team uses it for formatting their code base (switched from formatting by ESLint [3]).
Unfortunately, bun is unusable due to a myriad of bugs. I closely monitor every bun release, hoping it will function well beyond simple node use cases. The idea is amazing, and I would love to switch to bun, but looking at the issues - no, not yet. How can I trust bun to be a secure runtime with all these bugs?
1. An E2E system where the provider has de facto access to the encrypted data, or
2. You shift key management to the users and let them risk data loss.
Either way:
a. The provider can release an app version at any time that accesses the data on the client side, and
b. Most of your users cannot differentiate between E2EE and SSL/TLS, nor are they interested in doing so, nor they care about it.