31–40 of 278 posts
Everyone is surprised at the $300k/year figure, but that seems on the low end. My previous work place spends tens of millions a year on GPU continuous integration tests.
The docs indicate there are already 2 other go implementations. Why not just use one of those? https://docs.jsonata.org/overview.html
The bad engineering part is writing your own replacement for something that already exists. As other commenters here have noted, there were already two separate implementations of JSONata in Go. Why spend $400 to have Claude rewrite something when you can just use an already existing, already supported library?
Earlier quoted context omitted.
I wonder if you've ever worked on a web service at scale. JSON serialization and deserialization is notoriously expensive.
Would it be better or worse if I had that experience and still said it's stupid?
I'm just kind of confused what took them so long. So it was costing 300k a year, plus causing deployment headaches, etc. But its a realitively simple tool from the looks of it. It seems like their are many competitors, some already written in go. Its kind of weird why they waited so long to do this. Why even need AI? This looks like the sort of thing you could port by hand in less than a week (possibly even in a day)…
> it must have that architecture for a reason, we don't enough knowledge about it to touch it, etc.
That or they simply haven't had the time, cost can creep up over time. 300k is a lot though. Especially for just 200 replicas.
Seems wildly in-efficient. I also don't understand why you wouldn't just bundle these with the application in question. Have the go service and nodejs service in the same pod / container. It can even use sockets, it should be pretty much instant (sub ms) for rpc between them.
>The approach was the same as Cloudflare’s vinext rewrite: port the official jsonata-js test suite to Go, then implement the evaluator until every test passes. the first question that comes to mind is: who takes care of this now? You had a dependency with an open source project. now your translated copy (fork?) is yours to maintain, 13k lines of go. how do you make sure it stays updated? Is this maintainance factored…
probably another AI agent at their company, who I'm sure won't make any mistakes
The key point for me was not the rewrite in Go or even the use of AI, it was that they started with this architecture: > The reference implementation is JavaScript, whereas our pipeline is in Go. So for years we’ve been running a fleet of jsonata-js pods on Kubernetes - Node.js processes that our Go services call over RPC. That meant that for every event (and expression) we had to serialize, send over the network, ev…
edit: saw the total raise not the incremental 30MM
The key point for me was not the rewrite in Go or even the use of AI, it was that they started with this architecture: > The reference implementation is JavaScript, whereas our pipeline is in Go. So for years we’ve been running a fleet of jsonata-js pods on Kubernetes - Node.js processes that our Go services call over RPC. That meant that for every event (and expression) we had to serialize, send over the network, ev…
The original is ~10k lines of JS + a few hundred for a test harness. You can probably oneshot this with a $20/month Codex subscription and not even use up your daily allowance.
>The approach was the same as Cloudflare’s vinext rewrite: port the official jsonata-js test suite to Go, then implement the evaluator until every test passes. the first question that comes to mind is: who takes care of this now? You had a dependency with an open source project. now your translated copy (fork?) is yours to maintain, 13k lines of go. how do you make sure it stays updated? Is this maintainance factored…
That's only important if the plan is to stay feature-compatible with the original going forward. For this case, where it's used as an internal filtering engine, I expect the goal is fixing bugs that show up and occasionally adding a feature that's needed by this organization.
> This was costing us ~$300K/year in compute, and the number kept growing as more customers and detection rules were added. Maybe I’m out of touch, but I cannot fathom this level of cost for custom lambda functions operating on JSON objects.
I do have some questions like:
* Did they estimate cost savings based on peak capacity, as though it were running 24x7x365?
* Did they use auto scaling to keep costs low?
* Were they wasting capacity by running a single-threaded app (Node-based) on multi-CPU hardware? (My guess is no, but anything is possible)