As for source for nuget packages, it's easy to enable source link to make that happen too, it's just that this is all pretty new so not every package is doing it.
I'm in the early days of measuring performance, and it should improve dramatically with using a lower-level port, like in Rust. To me, that library is the long-term key to adoption as it allows the library to be embedded within native camera applications.
For the current Typescript version, I'm getting the following on Node 20 with my M1 Max MBP (64g RAM):
Again, those are preliminary and entire Node-based figures on a fairly-recent MBP. I'd expect significant performance improvements with both a Rust port as well as running the existing Typescript library through the Bun runtime.
Yes, in my opinion the biggest problem with straight SQL is dynamic filters. It easily becomes a huge mess and that filter is only good for that one query, sure you can layer on stuff to make it better, but then you might as well use a library.
Sometimes you can avoid writing multiple queries with different filters by creating single parameterized query with conditions like:
WHERE (name LIKE :name OR :name IS NULL)
AND (city = :city OR :city IS NULL)
AND ...
By no means it is perfect, but can save you from writing many different queries for different filters while being easy to optimize by db (:name and :city are known before query execution).
Still, I prefer explicit SQL in webservices/microservices/etc. the code and its logic is "irrelevant" - we care only about external effects: database content, result of a db query, calls to external services (db can be considered to be nothing more than an external service). And it's easier to understand what's going on when there is one less layer of abstraction (orm)
> Well actually. They (python SDK maintainers) argue their implementation is the correct one according to the spec. See this issue thread for example.
The comment section of that issue gives out contrarian vibes. Apparently the problem is that the Python SDK maintainers refuse to support a use case that virtually all other SDKs support. There are some weasel words that try to convey the idea that half the SDKs are with Python while in reality the ones that support the choices followed by the Python SDK actually support all scenarios.
From the looks of it, the Python SDK maintainers are purposely making a mountain out of a molehill that could be levelled with a single commit with a single line of code.
As a user it feels very weird to wade into threads like this to find a solution to your problem.
The power of Otel is it being an open standard. But the practice shows the implementation of that standard / spec leads to all kinds of issues and fiefdoms
Sentry is technically self-hostable, but they provide no deployment guidance beyond running the giant blob of services/microservices (including instances of postgres, redis, memcache, clickhouse, and kafka) as a single docker-compose thing. I get why they do this and think it's totally reasonable of them, but Sentry is a very complicated piece of software and takes substantially more work IME to both get up and running and maintain compared to other open-source self-hosted observability/monitoring/telemetry software I've had the pleasure of working with.
Yeah, it works for a time, but they don't support on-premise versions and they don't offer a Helm chart install, its all community based.
I tried it for well over a year, and there are so many moving parts and so many "best guesses" from the community that we had to rip it out. There's a lot of components, sentry, sentry-relay, snuba, celery, redis, clickhouse, zookeeper (for clickhouse), kafka, zookeeper (for kafka), maybe even elasticsearch for good measure. It did work for a time, but there are so many moving parts that required care and feeding it would inevitably break down at some point.
Problem is I can't ship data to their SaaS version because we have PHI and our contracts forbid it, even if scrubbed, so I had to settle on OTEL.
PostHog and Rudderstack say the same things. They're not really self hosted. But that's the rub, if someone authored a good operator for Sentry, Sentry as a commercial service would cease to exist. That's not good in my opinion, they do real innovative stuff.
It's tough. We should have never done "give away the software, charge for hosting." The market, in every sense, has been telling you that you're really building value for AWS, for years, by doing that.
Although I do not like those licences, I would not care so much about 2yrs until it goes FOSS. Before all this rush development RRDTool and OpenTSDB was so slow, this whole thing seems rather ideological than substantial criticism. Now going down the licence rabbit hole based to criticise the original argument seems like a classical strawman.
I've been using GlitchTip https://glitchtip.com with the Sentry SDKs and I couldn't be happier. Completely self-hosted, literally just the container and a db, requires zero attention.
reply