HN user

ilkhan4

89 karma
Posts0
Comments68
View on HN
No posts found.

I haven't read through the entire thing yet, but looks conceptually similar to Zenstack (https://zenstack.dev) with the auth plugin and auto-generated APIs, so I'd be interested in a comparison with that.

Fwiw, I went down the path of trying to do something similar with Drizzle and gave up since it was in such a state of flux (this was last year). There are (were) a ton of edge cases around trying to add automatic filters to queries to the point that it was hard to justify not just rolling my own ORM.

A few questions/comments after skimming the docs:

- How does authz work? Can I use Postgres RLS? If not, how would you address row or column-level permissions in a system that uses this? - If you're using logical replication to sync with PG, is there a limit to the number of clients you can have connected? I see there is a lot of work around de-duping live queries, but how well does that work in practice? - Any thought to making an extension for Postgres? My main hesitation right now is that I have to go through an NPM package to use this but a lot of our tooling expects a plain Postgres connection. - REALLY looking forward to seeing how the schema migration story looks.

Overall, it seems to address most of the use-cases where I'd reach for an ORM or API server so I'm really interested to see where this could go.

I haven't used Codex, but my process is the same with Claude Code as if I'm writing the code: branch off of main, tell it to write code. If I like it, commit the code. If I don't, revert the code, then tell it I reverted the code and it should do something different.

I commit on the branch about as often as I did when writing code manually: before I'm about to do something big or try something that might break other things.

I'll push the metaphor a bit: I think the point is that if you have a fleet of vehicles you want to fuel, go ahead and get a fuel truck and bite off on that expense. However, if you only have 1 or 2, a couple of jerry cans you probably already have + a pickup truck is probably sufficient.

This argument is always kind of silly to me. You really think they'd use a weapon of mass destruction just to take out a few people they don't like? On their home soil? I mean, I find myself being surprised by Trump daily, but still... It's far more likely that they'd use more surgical means, like the ICE raids, to root out people they don't like. In that case, I'd say being armed would make at least somewhat of a difference, or at least give pause.

Some guys with AK-47s kept the world's most powerful military pretty busy for 20 years, so I wouldn't underestimate the value of a few rifles against authoritarianism.

As someone who has been in the market for something like this, can I ask why it's a monthly subscription? I don't think I would be generating a new brand identity every month so it would make more sense to me to pay a one-time fee for x number of iterations. I have a little subscription fatigue so I'd actually pay a bit more to not have to remember to cancel it.

You can get a 1 -> 4 M.2 adapter for these as well which would give each one a 1x PCIe lane (same as all these other boards). If you still want spinning rust, these also have built-in power for those and SATA ports so you only need a 12-19v power supply. No idea why these aren't more popular as a basis for a NAS.

I’ve always wondered why something like this isn’t a thing. AWS ECS had a half-hearted feature to deploy docker compose setups but they discontinued it awhile back. We use compose to run our app locally so it would be nice to just deploy that.

Like the other response, my concern would be reliability on a new service, but I’d use it after it was around for a year or two.

Cybiko 1 year ago

This brings back memories. For some reason, my (at the time) girlfriend and I were gifted a pair these in my first year of college. I didn't have much use for them by then but they would have been pretty cool in middle/high school!

I've wondered this too, and I even tried to build one a few years back, but I came to the conclusion that most people who care that much about audio don't really care about open source or hacking hardware. They like buying a big, expensive black box that just does the thing and are fine upgrading every few years. Everyone else buys sound bars and there's not much in between.

Yeah, this has been my experience too. The mentality seems similar to "productivity hackers" who spend more time figuring out the quickest, most optimal way to do a thing than people who just do the thing.

Wow, I thought you guys were just reselling Neon like some others. This is genuinely impressive technically. It's got me looking at Unikraft Cloud for other stuff too.

That said, do you plan do offer branching or any other features that Neon offer? I think that's their big selling point along with separate billing for compute and storage.

