Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years

news.ycombinator.com

Post reply on HN
Print view View original

81–90 of 240 posts

Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years

#81

Post by acemarke »

Bilal_io wrote: post #60
sergeyski wrote: post #29

Looks similar to replay.io

What I don't like about replay.io is that it requires you to use their custom browser.

Hi, I work at Replay.io. There's a very good reason for that "custom browser" requirement.

Session replay tools like LogRocket or Jam do capture a lot of information, but they can only capture what's _in_ the page, and are thus limited by the JS execution environment and permissions. This is still very useful for seeing what the user did in the page, and you do get a good amount of detail (video, DOM, network).

Replay.io works by capturing the browser's calls into the operating system. (This is really complicated! Our fork of Chromium has thousands of lines of custom C++ and JS modifications in order to capture the runtime information and make it queryable.) That enables actually _debugging_ any line of code that ran at any time. That's something that session replay tools _can't_ do.

So, yes, both Replay.io and session replay tools let you _see_ what happened, but only Replay.io lets you _debug_ the code _as it ran originally_. And that's only possible because we do capture the _entire_ browser's execution.

We've got some sections in our docs that dive into this in more detail:

- https://docs.replay.io/time-travel-intro/what-is-time-travel...

- https://blog.replay.io/how-replay-works

- https://docs.replay.io/comparison/session-replay

Not only does Replay.io let you _debug_ recordings of bugs, we've got a Test Suites dashboard that lets you record Playwright or Cypress E2E tests _as they ran in CI_. This is possible because we can run your E2E tests with our own browser, and thus record them as they're running.

Finally, a sneak peak: we're currently prototyping some new advanced functionality that would actually _diff_ passing and failing E2E tests to figure out where a failing test went wrong, surface that info to developers, and help them identify common failure reasons in their tests ("27% of your failures in the last month were due to Apollo Client failing to connect"). Still very early, but we've got the core functionality working! Again, this is only possible because we've recorded the _entire_ browser's execution, and can then replay that browser at will and query for every bit of JS execution that happened.

Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years

#82

Post by randomgiy3142 »

We’d call these non reproducible non errors (200 for GraphQl) as “usefully wrong.” You see this in AI a lot where they spent millions in market research or ask MBA types how to recommend a product and it turns out that someone buying a new laptop tends to also want to buy new shoes. You’d get people like executives not happy they looked bad for spending money on one thing only to find out they were way off. Good news is more revenue makes people look good, so that’s not a hard problem. What’s hard is if a contact us form stops working (bad example), people stop using it but still use the app the same way and spend as much is the form and the people behind it necessary or are people brand loyal and willing to put up just with a minor bug? Similarly if we get something not working and can’t reproduce it did a network card have a low level error that propagated in such a way even our monitoring couldn’t pick it up?

I thought this was a new error in complex systems we have now with hundreds of clusters creating basically non-deterministic problems. But fine I remembered before kernels became better at talking to things like drivers and external hardware we’d see weird bugs outside our boundaries that were really hard to track down and often never manifested themselves in the same way. This is when you’d go to the weird guy no one talked to and in a week he’d have some piece of odd C code with a hex value doing logic no one understood that bypassed whatever error we were having.

It is too bad those guys that I’m pretty sure didn’t do much largely fell victim to the MBA thinking of the 90s. Now we usually will have one team go well we are calling the code right and the other saying they are sending it right and both aren’t wrong except it isn’t working so they are. We’ve reached a point where we have contracts with every vendor because the problem usually is actually like a Cloudflare :) but I’d argue it’d be far easier to just fix or create a work around and file a bug with them then spend more time on daily calls working with someone like you and knowing your progress. So I know what you mean by tools companies use. Unless it has hit industry standard we won’t even evaluate open source as we couldn’t blame someone.

Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years

#83

Post by Rapzid »

nolok wrote: post #15
thedg wrote: post #2

