Executando verificação de segurança...
22

Porque migramos nosso backend de Python pra Node.js

Fizemos uma mini-locura: migramos nosso backend do Skald de Python pra Node.js uma semana depois de lançarmos nosso produto.

Por um lado, é uma ótima hora pra migrar já que não temos muitos usuários.

Mas por outro lado essa é a hora em uma startup que você deve focar em fazer features pros clientes, vender o produto, e adicionar nova funcionalidades, não ficar fazendo refactor.

Então, por que migramos?

Basicamente porque async em Python é uma bagunça, e rapidamente íamos trombar em problemas de escala e também nosso código seria mais bagunçado e difícil de manter.

Por não ter nascido com async, o Python ficou um pouco pra trás nesse quesito, comparado com por exemplo JavaScript (que lançou com o modelo do event loop) e Go (que criou as goroutines).

Com isso, escrever código async em Python envolve muita cola, especialmente no Django que era o framework que estávamos usando.

Eu nunca cheguei a usar FastAPI, mas pelo meu entedimento o suporte pra async é muito bom. Porém os problemas do async do Python são meio estruturais, e o código async não é muito ergonômico, tendo o problema conhecido como colored functions.

Então mudamos pro Node. Fomos com uma stack standard usando Express e de cara vimos benefícios. Limos sobre e nos falaram também sobre AdonisJS, usar Hono com Bun, etc. mas achamos melhor começar com algo já bem estabelecido. Mas conta pra gente aí nos comentários sobre a experiência de vocês com outros frameworks no ecossistema JS/TS.

Se alguém quiser ler mais sobre a migração, escrevi um post em inglês sobre: Why we migrated from Python to Node.js

E se alguém quiser ver o código, é open source :)

skaldlabs/skald#56 feat: move the whole backend to node :D

Carregando publicação patrocinada...
5

Eu utilizo FastAPI ha mais de 3 anos e nunca tive problema com o suporte do Async. Geralmente o problema era o usuario que esquecia de dar um await onde precisava hahaha.

Mas se o JavaScript funciona pra voce e o time ta confortavel em desenvolver ta show.

Atualmente, de longe, o FastAPI eh o melhor framework (minha opiniao) de backend em Python.

Voce comentou que estao usando Express. Eu sugeriria o uso do NestJS, por conta do jeito que ele foi estruturado, pensando em Injecao de Dependencia e sem falar da integracao dele com Typescript e, tambem, com RabbitMQ/Kafka/Cron Jobs e talz. Eu acho uma framework bem completo.

Mas como voce mesmo falou, o foco inicial eh vender, entao bora vender xD

2
1
1

Poise cara, eu realmente acho que encaixaria pra gente. Mas como Django não dava e íamos ter que mudar os pilares todos, escolhemos o que encaixava como nosso outro serviço.

Nunca usei FastAPI mas sempre ouvi bem.

0
4
2
2

Qualquer pessoa sã migraria uma api de python para nodejs, py extremamente ineficiente em consumo de energia, e é o que importa no final, quando inventam de usar python para algo lembro por que inventaram nodejs

2

Interessante...

Muitas vezes gosto de ler os comentários sobre o tópico (ou artigo) para entender outros pontos de vista. Nesse caso, fiquei surpreso porque me deparei primeiro com essa publicação no Hacker News, na página inicial, então fica a recomendação para outras pessoas lerem os comentários lá também, que já são de 100.

De toda forma, obrigado por compartilhar, tanto em inglês quanto em português.

2

Poise, e o HackerNews é um lugar de muitas opiniões fortes rs. Mas se aprende muita coisa lá!

Da minha parte, acredito muito em começar a construir produtos na stack que for confortável para aqueles que estão construindo.

No meu caso e do Pedrique, era Django, que eu já usei em prod em sistemas com muita escala (notavelmente PostHog). Porém nunca tinha tido que mexer muito com async, então nessa parte me faltava experiência.

Grande parte da nossa experiência ruim vem do Django, e seria mitigada migrando pra FastAPI. Mas mesmo assim é um fato que o ecossistema async em Python é bem bagunçadinho, e isso não é uma questão de opinião sobre estilo, e sim relacionado ao design da linguagem.

Enfim, continuamos aprendendo. Às vezes eventualmente fazemos um upgrade pra um framework mais moderno em Node, mas pra gente estar no ecossistema Node faz muito sentido agora, sendo um bom meio termo entre perf out-of-the-box e usabilidade pros devs.

Mas já imagino que no futuro podemos acabar tendo um serviçozinho em Python tb :)

1

Muito interessante, cara!
Realmente, há uma bagunça com o Python e isso atrapalha um pouco.
Caso fosse um projeto pequeno, não faria diferença, mas como você apontou sobre escala futura, o quanto antes pode ser uma boa.

Eu tenho utilizado Nestjs e migrei alguns projetos de Ruby e Python também e fico maravilhado com a estrutura, organização e ergonomia.

1

Isso sem falar na maneira super eficiente de processar dados e filas do NodeJS, o que acredito que não é o caso do Python. Por si só o backend do node é postulado para lidar com muitos dados de maneira assíncrona e escalável.

1

Ultimamente iniciei um novo projeto com backend Nest/JS, muito interessante e bem organizado. Embora meus dois últimos projetos tenham tido backend em Elixir (que eu adoro) não senti muito impacto na mudança.

1

Concordo totalmente! Ter coragem pra mudar é essencial. Acho que fez certo se você viu que tinha uma oportunidade de mudança. Também estou nessa fase — venho usando NodeJS há um tempo e comecei a estudar Go, principalmente por questões de segurança, performance e economia, além de ser algo novo pra aprender. Você levou esses fatores em conta na sua decisão?

1

Cara que bacana ver essa prática aqui, não cheguei nesse ponto, mas escuto muito que concorrência/paralelismo com workload pesado é o limite do nodeJs.
Eu super recomendaria pra voces o nestjs, ate hoje oais preparado para projetos realmente complexos e escalaveis(eventos, micro serviços, etc) parece um spring do JAVA no que diz respeito a arquitetura, com typeorm fica muito bom. O express é bom mas a medida que voce vai escalando acaba tendo que implementar muita coisa e pra gerenciar tudo vc tem que ser mega organizado. Me da um tiro na testa mas HonoJs + Bun nem morto usso uma miseria desaa rs. FastAPI é o simples do s8mples, então so usaria se for uma coisa temporária e simples, e na maioria d9s casos pra isso eu prefiro Express. NextJs é bom pra front-end com controle refinado de SEO, fora isso evito usar, tem que saber lidar bem com ele pra não ficar dependendo da plataforma vercel.

0
0
1

Sim, mas também pq nosso produto anterior era um pouco diferente, e o Django fazia mais sentido. Ai mudamos de produto e carregamos um pouco do código, mas rapidamente trombamos em problemas