Effect 4.0 ficou muito mais difícil de ignorar

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Effect 4.0 Just Got a Lot Harder to Ignore · Canal: Better Stack · 07:49 · Assistir no YouTube

Tópicos: Engenharia de software com IA, Ferramentas de desenvolvimento com IA

Resumo

Effect é uma biblioteca de TypeScript que reúne erros tipados, retries, timeouts, injeção de dependências e concorrência em um mesmo modelo. A versão 4.0 traz um runtime reescrito, um bundle menor e mudanças incompatíveis, além de unificar vários pacotes. O vídeo destaca que os números de desempenho ainda precisam de confirmação independente e que alguns módulos continuam instáveis. Effect pode valer a pena em projetos de backend com tratamento complexo de erros, mas adotá-lo profundamente muda a forma de estruturar a aplicação.

Pontos-chave

Effect representa sucesso, erros possíveis e requisitos de execução nos tipos de uma operação.
Ao tratar um erro, ele pode desaparecer do tipo; ao adicionar um timeout, o tipo passa a incluir a possibilidade de TimeoutError.
Effect 4.0 reescreveu o runtime e, segundo a equipe, reduziu o bundle mínimo e aumentou a capacidade de processamento de tarefas.
Os benchmarks divulgados são da própria equipe e ainda não foram reproduzidos de forma independente; os números de tamanho do bundle também variam entre documentos.
Vários pacotes foram incorporados ao pacote principal, que agora tem uma versão compartilhada e zero dependências de runtime no core.
AI, CLI, cluster, HTTP, RPC e SQL continuam marcados como instáveis, mesmo com a versão 4 considerada estável.
A migração exige atenção especial ao Schema e aos módulos instáveis; não há um code mod oficial.
Adotar Effect profundamente pode exigir estruturar a aplicação em torno do modelo da biblioteca, tornando uma adoção parcial potencialmente problemática.

Capítulos

Início	Capítulo	Resumo
00:00	O que Effect muda no TypeScript	O vídeo apresenta o problema de erros ocultos em funções assíncronas e explica como Effect os inclui nos tipos.
02:04	Demonstração e novidades da versão 4.0	Uma demonstração mostra erros tratados e timeouts, seguida pelas mudanças no runtime, no empacotamento e na API.
04:44	Alternativas e ressalvas sobre os dados	O vídeo compara Effect com bibliotecas separadas, menciona a fusão com fp-ts e pondera os benchmarks e números de downloads.
06:47	Migração e quando adotar Effect	O apresentador discute o custo de organizar a aplicação em torno de Effect e recomenda cautela ao migrar ou adotá-lo parcialmente.

Citações

Sucesso, erro, requisitos. — 01:02

Adicionei um timeout. Então o compilador adicionou a possibilidade de falha por timeout. — 02:37

Quase todos os números impressionantes deste lançamento vêm com um asterisco. — 05:15

Como essa função pode falhar? — 07:49

Conceitos e entidades

Effect (ferramenta): Biblioteca de TypeScript que integra erros tipados, retries, timeouts, concorrência e outros recursos em um mesmo modelo.
TypeScript (conceito): Linguagem cuja relação com Effect é demonstrada por meio de tipos que descrevem os resultados e as falhas possíveis das operações.
Effect 4.0 (ferramenta): Nova versão do Effect, com runtime reescrito, mudanças incompatíveis e pacotes unificados.
Zod (ferramenta): Biblioteca citada como alternativa para validação de schemas, que poderia ser combinada com outras bibliotecas.
fp-ts (ferramenta): Biblioteca que, segundo o vídeo, se fundiu oficialmente ao Effect.
npm (ferramenta): Registro de pacotes usado no vídeo para instalar o Effect e consultar números de downloads.
Bun (ferramenta): Runtime usado na demonstração e também mencionado como opção para instalar o Effect.
Better Stack (empresa): Canal responsável pelo vídeo sobre as mudanças e a adoção do Effect 4.0.
Josh (pessoa): Apresentador do vídeo, que se identifica como Josh, da Better Stack.

Tradução completa (pt-BR)

00:00 Effect recebe cerca de 50 milhões de downloads por semana no npm. E, de alguma forma, ainda é uma daquelas bibliotecas de TypeScript estranhamente difíceis de explicar. Effect não é só tratamento de erros. Também não é só novas tentativas, schemas, concorrência ou injeção de dependências. A ideia é reunir tudo isso em um único sistema. E agora a versão 4.0 foi lançada, com um runtime reescrito, um pacote muito menor e várias mudanças incompatíveis. Então quero fazer duas coisas. Primeiro, mostrar o que Effect realmente muda quando você escreve TypeScript. Depois, vamos ver o que há de novo na