*engineers I work with are telling me that some of you are going to argue that types don’t exist in real javascript and that web assembly isn’t assembly

Well it's bytecode, so if you consider java or dot net bytecode assembly then it's assembly, if not then not. If we want to be pedantic, assembly is usually defined as being close to the architecture machine code, which web assembly is not. Yeah, I fell into that trap, but it's a holiday here.

I'm on holiday so I'll have a go and join the pedantic train. It's not as you say close to the hardware so it's intermediate code. And nobody argues .Net IL is assembly.

Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years

#84

Post by aftbit »

thedg wrote: post #72
Narushia wrote: post #44

Haven't heard of this before, seems very useful! God I wish there was something like this for mobile apps, though. Or a website running on the user's mobile device browser. I know Firefox Android does support extensions, but most people on Android use Chrome. And I think on iOS the browser extension situation was miserable the last time I read about it. Either way, an app would probably be the best way to do it.

Yeah! Looks like iOS safari might be the only mobile browser which supports extensions at the moment which is too bad, because the bug reporting problem is very real for mobile

Firefox on Android too, though probably ~nobody uses that.

Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years

#86

Post by modern-sapien »

Bilal_io wrote: post #60
sergeyski wrote: post #29

Looks similar to replay.io

What I don't like about replay.io is that it requires you to use their custom browser.

IDK.

Sanitizing chrome for testing makes a lot of sense as different versions of chrome have been proven to be unreliable.

Playwright uses a sanitized chrome version.

And Cypress does not, and allows users to use their own browsers which may be a reason for some not insignificant portion of flake. They definitely had multiple instances where a particular chrome version was unstable leading to lots of customer complaints regarding their reliability.

Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years

#87

Post by toekneestuck »

toekneestuck wrote: post #67
sandstrom wrote: post #55

Some thoughts: - Make the scrubbed headers configurable (if it isn't already). For example, our token header is called `X-Session-Token` and is passed on every request. Would your current regex scrub this? - Maybe clarify that the seat (pricing) is for recorders, not for people viewing them (which I think is a reasonable choice). - Would be nice to configure auto-deletion of Jams after X days. We'd probably go with 1…

[I work at Jam] - Yep, your header would be scrubbed by our default definition. And also: yes definitely, configurable scrubbing is on our radar/an inevitability. Sensible defaults has been our goal, but we're definitely aware that any given keyword may be sensitive to one company but not be to another! (e.g, an address in the context of a healthcare org's patients may be sensitive, but likely wouldn't be considered…

Quick follow up on the integration with Linear: just confirmed that we do not need write scopes on the workspace. The fix will be in production by next week :)

Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years

#88

Post by grodriguez100 »

randomgiy3142 wrote: post #82

We’d call these non reproducible non errors (200 for GraphQl) as “usefully wrong.” You see this in AI a lot where they spent millions in market research or ask MBA types how to recommend a product and it turns out that someone buying a new laptop tends to also want to buy new shoes. You’d get people like executives not happy they looked bad for spending money on one thing only to find out they were way off. Good news…

I have now read this comment three times and still don’t know what it is about.

Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years

#89

Post by giovannibonetti »

aftbit wrote: post #84
thedg wrote: post #72

Earlier quoted context omitted.

Yeah! Looks like iOS safari might be the only mobile browser which supports extensions at the moment which is too bad, because the bug reporting problem is very real for mobile

Firefox on Android too, though probably ~nobody uses that.

I do!

Re: Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years

#90

Post by [deleted] »

duxup wrote: post #22

JUST in time for me man thank you. I'm going to try it. Our company has just grown to where it isn't just some engineers and a few sales guys. Now we're trying to keep engineers working efficiently. / accurately, and the support team is ramping up. Making it easy for the sales or support guys to log a good ticket or bug is a never ending challenge. This looks like a great option. I worked in support for ages and late…

[deleted]
Post reply on HN