Top
Best
New

Posted by yakkomajuri 22 hours ago

Why we migrated from Python to Node.js(blog.yakkomajuri.com)
200 points | 222 commentspage 2
amai 5 hours ago|
Should be "Why we migrated from Django to Node.js".

Answer: Because Django doesn't support async by default.

travisgriggs 21 hours ago||
I do a lot of glueware and semi-embedded stuff with Python... but my goto these days for anything networky is Elixir (LiveView if ux). If I need an event loop, async that is more than a patched on keyword, it just rocks. It is amazing to me how much Elixir does not have, and yet how capably it solves so many problems that other languages have had to add support for to solve.
xenator 21 hours ago||
So basically you just rewrote boilerplate code with complexity of "hello world" and deploy scripts. Without any dependencies, data migrations, real user data and downtime SLA. And after that you had time to write quite long article.

What honest reaction you expect from readers?

oompydoompy74 20 hours ago|
I have no idea how you reached this conclusion from the article that I read.
xenator 4 hours ago||
Just simple arithmetics.
euph0ria 21 hours ago||
"we almost quit multiple times"

It was a three day small task?

ehutch79 21 hours ago|
This didn't make sense to me either? If it only took three days for a complete rewrite to another language, what's the problem? Did I read they were getting interrupted for user requests? felt weird.
pier25 21 hours ago||
I would have picked Hono and Drizzle. In part because of the great TS support but also Hono is much faster than Express and supports Zod for validation out of the box. This stack would also allow to use any other runtime (Deno, Bun, or Cloudflare Workers).

Given they used TS and performance was a concern I would also question the decision to use Node. Deno or Bun have great TS support and better performance.