00:30 versão 4.0 e se vale a pena usar alguma dessas novidades. Certo, o problema que Effect está tentando resolver é o seguinte. No TypeScript comum, esta função retorna uma promise de usuário e, de acordo com o sistema de tipos, é basicamente só isso. Mas há muito mais acontecendo na função de verdade. A rede pode falhar. Talvez o usuário nem exista. Essa requisição pode ficar pendurada, e o TypeScript não sabe nada disso. Pelos tipos, você recebe um usuário. Em produção,

01:02 bem, boa sorte. Effect muda o contrato. Em vez de uma promise de usuário, você recebe um effect que contém três coisas. Temos informações como o que é retornado, o que pode dar errado e do que o código precisa para ser executado. Sucesso, erro e requisitos. Então, em vez de as falhas ficarem escondidas em algum lugar da implementação, elas passam a fazer parte do tipo da função. Se você gosta de ferramentas de programação que aceleram seu workflow, não deixe de se inscrever. Temos vídeos novos o tempo todo. O ponto importante aqui é que o tipo de erro muda

01:34 conforme o código muda. Se você trata o caso de não encontrado, ele desaparece do canal de erros. Se adiciona um timeout, aparece um erro de timeout. Assim, o tipo sempre descreve o que realmente pode acontecer naquele ponto do pipeline. Este é o Effect 4.0 direto do npm, com TypeScript 7 rodando no bun no meu Mac. Tenho esta função get user. Ela busca um usuário e tem dois erros personalizados: not found e HTTP error. Se eu passar o cursor sobre ela, o que aparece? Temos Effect de

02:04 usuário. HTTP error ou not found, e never para os requisitos. Então, antes mesmo de executar isso, o compilador sabe exatamente como essa operação pode falhar. Agora, veja o que acontece quando começo a adicionar comportamento. Vou colocar isso aqui. Encadeio com uma nova tentativa exponencial, três vezes. Depois, um timeout de dois segundos. Em seguida, capturo not found e retorno um valor alternativo. Passe o cursor sobre ela e veja o tipo de erro. Not found desaparece

02:37 porque tratei esse caso. Mas agora há uma nova falha: erro de timeout. Adicionei um timeout. Então, o compilador acrescentou a possibilidade de o timeout falhar. E isso não é apenas algum truque inteligente com tipos. Vou reduzir o timeout para 50 milissegundos. E vamos executar. E lá está: erro de timeout. Exatamente a falha que o tipo nos disse que poderia acontecer. E, quando você entende isso, Effect começa a fazer um pouco mais de sentido. Então, o que a versão 4 realmente mudou aqui? Bem, bastante coisa. A equipe diz que Effect foi reconstruído

03:09 do zero. O que isso significa? Inclui o runtime de fibers que fica por baixo, basicamente a parte responsável por agendar todo o trabalho. E é aqui que começam a aparecer alguns números maiores. Segundo eles, o pacote mínimo passou de 35,5 quilobytes na versão 3 para 7 quilobytes na versão 4. É cerca de cinco vezes menor. A taxa de processamento de tarefas é aproximadamente 6,5 vezes maior. E o uso de memória para 50.000 fibers supostamente caiu de cerca de 157 megabytes para aproximadamente 22. Esses números parecem

03:41 ótimos. Mas não os perca de vista, porque preciso voltar a esse assunto daqui a pouco. A segunda grande mudança é o empacotamento. Antes, Effect era distribuído em vários pacotes. Platform, RPC, cluster e outros agora estão dentro do pacote principal de Effect, todos com o mesmo número de versão. E o core não tem dependências de runtime. Então, em vez de gerenciar vários desses pacotes de Effect e descobrir quais versões funcionam em conjunto, agora você só precisa instalar um pacote. Depois, há as mudanças que você realmente vai notar no seu

04:12 código. Context tag agora é context service. Catch all agora é apenas catch. Either virou result, e runtime desapareceu. Há também algo fundamental aqui se você está tentando convencer alguém a realmente usar isso: o suporte de longo prazo. Effect 4.0 receberá correções de bugs até setembro de 2029. E, se você só quiser experimentar, a instalação é bem simples. Bun add effect ou, sim, npm install effects. Agora, a esta altura, alguns de vocês talvez digam que

04:44 dá para usar ZOD para isso. Adicione uma biblioteca de novas tentativas, adicione um timeout e pronto. E sim, dá, mas essas ferramentas não sabem umas das outras. Effect está tentando fazer com que erros tipados, novas tentativas, timeouts, injeção de dependências, rastreamento de concorrência e tudo isso façam parte do mesmo modelo. E, à medida que você combina essas peças, os tipos continuam acompanhando você. Effect ficou tão grande que até absorveu um antigo rival. FPTS se fundiu oficialmente com Effect. O próprio README diz que

