If the first commit was two weeks ago, how did it ended up saving 500k a year already? Did they mean expected to save?
We rewrote JSONata with AI in a day, saved $500k/year
151–160 of 278 posts
Re: We rewrote JSONata with AI in a day, saved $500k/year
#152The 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…
You build something that's a dirty hack but it works, then your company grows, and nobody ever gets around to building it.
I was at a place spending over $4 million a year on redshift basically because someone had slapped together some bad (but effective!) queries when the company was new, and then they grew, and so many things had been built on top they were terrified to touch anything underneath.
Re: We rewrote JSONata with AI in a day, saved $500k/year
#153Re: We rewrote JSONata with AI in a day, saved $500k/year
#154The 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…
A human writing some poor, but working code that is supposed to be a demo, goes to production 9 times out of 10.
Then it becomes critical infrastructure.
Then management cannot understand why something working needs a rewrite because there's no tangible numbers attached to it. The timeless classic developer problem.
We were here ^^^^ up to 2024-2025.
Now, with LLMs, you can at least come up with a vibe coded, likely correct, likely faster, solution in a morning, that management won't moan at you about.
Re: We rewrote JSONata with AI in a day, saved $500k/year
#155The 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…
Kubernetes, app engine, beanstalk all are huge money sink
All managed services like cloud datastore, firestore all tend to accure lots of costs if you've good size app.
These are quick to start when you don't have any traffic. Once traffic comes, you the cost drastically goes up.
You can always do better running your own services.
Re: We rewrote JSONata with AI in a day, saved $500k/year
#156The 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…
Most of the other replies to this hit the nail on the head. A human writing some poor, but working code that is supposed to be a demo, goes to production 9 times out of 10. Then it becomes critical infrastructure. Then management cannot understand why something working needs a rewrite because there's no tangible numbers attached to it. The timeless classic developer problem. We were here ^^^^ up to 2024-2025. Now, wi…
Re: We rewrote JSONata with AI in a day, saved $500k/year
#157Earlier quoted context omitted.
The original author said he built this on the weekend, so my assumption is that this was something engineers had advocated for before but were shut down because management wanted them elsewhere. The use of ai agents allowed them to shrink the problem down to the point where it was small enough to fit in their free time and not interrupt their assigned work.
Why are engineers spending their week-end on saving their company money especially if the company clearly doesn't care to allocate resources to the problem? I get that it's fun and there's personal satisfaction in it, but it just reinforces to management that they don't need to care about allocating resources to optimisation, the problem will just take care of itself for free.
Should it be this way? No. Is it this way in practice? Unfortunately often.
Re: We rewrote JSONata with AI in a day, saved $500k/year
#158> 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. This makes me wonder, for reimplementation projects like this that aren't lucky enough to have super-extensive test suites, how good are LLM's at taking existing code bases and writing tests for every single piece of logic, every code path? So that you can th…
Re: We rewrote JSONata with AI in a day, saved $500k/year
#159The 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…
Re: We rewrote JSONata with AI in a day, saved $500k/year
#160> At Reco, we have a policy engine that evaluates JSONata expressions against every message in our data pipeline - billions of events, on thousands of distinct expressions. The original architecture choice and price almost gave me a brain aneurysm, but the "build it with AI" solution is also under-considered. This looks like a perfect candidate for existing, high quality, high performance, production grade solutions…
But if the ai built solution is slightly less stupid, then it's still a win isnt it?
That's a win for human engineers, not AI.