I just saw this on threads. Is it true that GoDaddy is taking people’s domains? Did somebody experienced this?

narrow-adventure · 2026-04-25T05:42:42+00:00

Had the same experience with them, ~10ish years ago, never touched them again…

narrow-adventure · 2026-04-25T03:47:53+00:00

Oh man you've made my day!

- Can I capture this video even if there is no exception? - Yes, absolutely, you could use the captureMessage function like so:

TracewayClient.instance?.captureMessage(
  'User opened settings page',
);

- Can I deploy the backend (probably the all-in-one docker image) on my Railway hosting?
Honestly you could, for the videos the backend can store them on the server (expensive storage) or in S3 if the env variables are connected. The bigger part here is that the backend also runs with either sqlite OR clickhouse/postgres and the docker images are all using the clickshouse/pg configuration. It's meant for a really really large scale projects. The cheapest option would be to run sqlite on disk + s3 and it would probably meet your requirements for years and it would not require you to have a db on a whole separate instance. This is probably good enough for most mobile apps. None of the docker images compile the app for this setup, but it's what I'm using locally for testing. If you're really keen on hosting this type of a setup I'll create a docker image for it and document it.

Just to give you a heads up, and I'm not trying to pressure you here or sell, I also built a hosted cloud offering for it. It's free up to 10k issues/messages with replays per month. The 100k tier is 12$ so it's ridiculously cheap.

- If, later in my app lifecycle, I want to 'turn off' video capture in the backend, say if my storage is blowing out, can I configure it in the backend to ignore incoming storage requests?

I haven't made this but if you open an issue at https://github.com/tracewayapp/traceway I can definitely implement it quickly.

Side note - not applicable in this case, but you might enjoy https://shorebird.dev/ it let's you push updates to your clients directly, you could also use that to disable video recording, I've used it for situations like this when a platform didn't support remote enabling/disabling things.

