Quando nosso co-fundador e companheiro de engenharia Dmitriy Zaporozhets decidiu construir GitLab, ele escolheu fazê-lo com Ruby on Rails, apesar de trabalhar principalmente em PHP na época. GitHub, uma fonte de inspiração para GitLab, também foi baseado em Rails, tornando-o uma escolha lógica considerando seu interesse no framework. O CEO do GitLab Sid Sijbrandij acha que seu co-fundador fez uma boa escolha:
“Funcionou muito bem porque o ecossistema Ruby on Rails permite que você dê forma a muitas funcionalidades com alta qualidade”, ele explicou. “Se você olhar para o GitLab, ele tem uma enorme quantidade de funcionalidades. O desenvolvimento de software é muito complexo e para ajudar com isso, precisamos de muitas funcionalidades e Ruby on Rails é uma forma de fazê-lo”. Porque há todas essas melhores práticas que estão no seu caminho feliz, é também uma maneira de manter o código consistente quando você envia algo como o GitLab. Você é meio guiado a fazer a coisa certa”
Dependente de gemas úteis
Gemas Ruby desempenham um papel integral na construção do GitLab, com ele carregando mais de mil gemas não-únicas, de acordo com o Sid. Chamando o framework Ruby on Rails de “muito opinante”, ele acha que é um ambiente forte no qual construir uma aplicação complexa como GitLab.
“Há um grande ecossistema ao redor dele com gemas que podem fazer suposições sobre como você está fazendo as coisas e nesse sentido, eu acho que o ecossistema Ruby on Rails ainda está sem par”, ele diz. “Se você olhar para o nosso Gemfile, ele lhe dá uma indicação de quão grande é a torre de dependências que nós podemos construir. Ruby on Rails tem ombros incríveis para ficar de pé e teria sido muito mais lento desenvolver o GitLab em qualquer outro framework””
Desafios superados
Tudo isso não quer dizer que não tenha havido desafios na construção do GitLab com Ruby on Rails. A performance tem sido um problema que nossos desenvolvedores fizeram avanços para melhorar de várias maneiras, incluindo reescrever código em Go e usar o framework Vue. Este último está sendo usado para reescrever páginas frequentemente acessadas, como problemas e pedidos de fusão, assim eles carregam mais rápido, melhorando a experiência do usuário.
Go está sendo usado para resolver outros problemas que afetam os tempos de carga e reduzir o uso de memória.
“Ruby foi otimizado para o desenvolvedor, não para rodá-lo em produção”, diz Sid. “Para as coisas que são muito atingidas e têm que ser muito performantes ou que, por exemplo, têm que esperar muito tempo em um sistema IO, nós reescrevemos essas em Go … Ainda estamos tentando fazer o GitLab usar menos memória. Portanto, vamos precisar de activar a multithreading. Quando desenvolvemos o GitLab isso não era comum no ecossistema Ruby on Rails. Agora é mais comum, mas como agora temos tanto código e tantas dependências, vai ser um caminho mais longo para chegarmos lá. Isso deve ajudar; não vai fazer com que ele seja rápido, mas pelo menos vai usar menos memória.”
Adding Go to GitLab’s toolbox levou à criação de um serviço separado chamado Gitaly, que lida com todos os pedidos de Git.
Building on GitLab’s mission
O estilo organizado e estruturado do framework Ruby on Rails está de acordo com nossa missão principal. Porque Rails é racionalizado, qualquer um pode pular no GitLab e participar, o que o tornou especialmente atraente para Sid desde o início.
“Nossa missão é que todos possam contribuir”, explica ele. “Porque Ruby on Rails é realmente opinante sobre quais peças vão para onde, é muito mais fácil para novos desenvolvedores entrarem na base de código, porque você sabe onde as pessoas têm colocado as coisas. Por exemplo, em cada cozinha que você entra, você nunca sabe onde as facas e placas estão localizadas. Mas com Ruby on Rails, você entra na cozinha e ela está sempre no mesmo lugar, e nós queremos ficar por aí.
Em cada cozinha que você entra, você nunca sabe onde as facas e os pratos estão localizados. Mas com Ruby on Rails, você entra na cozinha e está sempre no mesmo lugar, e nós queremos ficar por aí.
“Eu fiquei realmente encorajado quando abri o projeto e o vi pela primeira vez um ano após o Dmitriy tê-lo iniciado. Eu o abri e ele é idiomático Rails. Ele seguiu todos os princípios. Ele não tentou experimentar algum tipo de moda em que estava interessado. Ele o transformou em uma aplicação de produção. Dmitriy vetou cuidadosamente todas as contribuições para garantir que elas se mantivessem fiéis a essas convenções, e ainda é o caso. Acho que temos uma base de código muito boa que permite que outras pessoas construam em cima dela. Um dos nossos sub-valores são soluções aborrecidas: não fazer nada de extravagante. Isto é para que outros possam construí-la por cima. Acho que fizemos isso muito bem… e estamos muito gratos por Ruby ter sido um ecossistema tão estável para nós construirmos sobre ele.”
Cobrir imagem de Elvir K em Unsplash
Deixe uma resposta