Bom... comecei a cursar Engenharia de Software e, por fora, também comecei a fazer alguns cursos de backend.
Até agora, boa parte do que estudei envolve criação de APIs RESTful e operações de CRUD. Surgiu uma dúvida, no fim das contas, esse backend sobre o qual todo mundo fala é basicamente só fazer CRUD?
Esses cursos básicos só vão ensinar 1001 formas diferentes de fazer CRUD, mesmo. Aprender a fazer CRUD (desde que bem feito) é o suficiente para desenvolver a maioria dos backends por aí. Mas não, isso não é tudo.
A complexidade de um backend varia muito, CRUD é o piso de complexidade: literalmente é o mais simples possível que um backend pode ser. Mas acima do CRUD em diante, tem uma enorme variedade de complexidades.
Eventualmente você aprenderá sobre arquitetura de software e verá que existem arquiteturas muito mais complexas do que a que você aprendeu. O que você aprendeu até agora se chama arquitetura MVC que, de novo, é o piso de complexidade.
Existe uma grande variedade de arquiteturas de software, tanto monolitas quanto distribuídas. E sistemas distribuídos são os mais complexos. Você só aprendeu sobre sistemas monolitos MVC que, de novo, é o piso de complexidade.
Além de arquitetura de software existem também, naturalmente, os critérios de qualidade. Performance, segurança, escalabilidade, manutenibilidade etc. Quando você tem critérios de qualidade à serem atendidos, tudo fica mais complexo.
Obs.: você aprenderá sobre isso quando estudar sobre requisitos funcionais e não funcionais no seu curso.
E backend é como qualquer outro software, então pode ter operações complexas como qualquer outro software. Olha o Google Docs, por exemplo. Ele é uma suíte de escritórios inteira implementada no backend. Olha o backend da AWS ou Google Cloud, por exemplo. São sistemas gerenciando infraestrutura complexa, todo implementado em backend.
Entre outros detalhes. Então não, desenvolvimento backend não é só CRUD. Existe um mundo inteiro além do CRUD. Aprender essas coisas é o que diferencia o fazedor de CRUD do engenheiro de software.
Hmmm, obrigado! Esse pensamento surgiu porque tudo que eu estava vendo e aprendendo parecia ser sobre como fazer um CRUD novo. Quando fui tentar ajudar em outros projetos open source, percebi que parecia que tudo que eu estava aprendendo era apenas “mais um CRUD” enão conseguia ajudar em anda outros porojetos kkkkk.
Mas, enfim, valeu pela resposta. Deu para pegar uma perspectiva diferente.
Meus 2 cents,
Nao vou gastar muita saliva aqui, backend tem um bocado de conteudo alem do "CRUD".
Para ver mais sobre o assunto, recomendo este canal:
Um video em especial que permite olhar um pouco mais longe:
Saude e Sucesso !
Este post foi favoritado via extensão TABNEWS FAVORITOS
Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS
Se pensarmos somente pelo ponto de vista dos requisitos funcionais, ou seja, referentes às funcionalidades que você deve implementar, sim: desenvolver back-end é basicamente fazer CRUD. O back-end nada mais é do que a interface do cliente com a lógica de negócios. E esta, por sua vez, exige transações com banco de dados para persistir informações.
Mas, se olharmos na perspectiva dos requisitos não-funcionais, ou seja, pensando em como podemos garantir segurança, performance, entre outras coisas, o backend acaba sendo mais sobre como criar sistemas robustos no lado do servidor.
Hoje em dia, com os coding agents, a parte do CRUD é gerada para você em questão de segundos. O maior desafio para o engenheiro, na minha opinião, é como fazer com que o que está sendo gerado seja robusto e alinhado com as melhores práticas de programação.
O CRUD é uma das primeiras operações ensinadas ao estudar criação de APIs, mas o desenvolvimento back-end envolve muitos outros desafios. Alguns conceitos importantes que você deve estudar:
Só quis citar alguns conceitos, na verdade, o desenvolvedor back-end tem que conhecer o básico de cada um desses conceitos e muitos outros, não significa que ele deve dominar todos, porque cada sistema requer tecnologias diferentes, o desenvolvedor deve saber quais escolher, e se aprofundar nas tecnologias e conceitos adotados.
Para ter uma visão abrangente dos conhecimentos que o desenvolvedor deve obter, sugiro ler Backend Developer Roadmap.
Valeu!!!! Voou dar olhada no RoadMap
Não querendo ser injusto com a galera do frontend, mas seria mais certo dizer que frontend é coletar dados, exibir dados coletados, processados e recuperados, mas isso também seria injusto com eles.
Mas respondendo sua pergunta de forma bem simples, o backend é responsável por todo o funcionamento, processamento, armazenamento, recuperação, comunicação, etc.
Somente com o tempo, muitos projetos e muito trabalho, começamos a separar e distinguir bem o que cada um é, e principalmente a grande importância do backend.
Da uma olhada na rinhadebackend que está rolando. Eles tem perfil no X. La da pra ter noção dos desafios do povo que lida com backend.
Bllzzz, vou dar uma olhada depois. Isso é novidade "rinha de backend" kkkkkkk
Segundo alguns memes, sim, é.
Mas a realidade é que não é bem assim. Alguns projetos são um pouco, inclusive não se deveria criar tanto projeto novo que faz quase a mesma coisa.
Nem preciso dizer que muitos casos têm uma ou mais dessas letras mas não as 4.
Existe muita coisa que pode ser considerada como letra R (read), que pode ser algo que está gravado em algum lugar, seja banco de dados, sistema de arquivos, vindo de um serviço ou pego ou gerado na memória on the fly. Todo relatório, geração de documentos e assemelhados é um read, certo?
Quem realmente entende o que está fazendo com bancos de dados vai dizer que o D (delete) muitas vezes é, na prática, um U (update).
O que as pessoas falam de CRUD geralmente é o front de um banco de dados onde é comum fazer essas 4 operações.
Agora quem está lendo pode ficar confuso, já que eu falei em front e a pergunta fala em backend. Bem, as pessoas usam termos errados aos montes. E alguns termos podem se encaixar em situações diferentes.
O primeiro erro é as pessoas acharem que backend é um lógica que recebe um request via HTTP e entrega um resultado para quem pediu. Existem diversas outras formas. O banco de dados é um backend que será acessado por algum front, que não precisa ter UI, pode ser uma rotina em um servidor HTTP, que, portanto, é um backend web. Um compilador tem um backend que gera código alvo (que em muitos casos roda em uma plataforma específica) e tem o frontend que entende uma linguagem de programação e faz algumas operações antes de passar para o backend. O sistema de janelas de um sistema operacional costuma ser ter um backend e um frontend, mas você não vê nada disso.
E algumas pessoas projetam o CRUD em uma API restful, porque essa forma tem as 4 operações consideradas como CRUD (PGPD). Muitos casos têm vários Gets e Posts diferentes em cima de uma mesma base de dados ou outra forma de organização de dados. Encaixa em um CRUD? Ou vira, por exemplo, CRRRRRRRRRRRRRRUUUUUDD?
E se você tem um backend (servidor de alguma coisa) que consulta algo em outro servidor (backend)? Então esse seu backend está funcionando também como frontend do outro backend, certo?
Então podemos ter ainda um outro frontend que é a UI, que pode ser chamado de CRUD (nem todo mundo concorda com isso - algumas pessoas fazem um código único com todas as operações, ou possuem vários R em formatos diferentes).
E se você manipula duas ou mais tabelas em uma operação? Você tem dois ou mais CRUDs ou não? O CRUD pode ser executado em cascata ou algum outro modelo?
Precisamos mesmo ter algo chamado CRUD para definir algo, para comunicar bem? Ou o termo é só usado para indicar que fará uma coisa extremamente simples, provavelmente envolvendo um banco de dados na sua forma mais simples?
Termos criados pelo "mercado" geralmente são mal pensados e as pessoas usam de forma equivocada. E nem sabemos direito o que é equivocado ou não, porque... foram mal definidos. ER alguns desses termos acabam impregnando o mundo acadêmico, já que cada vez menos vemos pesquisas sérias.
E como as pessoas gostam de complexidade, vão fazer algo muito pior do que pode ser, muitas vezes sem agregar valor algum, ou pelo menos o valor agregado não compensa o que se paga. As pessoas costumam apenas reproduzir o que aprenderam.
Se a pessoa aprende em cima do que é popular, pode ser que aprenda errado e fará errado para sempre, e ensinará errado para outras pessoas, perpetuando o erro.
Cada vez mais a função do programador é definir certo o que vai fazer e menos fazer.
S2
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).