In my experience, it's not really about the individual pieces of information, it's more about being able to build a more complete profile of someone. Most verification is built on the number of factors to build a trust score and having something with a picture, address, and additional ID number would give them another factor. That might be enough to put them over whatever threshold they need to open a bank account, credit card, loan, whatever.

I have not tried that, no. I'm not even sure what a SOTA model is (which is my other issue with AI right now: the fragmentation). Sure, the AI design can be done quicker and may be "better" by some objective measure. However, can it present its model to upper management in a coherent way to justify the budget it is about to be given? Can it translate this design into a series of tasks for (surely AI) engineers to implement? Can it deal with late-breaking changes to the design based on new requirements? You'll tell me it probably can, or shortly will be able to. The thing is, as long as humans are making the ultimate decisions, they'll probably want another human in the loop somehow, at least within this generation.

I mean, look, there's no one who wants to stop having to write code more than me. Our industry is full of make-work and pointless drudgery for no reason and I'd love to see that be made pointless by AI. But there's the old quote about overestimating the short term progress and underestimating the long term progress that applies here. Your version of "awhile" is probably pretty similar to the "awhile" of people excited about past technologies. As another comment pointed out, we engineers have been trying to automate ourselves out of a job for quite a while now and I don't see this being much different. I'm old enough to remember the 4GL fad and people were just as breathless then that you didn't need those pesky engineers anymore and soon you'd be able to do similar things as AI is promising. Low-code was a thing recently too. These things gradually chip away at the skills you need to make things happen, but something has to ultimately be responsible for the results and that's where humans come in.

I promised myself I wouldn't respond to these anymore but I can't help it.

Separate filtering from retrieval

Why? What does this buy you? You're already doing stuff in the DB. Why make another round trip after the application layer has decided it needs more stuff? We did this everywhere in a previous iteration of the app I work on and it was terrible for performance. You might actually make the DB do more work here since it has to do double the queries (and connection overhead).

Avoid performing operations on returned results

I guess this is the one valid point but honestly I haven't run into this much beyond some averages and summing (e.g. a balance is the sum of debits and credits). I'm okay with having those in the DB because they rarely change. What happens when someone wants to filter on one of these calculated values, though? Do you do that in the application layer too? How does Bob use his BI tool to get the data he needs from your application layer?

Move joins into the application layer

Yep, ship all the data over the wire then write your own code to match them up. More code to maintain and possibly slower! Again, what is this buying you other than some handwavey, vague promise of "scalability"?

There are reasons not to put logic in the DB but I don't feel like these make a good argument. Someone will keep parroting these points, though, all in the name of made-up constraints (e.g. "must scale") that were never actually needed. After all, with the architecture he proposes your app will be bottlenecked on the DB either way so might as well move the point that it happens further back. It's a sample size of 1, but every project I've worked on has had positive performance benefits by moving computation closer to data rather than just adding computation. By doing that, we didn't have to "scale" until much later.

Does it make sense to put all of your logic in the DB? Probably not. Does it make sense to put some logic there? Maybe! Test, evaluate and have an exit plan if it doesn't work, but absolutely never, under any circumstances listen to absolutes like this article.

I think it will be the opposite, actually. AI seems to be eating the bottom, but there is still demand for higher level decision making that seniors or architects do. The stuff that I would usually delegate to junior devs, e.g. "move this button" or "change this column" are the things it can easily do now and in the near term. But questions like "How should I design this system" are not and I don't see that happening for a while. People who are good at that will still be in demand since a good number of businesses still want a person they can talk to an make evaluations with.

Yeah, and this is probably sufficient for most common cases if we're being honest.

Immutability and bitemporal querying are nice features in Datomic, but the trade offs for most teams are an unfamiliar query language, unfamiliar runtime/hosting requirements, unknown performance footguns, little if any integration with 3rd party tools, and (until recently) licensing costs. If it were me, I'd probably deal with the headache or complexity of adding triggers/permissions and audit tables to Postgres to get that functionality if all of those other things are solved instead.