Introdução

Estou criando um aplicativo relacionado ao tema de produtividade e organização, que tem no momento um foco em estudantes que desejam ter uma forma rápida e fácil de se organizar. O App irá permitir a personalização do aplicativo para a melhor forma que o usuário encontrar para se ter uma produtividade desejada.

Uma das features que imaginei para o App, seria as multiplas pessoas acessarem o aplicativo e se organizarem em conjunto, igual como funciona no Figma ou Miro. E claro, isso exigiria uma capacidade muito grande de um servidor, tendo alto desempenho e segurança para a aplicação.

Minhas Primeiras Ideias Para o Backend

Como a maioria dos desenvolvedores Mobile, eu pensei inicialmente no Firebase, que é muito mais do que o suficiente pra criar um MVP de algum aplicativo, e remove a necessidade de criar uma API própria.

Além do mais que, eu sou especializado em Mobile, então eu precisaria usar para o Backend alguma tecnologia que fosse performática, prática, DIVERTIDA de usar e se aprofundar sobre. Porque eu desejo focar na criação de uma ótima usabilidade e experiência do usuário para o Aplicativo, que é o que de fato hoje faz uma pessoa passar mais tempo usando seu aplicativo ou não.

O que eu mais gosto no Firebase, é a facilidade da autenticação e o banco de dados NoSQL dele, o Firestore, que tem um limite muito bom para contas gratuítas. Porém, ele se torna caro a partir do momento que o App escala, e de uma forma ou de outra, em algum momento eu teria que acabar criando uma API Rest própria se eu quisesse escalar o App e fazer ele um produto que quero que seja.

O Processo de Escolha da Linguagem de Programação (Trade-off)

Após perceber que de uma forma ou de outra eu teria que migrar do Firebase, decidi então procurar por linguagens de programação que pudessem resolver meu problema, que eu me interessava por aprender mais sobre e, que principalmente me fizesse sair da minha bolha.

As tecnologias que já havia estudado por mais tempo foram Python, Dart e Java. Havia chegado a estudar sobre Javascript, mas havia me enrolado todo e acabei pulando direto pra estudar Next com Typescript (Não deu certo).

Baseado em alguns vídeos e artigos da Internet e influências de algumas pessoas e empresas, acabei elencando essas 4 tecnologias:

• Node.js
• Elixir
• Clojure
• Rust

Apesar de Node.js ser uma tecnologia muito incrível, que já evoluiu muito e tem evoluído muito, ela não seria exatamente sair da minha bolha, pois é muito parecida com outras tecnologias que já havia usado e não teria o gostinho de estar aprendendo algo novo e sim algo que eu estaria me aprofundando, pois já conhecia o ecossistema JS.

Acabou que as 3 tecnologias mais fora da bolha para eu seriam o Clojure, Rust e Elixir. Sendo o Rust a que com certeza eu teria mais dificuldade, então, possívelmente a mais divertida!

As motivações de eu ter escolhido essas 3 tecnologias:

Clojure foi por causa da Nubank, que usa ela para criar o seu Backend, o que me deixou curioso para entender mais sobre a linguagem utilizada numa empresa tão grande e inovadora.

Elixir foi principalmente por causa dos vídeos da Rockeatseat. Que quando eu vi um pouco sobre e o pipe operator, me fez ter muita vontade de estudar mais sobre a linguagem e o paradigma funcional.

Rust... Sinceramente, como não ficar curioso com a linguagens que já ganhou mais de 5 vezes seguidas como a Linguagem mais amada de todas? Além das várias notícias massas sobre ela que já saíram na Newsletter, como:

Vulnerabilidades relacionadas à memory safety do Android caem à medida que base de código utiliza mais Rust: entre 2019 e 2022, ocorrências desse tipo de falha caíram de 223 para 85 anualmente, representando 35% do total de vulnerabilidades do Android contra 76% há quatro anos. O Android 13 é a primeira versão em que a maioria do novo código adicionado usa linguagens memory safety como alternativa ao C/C++, com Rust representando 21%. As informações são do site Google Security Blog.

E essa outra notícia:

Desenvolvedores C++ estão cada vez mais difíceis de encontrar no mercado, apesar da grande demanda em setores como finanças e automotivo: um possível motivo para isso seria o fato da linguagem estar sendo rotulada como “legada”, com alguns especialistas sugerindo que, por questões de segurança, ela seja descontinuada em favor do Rust. As informações são do site eFinancialCareers.

