Ignoring the disclosure etiquette here, then making an irrelevant rebuttal about relevance when the point was disclosure, then getting snarky with the person who tried to helpfully point it out?
I have no opinion on your products or your post, but some % of people steer away from companies for such things.
My views are my own and as such I do not disclose my employment or otherwise on here.
I did think twice about posting it, as I don't usually but it's relevant and i might be helpful so why not? If you don't like it, thanks for the downvote.
Wow. I learned some stuff about etiquette on HN today.
I'll support you, mnd999. I don't work for a graph dB company. We don't use graph dBs, but I'm considering it. Graph dbs are a legitimate source to feed data I to your RAG system. Our RAG system currently used hybrid search: lexical and semantic. We need to expand our sources, too. I would like to see us use LLMs to rephrase our content (we have a lot of code), and index on that. I think we should build a KG on content quality (we have millions of docs) and software out the things no one likes.
I also think a KG on "learning journeys" would be valuable, but really difficult.
I had a look 3 years ago and the compatibility matrix was an absolute shitshow: older cards not supported at all, newer cards not supported at all, and support for those in the middle was full of holes depending on extension, version, etc.
I couldn't even figure out what I needed to buy, so I didn't.
The only postgREST app I ever worked on was awful. Why? Because like most of these ‘simple’ frameworks it’s only simple until your requirements get complicated. Then the original authors had to resort to writing a ton of stored procedures on the database to get back the results they wanted and that led to scalability problems. The solution, as always, is go back to SQL.
Sounds like the team picked the wrong tool for the job. If most of your endpoints contain complex backend logic, don't use PostgREST. It's made for CRUD apps, which applies to the majority of applications I come across.
If your app has the occasional custom backend logic, you can spin up a separate server (or edge function) to handle those one-offs endpoints.
I think it started as pretty much crud and then just grew features that were more complex backend logic. But I was the one brought in to fix it, not the original architect - he had left the company at this point so I don’t know the whole history.
I use PostGREST a lot, but with strong guardrails. IMO you should always have a real API layer, and use this just for a convenience to do the base load. Like all these tools, once you go to real world requirements, adapting the tool is worse than what it is trying to replace (SQL + some language and framework).
Already PostGREST is getting complicated, additions like this will make it less attractive to me.
> Already PostGREST is getting complicated, additions like this will make it less attractive to me.
This feature[1] actually simplified a lot and removed a lot of magic assumptions in the PostgREST codebase. It goes in line with REST as well — SQL functions are REST resources and HTML is just another representation for them.
Most of the code you see here is pure SQL and plpgSQL. The only PostgREST-specific part is the CREATE DOMAIN.
Right now most users view PostgREST as a HTTP->JSON->SQL->JSON->HTTP service and we're trying to turn that into HTTP->SQL->HTTP. If that's not some true top level simplification, I don't know what is!
What, huh? Aren’t stored procedures SQL in function form?
That’s how everyone used to build apps before Rails came along and made everone think putting biz logic into a slow server side language was a good idea.
IMHO and I might be entirely wrong but placing and coupling all that logic into the database seems like a bad idea and it's not a question of speed, it's a question of separating responsibilities. Also, for the case shown in the article, it seems all right for a "hello world" kind of thing. For something complex or prone to deep changes (like most of software projects I've been involved with), this seems like a true nightmare.
I’m sure you know this but the reason for taking computation off the database is that it’s much easier to horizontally scale a stateless middle tier than it is to scale a sql database.
Some DBAs I’ve worked with even advocated for taking sorting off the database. I wasn’t entirely convinced by that one.
My server side language in this case was Scala, so it wasn’t slow, just memory hungry.
Is it really easier to scale a Rails or Node app than Postgres (Scala might be an exception)? And how many pieces of software actually ever reach the kind of scale where database is the bottleneck? For many use cases, biz logic in the database will absolutely smoke doing it on server side due to query planner optimizations.
And there's a lack of an actual left in the media. No idea why people keep parroting that the media is leftist. It's not. Big media has a very blatant pro-corporate bias, and they're quite proud of that.
The semantics and bullshit around "social issues" like abortion or LGBT rights is just that - semantics and bullshit intentionally amplified to keep people focused on the wrong thing.
There are two nearly identical sides, as you rightly point out. Just like political parties, where there's the pro-corporate party that's OK with minorities, and the super-pro-corporate party with a little religion mixed in.
Most of dang's comments (that I've came across at least) are moderation actions, like telling people how they're not following the guidelines and so on. But yeah, also the actual backend moderation actions should obviously be included in the training set.
Excellent at producing a specific outcome (optimizing for certain variables) - whether that specific goal of an outcome is anywhere near optimal in a comprehensive sense is another matter entirely.
Excellent at allowing the same 10 guys (and their alts) to dominate almost every discussion. For truly serious topics, this place isn't all that different. Manipulation is a powerful weapon.
Metafilter also seems to work fine. Just charge money for each account creation, eventually the repeat trolls will get tired of paying over and over again.
The crucial difference is that these technologies are embedded differently. Java Applets had access to dangerous APIs that had to be restricted by the SecurityManager. Also, the JVM was installed externally to the browser, turning it into an uncontrollable component which made the browser vulnerable in turn.
The newer technologies were designed from the beginning with a well-defined security boundary and are based on a language that was designed from the beginning to be embedded. Everything is implemented within the browser and can be updated together with it.
That seems slanderous by the Union. They are suggesting that (likely a senior instructor) caused the collision and one of their members would have avoided it.
