Executando verificação de segurança...
-2

Golang: simples e funcional

Golang: Você Não Precisa de Um Framework Para Fazer Uma API

Se você precisa de um framework gigantesco só para subir uma API, você não sabe programar.

Sabe qual é o maior problema dos devs de hoje? Eles não sabem o básico. Pergunta pra um "senior" de Node ou Python como funciona uma requisição HTTP de verdade. Ele não sabe. O cara depende de um framework como se fosse um assistente de vida, sem entender o que está acontecendo por baixo.

Aí entra Golang. Você quer rodar uma API? "net/http" já resolve 90% dos casos. Sem gambiarra, sem "mágica", sem precisar instalar 50 dependências só pra dar um 200 OK.

package main

import (
	"fmt"
	"net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintln(w, "Hello, World!")
}

func main() {
	http.HandleFunc("/", handler)
	http.ListenAndServe(":8080", nil)
}

Pronto, seu servidor HTTP rodando sem frescura.

Enquanto isso, no mundo Node.js:

Express,

Middleware de CORS,

Body parser,

ORM desnecessário,

E mais 200 pacotes npm que vão quebrar na próxima atualização.

Go entrega o que você precisa e só. Se quer algo mais robusto, usa Fiber ou Echo, mas não porque precisa, e sim porque escolheu otimizar. A verdade é que a maioria dos devs não sabe fazer nada sem um framework segurando a mão deles.

Se você ainda acha que precisa de um framework só pra fazer um CRUD, acorda. O que você precisa é entender HTTP, TCP, concorrência e performance. Go te força a aprender isso. Por isso ele é foda.

Se você não quer aprender, tudo bem. O mercado vai escolher quem quer.

Carregando publicação patrocinada...
17

Olha, esse discurso de “se precisa de framework, não sabe programar” é aquele tipo de papo que soa bonito no bar, mas não sobrevive cinco minutos na vida real.

Primeiro, saber programar não é sinônimo de reinventar a roda toda vez que você precisa subir uma API. Eu posso te explicar direitinho como uma requisição HTTP funciona — desde o handshake TCP até o parsing dos headers no Node.js com o módulo http — e ainda assim te dizer que usar um framework não é “dependência”, é inteligência. Tempo é dinheiro, e ficar escrevendo boilerplate pra cada endpoint é coisa de quem tem ego maior que prazo.

Você quer falar de básico? Beleza. O cara que usa Express.js ou FastAPI entende o HTTP tão bem quanto o “gênio roots” que monta tudo na unha. A diferença é que ele escolhe gastar energia resolvendo problemas do negócio, não debugando edge cases de parsing de query string que o framework já resolveu há dez anos. E se o “senior” não sabe explicar o HTTP, o problema não é o framework, é o processo de contratação que deixou passar um cara despreparado.

Agora, Golang com net/http? Claro, é ótimo, ninguém nega. Rápido, leve, eficiente. Mas dizer que resolve “90% dos casos” sem gambiarra é exagero de quem só fez CRUD básico. Tenta escalar uma API com autenticação, rate limiting, middlewares customizados e WebSockets em net/http puro. Vai funcionar? Vai. Vai ser bonito? Duvido. Você vai acabar escrevendo seu próprio “mini-framework” pra não enlouquecer — e adivinha? Isso é exatamente o que Express e companhia fazem, só que testado por milhões de devs.

Node.js sem dependências te dá um 200 OK com dez linhas. Golang faz parecido. A diferença é que, no mundo real, 90% das APIs não vivem de “200 OK” pelado. Elas precisam de validação, logging, roteamento dinâmico, e por aí vai. Aí o “mágico” do framework vira o herói, enquanto o purista tá lá, xingando o teclado e escrevendo mais 500 linhas de código que podiam ser três imports.
Saber o básico é essencial, concordo. Mas confundir “usar ferramentas” com “não saber programar” é só pose de macho alfa tech. Programador bom é o que entrega valor, não o que prova que sobrevive sem atalhos.

5

rapaz... loguei só pra te dar os parabéns kkkkkkk tu mandou a real. muitas vezes usar framework não é preguiça, é gerenciamento de tempo

2

muito obrigado por poupar meu tempo de escrever. quando o tabnews surgiu eu vi um lugar sem guerras de plataforma. tinha só conteúdo inteligente. agora o cara se alegra de fazer copia e cola de código toda vez que vai subir uma API nova e se acha o dono do mundo. Ou se não fizer copia e cola vai subir 10 APIs que fazem a mesma coisa de um jeito diferente.

2

Não acho que tem nada haver com o go em si...Node.js tem http de baixo nivel. Python sempre teve wsgi..etc.

Mas de fato a quantidade de "dev" que nunca viu uma request de http em texto plano, puro é assustadora. Talvez no dia que verem percebam que não precisa de muita coisa para responder corretamente...

1

Que post infeliz, na moral. Por todos esses motivos citados pelo pessoal e também pelo simples motivo que você usando a biblioteca http do Go, nao indica nada que você saiba programar melhor que uma "pessoa que usa framework" ou que você entenda de TCP.
Imagino você numa entrevista, quando o mercado estiver te selecioando você falar que é bom por conta que nao usa frameworks. (ainda mais na era da produtividade com uso de IA)

Me parece duas opções, ou você 🫵🏽 ainda está no hype no Go, ou você está com raiva de algum senior.

1
1

Vou explorar um ponto que ninguém fala neste tipo de discussão, que é o das iniciativas existirem para que seja reforçado padrões de desenvolvimento seguro e casos de uso não cobertos por bibliotecas padronizadas da linguagem.

