zknill

Wish I could see the source, hosted. Without having to download the zip

GPS traces recorded on a watch can be pretty noisy. If you stand in the same spot for a while, you're not going to get the exact GPS position recorded for the entire time you're there. The same happens when you move, it's not a smooth trace.

Strava (and I assume to some extent Garmin) apply some smoothing to these raw GPX traces to try and improve the path, or remove some of the noise.

You'd be missing out on this post-processing by taking the data raw. Ofc you can implement something similar yourself, but I wanted to point out that these platforms are doing a little bit more than just displaying the GPX trace.

I read the first two paragraphs and the post presumably criticising folks for using AI is so clearly written by AI. It's got all the tell tail claude-isms in it.

Analogies about 'students and exams' that don't quite fit. The sentences ending in artificially punchy short phrases. The 'correction' and dash-as-reveal in "they can't answer it - no one can".

It's not good, or a compelling read, and I think it's lazy not to have swept through and fixed these things.

I'm really put of reading ai-isms like "It quits working around the fourth time, and the average hides who it worked for"

This is classic Claude, and makes me think the author didn't read, edit, or invest in their own words.

The original Typescript version of the AI SDK has two parts. A backend part called Vercel AI-SDK, and a frontend part called AI UI SDK.

When you make an LLM call, if you use the streaming responses (typical of token streaming into applications) then the response from the LLM provider comes in a specific format; mostly made up of individual json events, one for each text-delta or token generated, and some framing around start/stop. That API format differs across different LLM providers, and also isn't that convenient to process for what you actually want to show in the client/browser.

The backend portion of these sdks (AI-SDK) are an abstraction over the LLM provider, and re-write the 'events' that you get back from the LLM provider into an abstracted json format that's a little bit easier to work with. And not coupled to a specific provider.

The frontend portion of these SDKs (AI UI SDK) helps you to render those message into a frontend interface, and uses the same abstracted format that the backend uses.

There's one big missing piece though, and that's the fact that the transport between frontend and backend is over a single HTTP+SSE stream. If that connection fails, all the work that the backend is doing cannot be transported to the frontend anymore. The HTTP connection also doesn't allow for useful features like cancellation, steering, interruption, and multiple devices.

If you want those, checkout Ably AI Transport, which targeting the _transport_ section between backend and frontend, to make sure you get reliable experiences in the UI regardless of which AI provider or SDKs you use.

Disclaimer, I work for ably on this product:

https://ably.com/docs/ai-transport

This is a backend written in go that's wire-protocol compatible with the (catchy named) Vercel AI UI SDK; which is an SDK for helping to build AI chat apps. The original Vercel AI SDK backend is in typescript.

I think they really missed the opportunity to add in resumable streaming after a dropped SSE connection, or multi-device support. Because these SDKs are easy to drop-in to your applications, but hard once you actually try and build resilient systems on top of them. Systems that can heal from dropped connections, or support multiple users or multiple devices.

Yeah, with only minimal guidance it's what you get out of claude. The colours and layout are pretty 'default'.

How do you know?

There's a lazy habit from some folks to say something they either disagree with or don't understand was "written by AI" without backing up that statement.

Isn't the point that you no longer have a connection to the client?

So you can be notified by the database, but you can't (with the stateless HTTP + loadbalancer design explained in the article) get that notification back to the client. Because the client isn't connected anymore; so how does the client know that there's new information?

The industry decided a long time ago that sticky sessions was a terrible idea. They only half-solve the problem, while suffering from session loss on server loss and imbalanced load over time.

And once those long running jobs have reported their status back to the database, how will the client find out about that status?

Please, please, please don't say "polling". Because you've clearly missed the entire argument of the article if you say polling.

would be nice to see an example linked

Folks will probably say, 'I just use cmux, or tmux, or tabs, or warp'. But I do appreciate it when the original project makes an attempt to solve the problem.