Como eu sou apaixonado com a área de Mobile, ao ver uma notícia que falava sobre como Rust estava auxiliando os Softwares do Android, me fez ter uma certe tendência a pesquisar mais sobre ele do que as outras tecnologias.

As primeiras perguntas que tinha sobre cada uma das tecnologias eram:

• Como eu poderia construir de forma rápida e fácil API's Rest?
• Seria possível eu escalar de forma fácil a aplicação? Adicionando Features novas e removendo bugs de forma fácil?
• Existem integrações com tecnologias Cloud como AWS ou Azure?

Obviamente o Node.js arrebentou essas e outras perguntas de forma disparada!

O Clojure e Elixir me pareceram linguagens que precisam evoluir muito no sentido de integrações com outras tecnologias (principalmente Cloud), eu acabei sentindo que elas estão muito nichadas ainda e que eu poderia acabar fazendo um OverEngineering em algum momento (ou vários), o que contradiria o que eu disse no início do artigo sobre uma tecnologia prática e que me permitisse focar no que eu realmente gostaria, o UX do aplicativo.

Os Finalistas e a Decisão Final!

Apesar do Rust ser uma tecnologia recente, comparada a outras, ele possui uma comunidade muito forte e grandes patrocinadores.

Acabei achando de forma fácil frameworks que poderiam possibilitar que eu criasse API's Rest com Rust como o Rocket, mas claro que não tão práticos quanto um Nest.js.

Porém, na parte de analisar como as duas tecnologias se sairiam em Cloud, foi o que me fez ter a decisão definitiva.

Analisei algumas comparações de Rust e Node, que da para visualizar nesses artigos:

• Comparação de utilização de recursos do AWS Lambda usando NodeJS, Golang e Rust
• Escrevendo com performance: Porque escolhemos Rust

E gente do céu... Vamos aos Dados!

Uma Comparação Básica

Enquanto uma API Rest construída em Restify com Node.js suportava 8.000 requisições por segundo, o Rust usando Rocket suportou 72.000 requisições por segundo!

Mas e em Nuvem? Como fica?

E como esse gráfico abaixo mostra, quando comparado com Go, Node.js e Rust dentro do AWS Lambda, o Rust conseguiu ser mais rápido e usar menos recursos que as outras tecnologias:

Apenas isso já seria incrível! Mas, para melhorar, a AWS está criando suportes especialmente para o Rust, onde podemos acessar alguns recursos aqui nesse link:

• Rust na AWS

E o que achei mais interessante nos recursos da AWS sobre Rust, foi uma seção especialmente feita sobre Sustentabilidade, onde mostra como podemos usar Rust para reduzir o processamento de computadores e criar Softwares mais suntentáveis, indo muito na linha das ascensão das soluções e iniciativas ESG, que vão ter um crescimento maior ainda esse ano. Podemos acessar o link para essa seção por aqui:

• Sustentabilidade com Rust

Conclusão

Todas aquelas 3 perguntas que fiz inicialmente para decidir sobre qual tecnologia usar, foram respondidas! Onde pensei numa estratégia de criar microsserviços em Rust usando o AWS Lambdas, para uma ótima escalabilidade e praticidade na criação do meu Backend.

Caso tenham sugestões melhores, estou aberto a ideias e debates!

Algumas outras fontes de conhecimento que vi na decisão de escolher Rust:

• Essa Linguagem Está ROUBANDO O CORAÇÃO Dos Programadores Mundialmente
• Rust Lang (A Linguagem Mais AMADA de Todas) // Dicionário do Programador
• Engenheiros defendem Rust como a linguagem mais segura em softwares automotivos

Quem Sou?

Meu nome é Thiago, tenho 19 anos, sou desenvolvedor Mobile desde 2021! Já passei por alguns projetos e adoro sempre desafios que possam me fazer usar todo meu talento =)

Meu linkedin: https://www.linkedin.com/in/thiagoaugustozeferino/

Espero que não seja errado postar coisas "pessoais" como foto e linkedin, porém, as vezes sinto uma falta de contato humano no Tabnews, por só ter o nome das pessoas e, que muitas vezes está ilegível.