Entendo o seu ponto e realmente o que é ensinado em bootcamps, cursos e universidades, não cobrem coisas como você entender bem como funciona determinada especificação de como funciona o protocolo HTTP/s. Mas o ponto essencial é que a "catequização" pelo uso de frameworks existem para diminuir a superfície de ataque, o ponto não é fazer as coisas na mão, porque até mesmo o programador que saiba como funciona o protocolo de cabo a rabo, vai deixar pontos vulneráveis pela exaustão em fazer uma aplicação na unha, coisas que os frameworks mais estabelecidos passaram.

O exemplo utilizado na publicação foi infeliz, porque se chega com uma espectativa de se mostrar um ponto mais bem explorado, do entendimento sobre estas decisões e não passou de um "Hello World", e entendo o jogo da expectativa baixa com um titulo como proposta de um conteúdo superficial, mas poderia ter entregado mais e informado melhor os leitores.

Esta maneira holística revela a maturidade do escritor que tem o seu lugar bem definido, mas ainda precisa exprimir mais da sua arte.

Agradeço o seu esforço, e nenhum discussão é boba, até porque a iniciativa foi nobre e mostra que não esta acomodado.

Parabéns!

1
1

Eu trabalho com Go hoje; entendo seu ponto de vista. Mas esse entendimento do "baixo nível", não sei até quando será necessário. A tendência é cada vez abstrair mais, à medida que as linguagens ou frameworks se tornarem mais expressivos e esconderem os detalhes.

Cada vez menos pessoas sabem qual algoritmo o database usa quando executa "select count(1) from User", nem qual estrutura de dados está sendo usada no armazenamento. Linguagens de 4ª geração são o futuro, acho eu...

Só uma opinião.

1

Não está errado, mas essa divisão dos programadores que vivem em cima de abstrações e não querem entender a forma mais rustica vai levar a uma onda onde, ainda mais programadores que criam as bases de abrstacao estarão escassos.

Os programadores que entender essas bases não podem morrer pois são eles que criam as abstrações.

1

E na visão de vcs, como podemos evitar que programadores que criam as abstrações não morram? pq hoje qualquer contexto que você busque de trabalho e pagar conta, acaba sendo centenas de abstrações que acontecem pra facilitar a vida do dev, e ainda mais com IA agora...

3

Em resumo

Valorizando o mercado e o estudo baixo nivel.

Só quero deixar ênfase aqui que um programador que meche com linguagens de alto nível não menos programador que um de baixo nível ou o contrário, pois ambos são extremamentes importante, apenas acho que o mercado não enxerga o baixo nível assim como enxerga o alto nível, talvez por uma questão de ser mais visual, e por isso acaba não incentivando o mercado baixo nível amplamente,acho que se criou uma divisão grande sobre esses conhecimentos que levou a uma separação meio complicada.

Bom eu penso que valorizando o estudo e a área é um bom meio, a maioria dos programadores que criam abstrações tiveram essas bases criadas em faculdades pensando em chegar em big techs, e isso tem sido deixado de lado pela nossa área, pelo menos no brasil.

A faculdade que estudo deixa essas bases de lado, então pelo menos na minha vivência é assim.

Infelizmente o amplo mercado atual foca muito mais em tecnologias existentes e voltadas somente para o usuário final, o que favorece o crescimento do uso de linguagens mais alto nível e frameworks que só aumentam a abstração e depois do bum das IA's o conhecimento de base ficou ainda mais de lado, já que empresas buscam a criação rápida dos produtos.

Mas minha humilde análise é que as IA's estão muito caras para serem mantidas e a tendência delas de não gerar retorno financeiro as levará para um declínio, e o mundo irá precisar de inovação novamente e será nessa época de inovação que o conhecimento de base se tornará relevante novamente, foi assim que os telefones se modernizaram, foi assim que os computadores se modernizaram.

Acho que acaba se tornando algo de época então é meio difícil gerar esse incentivo!

2

Acho que em alguns casos será bastante útil esse conhecimento, como otimização no uso de recursos ou melhoria de desempenho. Sempre tem demanda pra isso em aplicações corporativas ou desenvolvimento de embarcado. Então saber programar em uma linguagem de 3ª geração continuará tendo mercado, ainda que reduzido com o tempo.

Acho que não terá mais volta quando subirmos o nível com linguagens de 4ª geração. Da mesma forma que você não especifica como o database tem que fazer o scan na table ao usar SQL, vamos programar cada vez mais em alto nível e com mais abstrações. O lance é se adaptar pra não perder o bonde.

A linguagem Mojo tem recursos de alto nível para usar GPU, e vai cada vez mais abstrair os detalhes, não precisa mais ser especialista em "vectorized computation" e "parallelism".

Eu sou back-end, acompanho as inovações no front-end pra não ficar tanto defasado. Mas hoje em dia é tanto framework, libs, tudo componentizado. Tem até uma extensão no chrome pra você navegar pela internet e quando encontrar um botão com estilo legal, a extensão te entrega o code-snippet do botão. E um agente de IA vai fazer isso pra ti. Vanilla JS uma hora será bastante reduzido e somente usado para casos especiais.

3

Sou dev e gestor de devs há 30 anos. Hoje uso Node e Python pra back e respeito muito o Golang. Mas tudo que foi escrito me lembra um romance de ficção-científica que li há 40 anos: "A Rebelião das Máquinas ". Num mundo pós apocalíptico poucos humanos sobreviventes viviam dentro de casulos mecanizados controlados por computadores que faziam tudo, inclusive manutenção ao suporte de vida. E todos os engenheiros ja haviam morrido, só um restava. Esse cara estava velho e temia l, que, após morrer, as máquinas ficassem sozinhas na auto manutenção até que uma falha não prevista fizesse todos morrerem porquê as máquinas não sabiam os detalhes, só o genérico dos algoritmos.

1