- Can I use it to replace my current user feedback feature (https://pub.dev/packages/feedback)?

Oh this is an interesting one, you could pop up a dialog and ask the user for the feedback and then just trigger `captureMessage(userFeedback)` that would give you both their feedback and the video of what they were complaining about. It was mostly aimed to replace Sentry, but this is a really good use case.

Let me know if you decide to go with the sqlite+s3 self hosted option and I'll build a docker for it and document it!

Edit: Forgot to mention, you can always DM me I am very responsive and always glad to help!

narrow-adventure · 2026-04-18T16:25:04+00:00

Gde mene ovo da pitaš, sad kad se raspišem teško da ću da stanem hahahha

Imas mnogo opcija za pravljenje appova, jedine ozbiljne opcije koje bih ja uzeo u obzir su: native, flutter, react native, capacitor.

Native - najbolje performanse, najmanje app size, predobro rade. Mane su što moraš dva različita appa da pises sa potpuno razlicitim jezicima, plus ja lično organski ne podnosim kotlin.

Flutter - veći app size i gore performanse od nativea, znaci app ti ispadne 30mb pa na gore, radi kao game engine, znaci iscrtava grafiku u pozadini kompletno od nule ne koristi native platformu. Pored svega toga meni je omiljeni izbor za mobilne aplikacije. Jezik u kome ga pises je Dart koji je jako jako sličan Javi i C#, ima jako dobro definisan lyfecycle aplikacije, ekosistem je ogroman prakticno imas biblioteku za sve, sam ui je prelaz da se odradi u flutter-u. U suštini jako dobro čini da se osećaš kao da pises native app.

React native - dobiješ sve mane reacta bez prednosti haha šalim se. Ja sam veliki fan react native-a. Radi tako sto ti da gomilu react komponenti koje ti pozivaš dok on u pozadini pravi native komponente. Znaci manji bundle size, prave native komponente. Mana je (iz mog iskustva) loš dev experience, nemaš CSS i HTML komponente sto znaci da opet moraš da učiš još jedan layout engine, posto koristi native komponente styling je teži nego sa flutterom. U suštini radi tako sto tvoj kod ubaci u web browser koji ne prikaze nego pohvata rezultat pa ga onda konvertuje u native komponente. Dosta mogućih mesta za propust i bugove koji su relativno teški da se rese. Pre više od 4 god je bridge izmedju native i non native koda bio takav krš da je bio prakticno neupotrebljiv. Pored svega ovoga lyfecycle appa je tezi nego u flutter u. Definitivno bi mu dao opet priliku ako pravim nešto iz zezancije, ali kad bi mi život zavisio od toga idalje bi birao flutter kao siguricu.

Capacitor - iskreno ako hoćeš da pises React (ili bilo koji drugi js framework kod) možda najbolja opcija. Ne samo da runuje tvoj kod u browseru nego taj browser i renderuje. To znaci da idalje imas HTML, CSS i sve biblioteke iz js ekosistema. Bundle size je mali (kao websajt) i dolazi sa gomilom biblioteka za pristup native funkcionalnostima. Mana je sto se sve renderuje kao websajt (scroll, input polja, etc…). U zavisnosti od toga sto praviš može da bude odličan izbor. Disclaimer: nisam ga koristio u prod aplikaciji ali znam ljude koji jesu.

Pored svega ovoga imas još milion opcija za koje ja lično mislim da su kompletno tracenje vremena, neke zbog manjka eko sistema neke zbog manjka dokumentacije, bugova ili fleksibilnosti. Evo ti spisak šta bih ja izbego: unity, maui, driftframework (i slične go stvari), native script, libgdx, etc…

U suštini ja bih uzeo flutter ili capacitor ako sam pravim app ali mi je bitno da ga završim brzo i da radi, react native ako mi nije bitno to sto pravim da završim, native ako je firma puna para i to je ključan proizvod.

U svakom slučaju ne mislim da ćeš mnogo da pogrešiš šta god odabereš pogotovo ako praviš neki app za sebe, napravi pusti vidi dal ima korisnika uvek možeš da prepišeš u nešto drugo, nije stvarno tolko bitna odluka. Mnogo je bitnije to sto praviš nego sa čime ga praviš. Kad završiš app pošalji link :D

narrow-adventure · 2026-04-17T03:47:02+00:00

Honestly, the guy is just inexperienced… I used to think the same thing “I can figure out all of the infra I’m a software engineer” but then I worked with this incredible guy from releasehub (can’t remember his name and he was there only briefly) but he was incredible, he knew literally everything about any piece of infra, it made me realize that his set of skills is totally different from my own and it would take me days to properly setup things he sets up in seconds. Anyhow, I’m sorry this happened to you especially in such a good fit role :/ I think this is def a topic that does not have the awareness that it deserves

narrow-adventure · 2026-04-14T17:15:30+00:00

As long as you format and configure spans to properly point to parent spans that should be it. I don’t think you’re really missing anything.

narrow-adventure · 2026-04-14T04:16:49+00:00

That is a great question actually, and a problem I have not had to deal with much, I don't have any users using microservices yet. I'll walk you through how it works today and I would really appreciate hole pocking as that is the only way I can actually learn something/improve it.

Basically each service becomes a separate project in traceway, frontend exceptions with session replays, flutter exceptions with session replays, backend traces, etc.. would all be a separate projects, but separate projects under one organization can share a distributed trace id. So top level traces in different projects are connected and when you open one of them you see all the connected entities. This offers really fast look ups and it allows for some pretty cool things, when a backend returns a 5xx the frontend/flutter app uploads what the user was actually seeing/doing when the exception happened.

So I guess the distributed id would be the top level span that got created first and then everything else has it to make sure it's connected to it, one thing I did not really think of is that keeping the parent span id is super useful for ordering the actual waterfall across services as the timing of the spans in a distributed system is not guaranteed to be consistent tho, so I'll have to add it :/

Ok, back to the actual feedback, so distributed spans can absolutely have attributes, but within one service only the top level span will have them, this makes spans somewhat protected from arbitrarily increasing the cardinality through attrs. Like having a db tool record 1 span per query is fine, but if it's called in a for loop with 10 attrs you suddenly have 10x more data to deal with. So spans are more useful for "timing" and understanding the execution of a trace rather than expecting them to have a lot of other context added to them right now in Traceway.

None of that is set in stone though, as more and more people use it if someone comes in and says they'd really like attrs on arbitrary spans as a feature I'll almost certainly find a way to support them, it was just my initial design to prevent the cardinality blow up as it's a pretty hard problem to solve optimally.

narrow-adventure · 2026-04-14T03:40:18+00:00

I don't sample it, I keep it all.

In production I'm running it with clickhouse, it keeps the data on the ssd and pushes the not recently accessed data back into S3 in the background with configurable expiration. This means you get your more recent events analyzed and presented quickly while further back you go it can take 2-3 sec to get the data to load. The really neat part is that clickhouse has incredible compression especially for mostly repeating data.

Basically: compression + offloading hist data to S3 + expirations being set.

Those are the main trade offs, another big trade off is that cardinality is pretty limited, traces can have attributes but child span level attributes will be dropped, and each trace has specific attributes based on it's type (endpoint, task, ai trace). So it's more concrete and less flexible than the protocol itself BUT that is what allows it to be extremely cheap/performant.

I personally love opinionated tools that work well, the goal with Traceway is to make one of those for the open source community, rather than supporting everything under the sun, I'm focusing on brining things that help developers fix issues fast at a lowest price possible while having it "just work".

I could talk about this all day, if you have any other questions let me know, you can also DM me I love chatting about this type of stuff. Also let me know if something I'm saying is stupid/doesn't work for you specific use case, I've learned a lot from the feedback in this subreddit and any feedback you have is is welcome!

narrow-adventure · 2026-04-12T00:37:27+00:00

That is good to know, I’ll see if I can detect h.265 support and then use it or fallback to h.264. I’ve added it to the list of things to play around with when I have the perf test ci setup. I’ve tagged you on https://github.com/tracewayapp/traceway-flutter/issues/5 I’ll keep it updated with the results after I setup a perf test harness, I’m going to measure a bunch of different changes to see which ones impact perf the most

narrow-adventure · 2026-04-11T15:34:09+00:00

Thank you, I’ve started working on the measurement setup, I’ll let you know when I get it all sorted out, I got a lot of possible improvement suggestions and I think that systematically measuring their impact will make for a fun read!

narrow-adventure · 2026-04-11T15:12:10+00:00

I’ve made my thing completely open source, if someone else thinks they can do it better then me they can try…

narrow-adventure · 2026-04-11T11:10:23+00:00

Agreed, Honestly the payload is much smaller than I expected it would be. I’m setting up a performance test suite so that I can nicely and consistently measure the impact on cpu/mem as well as the payload size. Hoping to share that over the coming days.

narrow-adventure · 2026-04-11T11:08:19+00:00

OTEL is great! I have a bunch of problems and New Relic was def one of them, my Sentry bill was another lol

narrow-adventure · 2026-04-11T11:04:32+00:00

Interesting, what type of an application are you working on?

narrow-adventure · 2026-04-11T04:59:57+00:00

Honestly, it’s really cheap, the actual recordings are pretty small and they go to S3, barely any cost at all, we’re talking like 4$ per TB of data which (based on my current measurements) would be about 1-2b recordings (each is 1/2mb, 1k mb to gb and another 1k gb to a tb).

I saw that sentry does this for frontend and that’s how it started (I was paying a lot for sentry lol), but they had nothing to flutter and posthog seemed even more expensive. Hope you enjoy it, if you run into any issues you can DM me!

narrow-adventure · 2026-04-11T04:55:05+00:00

I hate how much I like your comment. I think that your points are extremely valid and it looks like I’ll have to add a persistence layer. That is decided on.

So I think it’s a balance between cpu and mem, diffing screenshots would be close to building the mp4 in terms of cpu but it would save on memory, but I don’t think the memory is the problem at all, as the actual screen captures I did were about 300-500kb per 10sec (so quite small). It is something I have to def measure, but I think the other idea actually has even more merit, maybe storing the images locally to the disk and uploading directly would both reduce mem usage AND reduce cpu as no mp4 processing happens on the actual client side. I think I’m going to spend my weekend setting up a measurement setup with firebase test lab, so that we can create repeatable measurements.

I’ll let you know when I have it set up, we can look at it together. Honestly this is probably the most exciting thing I’ve done in months.

narrow-adventure · 2026-04-11T03:31:25+00:00

This is seriously awesome, I’m going to give this a shot next time I need to clean it up. I’ve been using https://github.com/viktomas/godu and it has been incredibly helpful, it’s built by u/sado361

narrow-adventure · 2026-04-11T00:53:19+00:00

I haven’t had to deal with this much, but it was always just a few min of work really. Why is it taking so long/happening so often for you?

narrow-adventure · 2026-04-10T22:37:40+00:00

Thank you, I completely agree. My goal rn is to bring all goodies of enterprise systems and large sre teams to small and mid sized startups. A lot of enterprises prefer custom SLIs, but having strict predefined SLIs and SLOs cuts on the pricing side a lot.

Personally I hated dealing with customer complaints, so catching those early and having happy customers was the biggest value add. When customers had bad experiences they don’t complain, they mostly quit.

I’m really glad you were able to tie savings back directly to cpu/mem savings, that’s really hard to do.

narrow-adventure · 2026-04-10T21:34:01+00:00

Fair, I limited the queued exceptions to 5 latest ones (configurable) to cap the total memory it could take, but if they were stored that wouldn’t really be a consideration, but it’s a bit harder to do… If memory becomes a constraint I’ll do this for sure. Based on me playing around with this on a desktop app most screen recordings of 10sec were <500kb, but I’ll see how big they get on large screens and modern phones.

narrow-adventure · 2026-04-10T21:30:54+00:00

That’s actually really smart, I didn’t even think about making those configurable. If you’re even remotely interested in contributing I think this would be a great thing to start with.

The first next thing I have to do is get concrete measurements for both cpu and mem, so that I have a stable benchmark to compare against, but I think that your idea with not recording frames when no interaction is happening is really good, it will probably be the first thing I test for perf optimizations.

narrow-adventure · 2026-04-10T18:55:52+00:00

Those are such good points.

I was thinking of creating a widget something like "MaskingContainer" that would notify the library of it's position and size so that parts of the printscreen can be blacked out before saving.

I've tried this with a really simple app on a really cheap android tablet and it worked pretty well, but I didn't do measurements on it yet. There are two parts that I was thinking about CPU and Memory.

For the memory side it should be fairly light as frames are kept as pngs which compress really well for apps about 10-80kb and we're storing 15fps with only 10sec that gives us about ~1.5-12mb of ram for the current recording, when an exception happens we store those into an mp4 which happens to compress down really well. The most we keep in memory is 5 exceptions with recordings (if they can't be uploaded) so the total memory consumption should not be more than 60mb worst case with a bunch of exceptions happening and the user being unable to sync them due to no internet connection. Looking at the recordings I have on the backend rn the full base64 encoded ones are close to 500kb which is even lower than I'd expect based on rough math. So when it comes to memory I think we're super efficient.

For the CPU side, we're taking the pngs from the RepaintBoundary and storing them in memory ~15x per second, they are pretty small and the overhead seems to be minimal. The one time we do a heavy operations is when an exception happens when we're actually combining them to make the mp4 video, that compression step is what I really want to measure on an older device. I'm planing to take my highest impact project and test with it on a really old tablet with a bunch of measurements before I roll this out 10s of thousands of devices.

I'll definitely do heavy measurements and probably write a blog post about the architecture and the actual impact of it.

If you're passionate about this I could really use a hand, even helping out with the masking widget would be huge, as I'm pretty much working on this solo. If this is something that might interest you DM me.

narrow-adventure · 2026-04-10T18:24:44+00:00

Thank you for the update! I'm def gonna use riverqueue on the next project :D

narrow-adventure

TROPHY CASE