looking at the docs and examples, I see Workflows and Steps and Retries, but I don't see any Durable yet. none of the examples really make it clear how or where anything gets stored
That depends on the “world”. We built an adapter interface so you could store the data (and other things) anywhere you want. There are some docs which are wip regarding that: https://useworkflow.dev/docs/deploying/world
As for calling it "*source" and saying "oh we're not pretending its open source"? This is a point of opinion, but I think that's disingenuous marketing, at best.
Sentry's been around for ~15 years, and has been using a license fitting the Fair Source definition for ~5 years. This is not a "hastily preparing ourselves to be acquired" sort of move. What makes you think this is a sign of some impending change?
Sentry's pricing plan has never gone from 10k errors straight to "negotiated enterprise deal"; you must have missed something. I say this having been a Sentry customer for the past 7 years across multiple companies, always with a paid plan beyond 10k errors and never with an enterprise deal.
So, they now go from 50K (which sounds close enough to '10K 5-or-so years ago', right?) errors to "negotiated enterprise deal", and I have no idea whether that's worth it?
Do they coalesce errors these days? Again: I would love to use services like these, and I even don't mind getting a customized pricing plan, except that nobody like, ever, seems to want to talk about even the most basic details?
"Just give us your credit card number, and we'll see what happens, we'll make it work"... Right! But, but by any means, go and complain on HN that's it impossible to get paying customers...
I would recommend reading more of the pricing page. You'll learn that:
- $312/year and $960/year are for unlimited users, not per seat
- Additional error/event volume is priced separately from the base plan
- You can pay for error volume, either prepaid or on-demand, without a custom enterprise deal:
> Each of our plans comes with a defined quota, with the option to process additional events by setting a pay-as-you-go budget. You can also plan ahead and save 20% over the pay-as-you-go rates by reserving events.
What's the concern here? The pricing is transparent, and yes we've adjusted it over the years to be more in line with our costs. We still charge you per error just like we have since I started the business, and we're very honest about that. If you scrolled down you would see a full transparent pricing calculator for all of our product offerings.
wrt Enterprise, you seem to not be the target person. Its primarily about access to humans. Terms, liabilities, SLAs, services, etc. If you are FAANG scale, yes it is about price negotiation as well. When you are in the buying cycle at a company that needs these kinds of things you are well accustomed to this kind of thing.
1. A single component in my app causes the same error over and over again, every second or so
2. This causes me to run out of my 10K, 50K, or whatever, fully paid-up 'Teams' or 'Business' allowance within the first day, and then my account gets disabled
3. Once my account gets disabled, my only option is to "contact Sales" and they never reply to me (in the case of Sentry), or quote me an amount that I'm simply unable to pay (in the case of many other similar services).
So, you could address this concern by stating that you now coalesce similar errors, and that my scenario is no longer an issue. Or, you could just punt me to a sales contact. Or, just, basically, tell me to "get gud" and get back in touch once my services have proper error handling.
Instead, you chose to pretend that I can't write properly, which, frankly re-confirms my notion about Sentry: RUN AWAY WHILE YOU CAN! This goes doubly for employees, BTW, so... consider yourself informed!
1. You have a burst of errors - typically this happens first month when people dont understand their volume, or they had a runaway bug.
2. We rate limit/throttle you for your billing period. We also provide some tools that we'll eat various cost for periods of time (such as Inbound Filters and Spike Protection).
3. You never have to "contact sales", but you're certainly welcome to email support, and they almost always will forgive your volume.
It sounds like you want us to pick up the cost, which sure, sounds great as a customer, but we're trying to build a long term sustainable business. We can't just accept infinite data and not charge for it. All of that costs money, and while in some less common scenarios you can dedupe client side (we do), mostly they have to hit our servers, and that has a cost associated.
"they have seemingly just ignored the better option...obviously much nicer"
This comes off a bit presumptuous. I would assume that they are aware this is a possibility.
"having to use a web service to view you stack trace"
This is just not a downside that matters for this usage scenario. It's almost the same story as minifying your frontend JS bundle, uploading source maps to Sentry, then using Sentry to view an unminified stack trace from a user's browser. The user was never going to view that stack trace anyway, and I am not bothered by having to use Sentry to view it - I never would have seen it at all otherwise.
> The user was never going to view that stack trace anyway
Speak for yourself.
The ability to understand and affect what's going on in your own user agent is important not just to users having control over their own devices, it changes the social fabric. You can't get interested in how something works because to you it's an opaque blob whose priests have declared you unworthy. Curiosity suppressed. That's bad for the kids.
Bun is open source, right? If you want the debug symbols then build them. This feature is for the users who don’t want to debug Bun and simply submit a comprehensive report, which will be the majority of users.
Bun is MIT licensed, meaning any derivatives aren't required to give you source code. But it's more about the principle. People do the same thing in web pages and give you minified gibberish "to save bandwidth". Meanwhile the hot garbage is still a megabyte of JS. Maybe cut some of the bloat and keep the human-readable text which is known to be efficiently compressed by ordinary lossless compression algorithms.
> This comes off a bit presumptuous. I would assume that they are aware this is a possibility.
They don't present it here, they justify their solution by claiming that the existing solution is bad because it includes several megabytes of debug symbols.
The creator of Vue pointed out a new feature for Svelte was a similar feature that Vue had tried and discarded. The creator of Svelte showed up to explain their position; I thought their exchange was illuminating. I was also impressed by Vue's research & experimentation.
> The user was never going to view that stack trace anyway,
Well akchually, I found stack traces useful as a user. It allowed me to pinpoint an issue (SPICE simulator crashing due to inconsistent quote handling in E-sources vs another simulator which did not crash). IDK how else I'd be able to find this other than file a Jira ticket to the simulator team (and then wait 2 days for various people to pass the ticket, as they almost always do)
Yeah that’s my reading. No way this is passing Akamai bot detection.
There are lots of signals like timings, user tapping and scrolling behaviour, signed sessions cookies that represent browsing flows which may be legitimate or not. And that’s all assuming you’re on a good looking IP. To do this you need a large supply of residential IPs which then leads to the dodgy underworld of botnets.
I’d be surprised if this works for anything but the most basic bot protection, this is an advanced space.
If it does work for those cases, they should be either keeping it quiet and making bank, or boasting about having a secret sauce, not basic stuff like this.
Edit: for apps, Akamai provides an SDK that uses things like your motion data to create a signature that suggests that you're a real user. This signature is either injected into API requests or into a webview session. I'm sure it's crackable if you dedicate significant reverse engineering resources to it, but then you've got to crack every version, crack every other implementation from other companies, etc. Non-starter.
When it comes to "motion data", are you referring to the client's movement around the website, i.e. which URLs they access and in which order? Their taps, clicks, scroll events, and other inputs?
Motion data (especially in the context of an SDK, which I assume means they're talking about in-app environments rather than browser environments) usually refers to gyroscope readouts on a phone or tablet.
A device that stays rock-steady throughout an entire browsing session isn't necessarily suspicious on its own—for example, you could have your phone laid flat on the table while your browse with your pointer finger—but it can be a useful tell in combination with other suspicious factors.
Asking out of almost total ignorance of this field, what prevents someone from running a script that sets their agent to a phone browser and then sending fake gyro data? Surely there's a way to emulate enough to make it look like a phone that's being held by someone, right? We can do realistic camera shake in blender to the point where something looks like it's being held by a person, why couldn't we fake minute movements like the device is held?
Why do we even need an actual device? We can emulate if we even need to and set our headers to look like we're coming from a device browser.
I'm sure that happens, but I haven't done any work with gyro data myself. There's similar logic for mouse cursor movements, there are libraries out there that will generate a natural looking curve that moves the cursor from one position to another, with imperfections that emulate human hand movement.
> Why do we even need an actual device? We can emulate if we even need to and set our headers to look like we're coming from a device browser.
This one is much harder, your browser, OS, and hardware leave a uniquely identifiable fingerprint (with Javascript enabled). A website can render some graphical pattern on a <canvas> or audio in an audio context, and the resulting output will have minute differences that originate from your rendering and audio pipelines.
You can try to fake these, but it all depends on the sophistication of the target website. You can quickly end up in really deep rabbit holes: https://www.nullpt.rs/devirtualizing-nike-vm-1
It does for the browser APIs, however Akamai provide an SDK to embed in your app, and apps do not require permission for gyro data. Then the standard practice is to a) pull a token out of the SDK for any API requests you make, and b) connect the SDK to any web view instances via the JS bridge so that any requests made in the embedded browser also get the same tokens.
For web-only, I believe they have a JS only bundle that your site can include which I would imagine does different things, but which would also bring a higher risk profile associated with it. Sites use these risk profiles to determine things like whether to offer specific services, whether to ask for more authentication, etc.
Ah! That makes more sense, I thought we were talking about the web.
That said, since I wrote that comment, I found out that on Android, both Firefox and Chrome grant access to gyroscope data without a permission dialog, which is extremely surprising. I don't have an iOS device to verify, but apparently Safari gates the API behind a permission dialog.
It's a never ending battle. Lots of tools aren't as sophisticated as they claim to be, and the current mechanisms inject a lot of "other stuff" that can be easily found. We're trying to do this in a more novel way that's faster, less prone to needing frequent updates, and is more akin to how actual users interact with browsers. Definitely work to be done, but it's exciting to see, and I appreciate the good luck!
APoSD is a relatively quick high-signal read, and not really a source of additional chaos. You can get through it in a weekend or less.
It mostly gives you vocabulary and labels and explanations for things that you may already intuitively understand, and teaches you to notice small things that matter. It will probably make it easier for you to discuss and dissect some of the chaos you're already dealing with.
Love Kysely, been rooting for it ever since it was first released. Paired with kysely-codegen, it's my favorite TS <> SQL interface. Does just enough, but not too much.
Had lots of good experiences working with Knex.js over the years, and Kysely is the TS-native spiritual successor to Knex.
Yea, DuckDB is a slam dunk when you have a relatively static dataset - object storage is your durable primary SSOT, and ephemeral VMs running duckdb pointed at the object storage parquet files are your scalable stateless replicas - but the story gets trickier in the face of frequent ongoing writes / inserts. ClickHouse handles that scenario well, but I suspect the MotherDuck folks have answers for that in mind :)
looking at the docs and examples, I see Workflows and Steps and Retries, but I don't see any Durable yet. none of the examples really make it clear how or where anything gets stored