05:15 Effect é basicamente aquilo em que FPTS versão 3 teria se transformado. Tudo isso é bem legal, mas é neste ponto que eu começaria a ter cautela, porque quase todo número impressionante deste lançamento vem acompanhado de um asterisco. Comecemos por esses benchmarks. São números da própria Effect. Não foram reproduzidos de forma independente, e nem mesmo a documentação da Effect está totalmente de acordo. O blog de lançamento diz que o pacote mínimo tem 7,1 quilobytes. O guia de migração diz cerca de 6,3. É uma diferença

05:46 pequena, mas é um bom lembrete de que isso precisa ser testado por mais tempo. Depois, há os 50 milhões de downloads semanais. Esse número vem diretamente do npm. Na semana passada, cerca de 29 milhões de downloads eram da versão 4. Isso parece bastante, não é? São milhões e milhões, só que quase todos eram versões beta e release candidates. A versão 4.0 estável teve cerca de 150.000 downloads no primeiro dia. Ainda é bastante. E aqui está a maior ressalva. A versão 4 é estável, mas isso não significa que tudo dentro da versão 4 seja estável.

06:17 AI, CLI, cluster, HTTP, RPC e SQL ainda estão marcados como instáveis, e mudanças incompatíveis ainda podem ser lançadas em uma versão menor. O guia de migração deixa isso muito, muito claro. Mover esses módulos para o pacote principal não os tornou estáveis. Schema provavelmente é a parte à qual eu prestaria mais atenção. Ela foi bastante reformulada durante a versão beta e tem seu próprio guia de migração. E isso nos leva à atualização propriamente dita. Não há um codemod oficial. O conselho no blog de lançamento é basicamente passar o guia de

06:47 migração para o seu agent de programação e, sinceramente, isso provavelmente vai funcionar muito bem. E então chegamos à crítica que acompanha Effect há anos: Effect não apenas ajuda no seu aplicativo; ele toma conta do seu aplicativo. Effect não é exatamente um pequeno utilitário que você simplesmente adiciona a uma base de código existente. Quando você o adota profundamente, começa a escrever a aplicação em torno do modelo dele. É mais parecido com trocar de linguagem, só que a nova linguagem ainda compila para o mesmo JavaScript. Para algumas pessoas, esse é o motivo para não mexer nisso. Se você está escrevendo código de backend em

07:18 TypeScript ou trabalhando com código antigo, e sua base de código já está cheia de novas tentativas, timeouts e erros que o sistema de tipos não consegue detectar, acho que vale a pena experimentar a versão 4.0. Se você já usa Effect 3, atualize, mas trate Schema e os módulos instáveis como projetos de migração separados. E, se estiver criando um aplicativo pequeno que ainda não adotou completamente o modelo de Effect, sinceramente, deixe para lá, porque Effect é uma daquelas ferramentas em que adotar só pela metade pode ser pior do que nunca adotar. Não se trata apenas de um pacote cinco vezes menor. Não se trata do

07:49 runtime mais rápido, nem dos 50 milhões de downloads no npm. O TypeScript finalmente consegue descrever algo que, em grande parte, vinha ignorando. Não apenas o que esta função retorna, mas algo como: de que maneiras esta função pode falhar? Eu sou Josh, da Better Stack. Se você gosta de dicas e truques de programação como este, não deixe de se inscrever. A gente se vê em outro vídeo.

Transcrição original

[00:00] Effect gets around 50 million downloads a week on npm. And somehow it’s still one of those Typescript libraries that’s weirdly hard to explain. Effect isn’t just error handling. It isn’t just retries, schemas, concurrency, or dependency injection either. It tries to pull all that into one system. And now version 4.0 is out with a rewritten runtime, a much smaller bundle, and a bunch of breaking changes. So I want to do two things. First, show you what effect actually changes when you write TypeScript. Then we’ll look at what’s

[00:30] new in 4.0 and whether any of it is worth using. Okay, so the problem E effect is trying to solve is this. In normal TypeScript, this function returns a promise of a user and according to the type system, that’s basically it. But the real function has a lot more going on. The network could fail. The user might not even exist. That request can hang and TypeScript knows none of that. As far as your types are concerned, you get a user. As far as production is concerned,

[01:02] well, good luck. Effect changes the contract. Instead of a promise of user, you get an effect containing three things. We get things like what comes back, what can go wrong, and what the code needs in order to run. Success, error, requirements. So now instead of failures being hidden somewhere inside the implementation, they become part of the functions type. If you enjoy coding tools that speed up your workflow, be sure to subscribe. We have videos coming out all the time. The important thing to note here is that the error type changes

[01:34] as the code changes. If you handle not found, it disappears from the error channel. If you add a timeout, timeout error shows up. So the type is always describing what can actually happen at that point in the pipeline. This is effect 4.0 straight from npm with TypeScript 7 running on bun on my Mac. I have this get user function. It fetches a user and it has two custom errors not found and HTTP error. If I hover over it, what do we get? We get effect of