jherdman 21 hours ago||
Have you tried Elysia (https://elysiajs.com/)? Admittedly I'm not using it at scale, but it's quite pleasant.
internetter 21 hours ago|||
I've written 10s of thousands of lines of Elysia+Kysely and its a match made in heaven
jherdman 15 hours ago||
I’m curious about your choice of Kysely. I’ve really only used Drizzle. It’s fine but it has some very rough edges around Bun and SQLite.
pier25 18 hours ago|||
I checked it out and it looks good on paper but it only runs on Bun.

Don't get me wrong, I use Bun and I'm happy with it, but it's still young. With Hono/Drizzle/Zod I can always switch back to Node or Deno if necessary.

bytehowl 13 hours ago||
ElysiaJS's blog claims that support for other runtimes was added in 1.2: https://elysiajs.com/blog/elysia-12.html#adapter
rozenmd 21 hours ago|||
I recently moved a classic HTTP API server from Express to Hono (through the Hono node-server package), absolutely seamless migration.
verdverm 21 hours ago||
I wouldn't call it seamless, having also done this recently. (Handler func signature is different) But it is relatively straight forward without major changes to the code needed
jgehrcke 21 hours ago|||
I'm sure you know what you're taking about -- yet, your response reminds me of https://youtu.be/aWfYxg-Ypm4

"drizzle works on the edge"

tracker1 21 hours ago|||
Made pretty much the same comment Hono + Zod + Swagger is pretty nice all around. Not to mention the portability for different runtime environments. I also enjoy Deno a lot, it's become my main shell scripting tool.
adzm 21 hours ago|||
I think it makes sense to start with node.js... it's the standard and widely supported. Eventually it should not be too difficult to switch to bun or deno if the need arises.
breakfastduck 21 hours ago||
I've had a really pleasant experience with Drizzle as an ORM. It feels straightforward compared to some of the incredibly bloated alternatives.
tracker1 21 hours ago|||
I'm more a fan of just a sql template string handler... in C#/.Net I rely on Dapper... for node, I like being able to do things like...

    const results = await query`
      SELECT...
      FROM...
      WHERE x = ${varname}
    `;
Note: This is not sql injection, the query is a string template handler that creates a parameterized query and returns the results asynchronously. There's adapters for most DBs, or it's easy enough to write one in a couple dozen lines of code or less.
pier25 20 hours ago|||
With something like EF Core in .NET or Drizzle in TS you get a lot of help from your editor that you wouldn't get when writing SQL.
pjmlp 5 hours ago|||
Only if using the wrong kind of editor.
tracker1 20 hours ago|||
In TS, I can still create a type for my result... const results : Promise<Foo[]> = ...

I'm not sure what additional help you're getting. I'm just not a fan of ORMs as they tend to have hard edges in practice.

pier25 20 hours ago||
ORMs not only help with the result of the query but but also when writing queries. When I wrote SQL I was constantly checking table names, columns, and enums. With a good ORM like EF Core not only you get autocomplete, type checking, etc but dealing with relationships is much less tedious than with SQL. You can read or insert deeply nested entities very easily.

Obviously ORMs and query builders won't solve 100% of your queries but they will solve probably +90% with much better DX.

For years I used to be in the SQL-only camp but my productivity has increased substantially since I tried EF for C# and Drizzle for TS.

tracker1 19 hours ago||
VS Code plugs into my DB just fine for writing SQL queries...

With an ORM, you can also over-query deeply nested related entities very easy... worse, you can then shove a 100mb+ json payload to the web client to use a fraction of.

mrsmrtss 18 hours ago||
That's just nonsense. It's trivial to make efficient projected queries with ORMs like EF. Nothing stops you doing stupid things with plain SQL either.
tracker1 17 hours ago||
No, but it does put you closer to the actual database and makes you think about what you're actually writing. You also aren't adding unnecessary latency and overhead to every query.
pier25 17 hours ago||
Better DX is not unnecessary.

Also the overhead of good ORMs is pretty minimal and won't make a difference in the vast majority of cases. If you find a bottleneck you can always use SQL.

breakfastduck 15 hours ago|||
Sure, looks good. I often do templating.

However drizzle makes it very very straightfoward to handle DB migration / versioning, so I like it a lot for that.

tracker1 12 hours ago||
I mostly use grate.
carderne 19 hours ago|||
Bit of a plug but I just started working on a drizzle-esque ORM[1] for Python a few days ago and it seems somewhat appropriate for this thread. Curious whether anyone thinks this is a worthwhile effort and/or a good starting point syntax-wise.

https://github.com/carderne/embar

resiros 21 hours ago||
TL;DR

>I'll preface this by saying that neither of us has a lot of experience writing Python async code

> I'm actually really interested in spending proper time in becoming more knowledgeable with Python async, but in our context you a) lose precious time that you need to use to ship as an early-stage startup and b) can shoot yourself in the foot very easily in the process.

The best advice for a start-up is to use the tools that you know best. And sometimes that's not the best tool for the job. Let's say you need to build a CLI. It's very likely that Go is the best tool for the job, but if you're a great Python programmer, then just do it in Python.

Here's a clearer case where the author was not very good with Python. Clearly, since they actually used Django instead of FastAPI, which should have been the right tool for the job. And then wrote a blog post about Python being bad, but actually it's about Django. So yeah, they should have started with Node from day one.

com2kid 19 hours ago||
Actually after having written a complex CLI in Node, I think I would've been better off learning Go and writing in that.

Sometimes tools are worth learning!

morshu9001 15 hours ago||
I'd also rather write a CLI in Python than in Node
com2kid 13 hours ago||
The only issue with writing a CLI in Node is ecosystem. The CLI libraries for Node are (or were last time I checked) inspired by React. Not a paradigm that is fun to write in, and if I'm making a CLI tool it is because I am bored and want to make something for my own entertainment.
pjmlp 5 hours ago|||
Here is an unwanted advice from a old dog, you don't need any libray to write CLIs.

A function to display help, and another old to parse the CLI parameters isn't PhD level coding.

Also nowadays, any LLM friend can quickly generate them.

morshu9001 7 hours ago|||
There are also CLIs actually written in React using Ink
com2kid 7 hours ago||
I'm aware....

That is exactly what I am complaining about.

I guess some people like it, but just, ick.

kelvinjps10 20 hours ago||
They were good but no experience with python async
cryptomic22 20 hours ago||
This is a lot more about Django than it is about Python.
luxuryballs 19 hours ago||
I don’t know a ton about either but now I am curious if I should takeaway the idea that async with Python is problematic or if only async with Django is the issue.
morshu9001 15 hours ago||
Async with Python is problematic, but this article doesn't really explain that. Django async being bad is just one of many symptoms.
fatih-erikli-cg 15 hours ago||
[dead]
aprilfoo 14 hours ago||
Posts inviting language/frameworks flame wars are clickbaits... and i fell for it, again.
oceansky 13 hours ago|
I, for one, love reading those.
pspeter3 20 hours ago||
I'm curious about who else is using MikroORM. I see a lot of hype around Prisma, Drizzle, and Kysely but MikroORM has always looked interesting.
sthuck 19 hours ago|
I'm using it for a hobby project, and pretty pleased.

My personal maybe somewhat "stubborn old man" opinion is that no node.js orm is truly production quality, but if I were to consider one I think I would start with it. Be aware it has only one (very talented) maintainer as far as I recall.

stephen 19 hours ago||
Everyone's definition of "production quality" is different :-), but Joist is a "mikro-ish" (more so ActiveRecord-ish) ORM that has a few killer features:

https://joist-orm.io/

Always happy to hear feedback/issues if anyone here would like to try it out. Thanks!

me2too 21 hours ago|
Is this 2015?
morshu9001 19 hours ago|
Plenty of people are still using Python, Java, or even C++ for this sort of thing, even in new codebases, for no reason other than familiarity
More comments...