Our great sponsors
-
drizzle-orm
Headless TypeScript ORM with a head. Runs on Node, Bun and Deno. Lives on the Edge and yes, it's a JavaScript ORM too 😅
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
Prisma
Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB
-
js-ts-csharp
A repository demonstrating functional techniques with C# 10 and the similarities between JavaScript, TypeScript, and C#.
-
playwright-scrape-api
A dead simple REST API to use Playwright to scrape the text contents from any URL.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
MikroORM
TypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns. Supports MongoDB, MySQL, MariaDB, MS SQL Server, PostgreSQL and SQLite/libSQL databases.
I would modify this to
- Don't use Prisma if you're using serverless
There've been lots of these blog posts and what all of them have in comon is using serverless/lambda. With actual servers and prisma running close to the underlying database, its pretty great.
Regarding using joints, that's not necessarily the best choice either. When using simple flat joins naively, you get a lot of repetition for the more toplevel nodes of the join tree, which eventually adds up to a lot of network traffic and allocation.
What you really want are joins that build the JSON on the server. In MSSQL this can be as simple as `FOR JSON`. In Postgres it can get... a bit more involved - Drizzle can do it: https://github.com/drizzle-team/drizzle-orm/releases#:~:text...
This is probably okay, although I do wonder what happens after you hit the compute limits of your database server (i.e. scenarios when you don't use things like planetscale). In those cases (again, non-serverless). Prisma's choice might again work better (especially if Prisma runs close to the db server) - which will still likely be slower than the fancy JSON join, but probably need fewer database resources.
Sounds like it's basically explained in the gh-ost readme https://github.com/github/gh-ost#how
I think it amounts to "use views to decouple access to the table with a fixed interface" and "use triggers for migrating data between tables"
Here's a comment from their team about this:
https://github.com/prisma/prisma/discussions/4617#discussion...
Tl;dr it's a design decision, not everyone (including me) agrees.
One thing that keeps coming up is that SQL equals low productivity. I don't think this is true. I think the culprit is that most developers are using to heavily abstracting SQL using ORMs like Prisma that hides the database and SQL logic.
Since building a SQL generator (https://aihelperbot.com) as a side project, I have become much more proficient in SQL and even though I am also locked into Prisma, I use the `queryRaw` all the time to execute raw SQL queries. You can understand the code without knowing Prisma API. It is more performant. For more complex SQL queries, I use the SQL generator for initial suggestions and adapt if needed.
For the next projects I build I want to use the minimal Postgres client (https://github.com/brianc/node-postgres) combined with a lightweight migration library.
The thing is, if you're comfortable with TypeScript, it's really more or less just a small step to C#.
A small repo here: https://github.com/CharlieDigital/js-ts-csharp
And a practical example of a Playwright web scraper in C# and TypeScript: https://github.com/CharlieDigital/playwright-scrape-api
"Too many keywords" is the weirdest objection to a programming language versus actually using the language to build something practical.
The thing is, if you're comfortable with TypeScript, it's really more or less just a small step to C#.
A small repo here: https://github.com/CharlieDigital/js-ts-csharp
And a practical example of a Playwright web scraper in C# and TypeScript: https://github.com/CharlieDigital/playwright-scrape-api
"Too many keywords" is the weirdest objection to a programming language versus actually using the language to build something practical.
This is a very strange comment section. And this article is insanely poorly written.
> Last week, we completed a migration that switched our underlying database from MongoDB to Postgres.
Okay cool, but why? MongoDB is a very capable and fast database.
> It was a shock finding out that Prisma needs almost a “db” engine layer of its own. Read more about it here: https://www.prisma.io/docs/concepts/components/prisma-engine...
If you did any research on Prisma rather than diving in head-first, you'd realize this is a core part of why Prisma exists.
> we discovered that at a low level, Prisma was fetching data from both tables and then combining the result in its “Rust” engine. This was a path for an absolute trash performance.
Can you confirm this is actually the case? Can you show some benchmarks re: this claim? Or are you just assuming this is the case?
I found MikroORM [0] to be quite reasonable if you're in the TS ecosystem already. It was also easy to do custom, raw queries, and really just felt like it wasn't in the way.
[0] https://mikro-orm.io/