[02:04] user. HTTP error or not found and never for the requirements. So before I even run this, the compiler knows exactly how this operation could fail. Now watch what happens when I start adding behavior. I’m going to drop this in here. I pipe it through an exponential retry three times. Then a two-cond timeout. Then I catch not found and return a fallback instead. Hover over it and look at the error type. Not found disappears

[02:37] because I handled it. But now there’s a new failure. Timeout error. I added a timeout. So the compiler added the possibility that the timeout can fail. And that isn’t just some clever type trick. Let me drop the timeout to 50 milliseconds. And we’re going to run it. And there it is. Timeout error. Exactly the failure the type told us could happen. And once you understand that, effect starts to make a little bit more sense. So what did version 4 actually change here? Well, quite a lot of things. The team says effect was rebuilt

[03:09] from the ground up. So what does that mean? That includes the fiber runtime underneath it. Basically the part responsible for scheduling all the work. And this is where some bigger numbers start appearing. They say the minimum bundle went from 35 1/2 kilobytes in version 3 to 7 kilobytes in version 4. That’s roughly 5 times smaller. Task throughput is about 6.5 times higher. And memory usage for 50,000 fibers supposedly dropped from roughly 157 megabytes to about 22. Those numbers do

[03:41] sound great. Just hold on to them though cuz I need to touch on that again in a second. The second big change here is packaging. Effect used to be spread across multiple packages. Platform, RPC, cluster, and others now live inside the main effect package on one shared version number. And the core has zero runtime dependencies. So instead of managing a bunch of these effect packages and figuring out which versions work together, you now just have to install one package. Then there are the changes you’ll actually see in your

[04:12] code. Context tag is now context service. Catch all is now just catch. Either became result and runtime is gone. There’s also something that’s key here if you’re trying to convince someone to actually use this, which is long-term support. Effect 4.0 gets bug fixes until September of 2029. And if you just want to try it, implementation is pretty darn straightforward. Bun add effect or yes, npm install effects. Now, at this point, some of you might say you

[04:44] can just use ZOD for this. Add a retry library, add a timeout, and call it a day. And yeah, you can, but those tools don’t know about each other. Effect is trying to make typed errors, retries, timeouts, dependency injection, concurrency tracing, all this stuff a part of the same model. And as you compose those pieces together, the types keep following you. And effect has become big enough that it has even absorbed an old rival. FPTS officially merged into effect. Its own readme says

[05:15] effect is basically what FPTS version 3 would have become. So all this is pretty cool except this is the point where I’d start being careful because almost every impressive number in this launch comes with an asterisk. Start with those benchmarks. They’re effects own numbers. they haven’t been independently reproduced and even effects own documentation doesn’t even completely agree. The launch blog says the minimal bundle is 7.1 kilobytes. The migration guide says about 6.3. That is a small

[05:46] difference, but it’s a good reminder that this needs tested with more time. Then there’s those 50 million weekly downloads. That comes straight from npm. Last week around 29 million downloads were version 4. This does sound pretty big, right? That’s millions and millions except almost all of those were betas and release candidates. Stable 4.0 about 150,000 downloads on day one. That’s still quite a lot though. And then here’s the biggest catch. Version 4 is stable, but that does not mean everything inside version 4 is stable.

[06:17] AI, CLI, cluster, HTTP, RPC, SQL are all still marked unstable and breaking changes can still launch in a minor release. The migration guide is very, very clear about this. Moving these modules into the main package did not stabilize them. Schema is probably the part I’d pay most attention to. It was heavily reworked during the beta and it has its own migration guide. Which brings us to actually upgrading. There’s no official code mod. The advice in the launch blog is basically give the

[06:47] migration guide to your coding agent and honestly that will probably work just fine. And then we get to the complaint that has followed effect for years. that effect doesn’t just help with your app, it takes over your app. Effect isn’t really a little utility you just drop into an existing codebase. Once you adopt it deeply, you start writing your application around its model. It’s closer to switching languages, except the new language still happens to compile to the same JavaScript. For some, that’s the reason not to actually touch it. If you’re writing backend

[07:18] TypeScript or aging code and your codebase is already full of retries, timeouts, and errors the type system can’t see, I think 4.0 is worth trying. If you’re already using effect 3, upgrade, but treat schema and the unstable modules like their own migration project. And if you’re building a small app that isn’t fully brought in the effect model yet, honestly, just skip it because effect is one of those tools where half adopting, it can actually be worse than never adopting it at all. It isn’t just the five times smaller bundle. It isn’t the

[07:49] faster runtime and it isn’t 50 million npm downloads. Typescript can finally describe something it has mostly ignored. Not just what does this function return, but rather something along the lines of how can this function fail. I’m Josh from Better Stack. If you enjoy coding tips and tricks like this, be sure to subscribe. We’ll see you in another video.