HN user
Maybe.
We observed that people migrated off as soon as the applications went into production or were serious, as the database<->api approach did not actually give them all the flexibility they wanted.
(This was 3 years ago, the players that stayed in that market or entered later, of course learned from that and adapted. So I hear they are making their users happy. As are we as an ORM.)
Or something along the lines of http://www.daemonology.net/hn-daily/
Prisma has pivoted to be “just” a Node.JS ORM a few years ago (I work there). You can still use it to build an API of course, but you will need some additional tool or libraries.
Wonderful insight into that world.
Very relevant to me right now.
But doesn’t the “ What About the Details?” section acknowledge that you will many of the other metrics later anyway for different people, projects and problems? Isn’t the message then “You should know which metrics are relevant to you and only look at them?”
What prevents the problem from coming back if you stop watching for that?
Thank you so much for doing the research and explaining this.
Then the "German" way of doing things is actually _the_ way of doing things, and the US just hase some additional stuff on top.
That also clarifies the twitter thread to me: This was about a _court_ ruling, not some copyright office deciding if something is copyrighted or not (which I assumed because I thought about the German way being special, and my misguided understanding of the US system being the international standard).
I also realize now that further down the twitter thread this is made more explicit. I should really have read more then the first 5 tweets. Sorry.
Important nuance, thanks for letting me know.. I was under the impression you only "got" the copyright by doing that. Do you "forfeit" anything by not doing it as soon/early as possible?
How does the copyright system in Luxembourg work?
In Germany for example (this will ignore a lot of nuance!), there is no applying or denying of copyright. If you created something, you own the copyright. It is even in the German name: "Urheberrecht" literally translates to "right of the creator". It can not be sold. And then there is the second concept of "Verwertungsrecht" or "Nutzungsrecht", which defines who has the right to "utilize" something (often for monetary gain). That fundamentally also starts with the person that created something, but can be sold (either before or after the work is done, for example via a contract).
As far as I know the US copyright system is very different from that, where you have to register or apply, and put (c) on things to show you own the right to moetize (this is even more vague, that is just the impression I got in the last 20 years of being on the internet).
In Germany the big discussion then is around "Schöpfungshöhe" - "threshold of originality" in English maybe - that decides if something is even in this system or not.
Is the discussion in the tweet about that really? If the work deserves to be in the system or not? If so, for "right of creator" or "right to utilize"?
Prisma often does multiple queries when getting some specific data, the first only leading to the second and so on. But we might very well get there one day. You are not the only one asking for this: https://github.com/prisma/prisma/issues/5052
It made sense at the time. We do not only support Node, but also have community Clients in Go, Python or Rust. Right now we are moving more and more parts from a Node-API library or binary engine (the two variants we support until now) over to Wasm modules where it is possible for our Node/TS/JS Client. Socket/TCP connections itself are unfortunately not supported yet, so this will only be partial. And maybe there is also a future where we support Node based databases drives. As this blog post we are commenting on shows, sometimes we have to combine the weirdest things together to achieve our goal.
That is only used in tests :) The query engine uses this: https://github.com/prisma/quaint/blob/6532d69b5aec007ad06ac6...
(I work at Prisma, could have mentioned that earlier)
Prisma does not actually use node-postgres, but a Rust PostgreSQL driver. Prisma will not be able to use the Neon serverless driver.
I am not sure I am following.
We can have either parallel queries in a transaction where the order does not matter, or we can have them serialized - but then the next query will only be sent onto its journey after the previous query returned its data to the app.
What are the attack vectors here? And where would the attacker sit and try to achieve what exactly?
Yes. You only have to open these connections once on the first execution of that function (cold start), any future request that hit this warm function will have 5 open connections and can instantly execute these queries in parallel. No overhead at all to open the connections.
What would be the alternative? Only execute the queries in sequence, one by one?
That I understand.
But of course for the user of the driver it might be fine if that is 2 or more HTTP requests. I expect that is how PlanetScale does it in their transaction implementation, https://github.com/planetscale/database-js#transactions, and I know that is how Prisma Data Proxy handles it - the transaction is identified with an ID which is returned to the Client and then included in further requests for the same transaction.
It's valid tradeoff to make to prefer a persistent connection to keep the overhead for multiple queries in a transaction as low as possible - which seems what Neon has done here.
Ok, so to make that explicit: If I want to do 5 parallel queries on my serverless function I should still have a connection pool size of 5 in my application, which will be fine as PgBouncer ensures there are plenty connections to open and use from the database server side. Correct?
The "How it works" section surprised me - I did not expect to see Websockets there.
Other serverless drivers or database APIs (PlanetScale Serverless Driver, AWS RDS Proxy or Prisma Data Proxy) usually use HTTP to replace the stateful TCP connection. The post explains a bit why this might be beneficial (can use existing tools, and use connection state) - but what about the other benefits and use cases of going with HTTP?
For example in that architecture the connection pool also moves from the application to the component in between and all that complexity can completely be removed from the app. Especially on serverless platforms, where in theory each request gets its own application with its own pool, that is huge. How does that work here? Or does the pool also move to the "WebSocket-to-TCP proxy" and you just did not highlight it in the post? (The graphic shows a "Connection Pool" but I can not really make sense of what that means.)
Came here to point out that the right question is if it works for the company that offers it, not how a minority of users experiences it.
You answered that. Thanks.
Did I understand correctly that with the "Time" or "LSN" options for branch creation I do not have to create my branches ahead of time (via UI or API), but I can do that _after_ I messed up already?
Ground elevation was by default turned off for me, but via the burger menu and then "Graphic options" I could turn it on.
And Prisma supports it equally well as PostgreSQL.
“I wonder what happens when I call this URL in the backend. Or this one.” Unnamed person from new owner company
The Prisma Query Engine is indeed written in Rust :D
2020 you mean.
You just sent me into an small crisis wondering when that 2023 thing happened :D
More a second try I would say. Lovely that I found this article via that.
(2015)
Yes it absolutely is if you write the tweets while you actually do the thing.
Writing a blog post would require you to do the same, but not share while you are going through the experience (so no helpful replies from your followers etc), then having to edit (as blog def requires something a bit more polished) and post it on the blog that you need to run or have run for you some way. And then you would need to somehow get people to actually read that still.
So I totally believe them (besides believing them they are telling me their valid view in the first place).
The linked article spells out exactly what project it was about:
Take AWS. It reached $10 billion in revenue in less than four years. But what's remarkable is that they didn't get there by forming a team, writing a lot of code, and then testing and iterating. In fact, it took more than 18 months before the engineers actually started to write code. Instead, they spent that time thinking deeply about the customers they were trying to serve and forming a clear vision for what AWS should be
Oh, I did not connect these dots.
Shucks.