Muito bom seu conteudo Lucas, estou nessa fase de desacomplamento, adicionando interfaces, para no futuro facilitar troca de banco de dados, de ferramenta de cache, de meios de pagamento... Tudo isso é muito top. Muito bom ver, como você que trabalha em uma grande empresa faz. 👏👏👏
Discutimos as mesmas coisas durante uma década , nessa area o que mais existe é conflito de egos, o importante e simplificar ao máximo para construir algo realmente de grande valor. Linguagem é só um detalhe o importante e o modelo e design.
Cara sobre i18n, eu recentemente tive que fazer isso em um projeto relativamente grande que não tinha nada implementado. Foi um desafio muito legal e consegui concluir em duas semanas, sozinho. Basicamente fazendo isso que você falou, implementando um framework do zero e substituindo todas as strings. Eu sinceramente acho que acabou compensando mais ter feito isso em uma tarefa só, "no final", ou seja, custou menos estas duas semanas do que se os devs tivessem que ter lidado com isso desde o início, feature por feature. Mas é o que vamos ter que fazer a partir de agora, é chatinho, mas acostuma. Então nesse caso eu diria que é melhor fazer tudo em uma vez só, quando for preciso. Ou no máximo vai dar na mesma fazer desde o início. Enfim, meu caso é só um exemplo, não sei se aplica a toda situação. Se alguém tiver curiosidade, basicamente fiz isso em um projeto usando react-i18next junto com i18n padrão do Ruby on Rails. Usei Crowdin para pré-traduzir os YML e JSON em EN, PT e ES. Ficou muito bom com esta stack, diga-se de passagem haha.
Sim, esse comentário dele da internalização e das filas foi infeliz, também já tive que internacionalizar um app e demorei poucas semanas e foi bem tranquilo. Quanto as filas, trabalho em uma empresa que tem um app que tem 150 mil usuários pagante e não temos fila de processamento também. Ótimo canal em geral, mas esse vídeo veio com péssimos exemplos.
i18n é show, usei ele com react e usei as strings naquele formato t('string'). O resto (tradução e inserção nos arquivos de tradução) foi tudo feito com um bot em python que foi atrás de todas as strings do i18n do projeto, traduziu automaticamente com uma api externa e inseriu nos arquivos.
Cache, indexes, dB alta disponibilidade, não aguentou 4k rpm. No fim das contas as queries estavam executando no servidor redundante que tem alta latência e metade dos recursos esperados, tudo pq a equipe que mantém o serviço de banco relacional inverteu a poha das configs. Até achar esse BO fui questionado de todos os lados sobre o design de código que sempre esteve OK
14:52 rapaz o que eu mais vejo aqui no projeto é a lógica toda na controller, fazendo consulta direta no banco ou salvando as alterações, service só pra chamar outra API, repository não existe, valores como "passwordKey" pra poder fazer tal requisição sendo comparada com string hardcode. Quando eu ousei mover o código da controller pra service porque precisava de 2 controllers acessando ele quase levei uma lapada na daily kkkkk
Olá Lucas e pessoal, eu sou iniciante e fiquei em duvida no minuto 14:50. Eu desenvolvi um sistema CRUD por exemplo em Spring, essa API do CRUD não deve estar no mesmo projeto que o banco está modelado? Devem ser projetos diferentes se comunicando?
Sabe aquela pessoa que depois que aprende a usar Photoshop quer colocar todos os efeitos em tudo? A versão Dev disso são problemas de escala imaginários!
Pra mim hoje tudo tem que ser escalável, principalmente se você já tem experiência naquilo. Já planejei escalabilidade que parecia desnecessário e agilizou novas implementações para menos de 20% do tempo 2 anos depois, otherwise tudo teria que ser refeito, portanto mais que o dobro do tempo da primeira implementação. Hoje em dia boilerplate é mínimo. (Agora refactor é outra questão)
Aprendi mais nesse video que em 6 anos de trabalho, coisas que fui aprendendo e pegando aos poucos, como i18n logo de começo, log, abstrair servicos de terceiros/cloud
No meio da pandemia trabalhei em alguns projetos pra uma loja loja de roupa bem conhecida, daquelas que você encontra em qualquer shopping, essa preocupação era constante, mesmo tendo uma base de meia dúzia de usuários. Microserviço pra todo lado, serviço de mensageria, várias instâncias de CosmoDB, porque na visão de algum "arquiteto" fazer join ou separar em várias queries deixava o sistema lento. Algumas semanas atrás tentei acessar, todos já foram removidos, só serviu pra jogar dinheiro fora.
O que eu costumo fazer é desenvolver aquela solução, já pensando numa possível escala, mas espero os usuários utilizar antes pra entender a necessidade. Quando é algo que já imagino que vai ter bastante acesso aí n tem muita mistério, é teste de carga e otimização. Mas geralmente é uma paginação ali, um cachezinho aqui.
Tem os níveis: jr, pleno, senior e o cara do comercial/marketing com habilidades em TI. O último se preocupa em resolver o problema do cliente, o restante fica sentindo tesão em escovar bits e new stacks que resolvem algo que as pessoas não se importam realmente a menos que afete a vida delas, e se afetar, não vão ligar como você fez pra resolver hahah
Meu tech lead implicou comigo porque eu fiz um if ao inverso do que ele pensou kkkkkkkkkk Ele é gente boa, no final consegui convencer ele que dava na mesma.
Tem que cuidar só pra não deixar pra "depois" e se deparar com a necessidade de refatorar um elefante gigantesco porque não se preocupou e fez "evolutivo".
A primeira parte do vídeo eu chamo de adolescência do programador, quando os hormónios estão a flor da pele e o programador quer sair pimbando tudo… mas acaba fazendo mais do que precisa e passando vergonha…
Em tecnologia, existe um mercado de produtos, consultorias e conhecimento. Como hoje tudo é mercadoria, estamos imersos num espaço onde tem um monte de feirante gritando para te vender alguma coisa. Quanto maior a empresa, maior será a banca e maior será o recurso gasto para chamar sua atenção. E digo isso não de forma pejorativa. Conforme o tempo vai passando (e quebrando muito a cara) vc vai pegando a malandragem e entendendo se estão tentando te vender um vaca leiteira quando vc apenas procura um peixe. Sobre os microserviços... +- 10 anos atrás um mercado disso começou a surgir (muito impulsionado pelas bigtechs) e empresas viram uma oportunidade de lucrar em cima disso. Muita gente adotou - grande parte quebrou a cara, inclusive eu - e eles encheram o bolso de dinheiro. Algumas coisas legais surgiram, como o docker e orquestradores de serviços, mas muito chorume escorreu.
Eu tenho a impressão que microsserviços tem se tornado cada mais fácil de implementar e que pode até virar um padrão da indústria. Mas eu teria muito cuidado mesmo sobre a adoção em certos projetos. Mas até acho viável adotar desde o início, mesmo em projetos pequenos. Certamente requer um bom nível de maturidade dos envolvidos. Mas isso vale para tudo, tem gente que até hoje não sabe nem usar direito um monolito baseado em MVC básico.
nem ferrando que é mais facil de um monolitico. Nem ferrando. só ter que ficar sincronizando dados entre varias aplicacoes, ser eventualmente consistente, nao ter ponto unico de falhav ja te faz ser MUITO mais complexo. Agora que for pra implementar cagado, com um monte de aplicacoes apontando para o mesmo banco de dados Eu nao penso duas vezes em fazer em monolitico se eu o projeto é pequeno.
@@edimachzin ué... Seu comentário começa dizendo que está se tornando mais fácil implementar. Talvez mais fácil no sentido de comparar com 10 anos atrás, e não comparado com monolítico como deu a entender. Aí sim, faz sentido
Bom dia lucas e para a comunidade, comecei a assistir recentemente o seu canal e tem sido bem proveitoso e benefíco para ampliar o meu gama de pensamento em relação ao mercado de tech. teriam alguma indicação de algum criador de conteúdo voltado para IA/ML? gostaria que o mesmo fosse similar ao Lucas para assistir os vídeos
E se eu receber 10 mil acessos por segundos, e se eu vender para china e japão, e se o mundo entrar em colapso e o pagamento agora é somente via graveto de cedro, e se.... enquanto isso o filho do zinho fez o crud básico e vendeu pro zé da padaria e você está com seu projeto perfeito só dando prejuízo por nunca sair do papel. saber dosar o que o cliente precisa e pode pagar é muito mais importante do que produzir uma ferrari e o cliente só consegue pagar um fusca, ambos saem no prejuízo!
Eu fico me perguntando como que alguém vai aprender esses conceitos mais "avançados" sem aplicar eles em algum lugar, é obvio que ao se pensar num produto real o arquiteto vai ter que considerar uma gama gigantesca de informações pra deixar o produto factível, e que caso ele pense em problemas que ele ainda não tem vai acabar causando o over engineering. O que me preocupa é como alguém se torna capaz de resolver um problema de escala sem ter encarado um problema do tipo antes? As vezes criar um side project inchado pra tentar resolver os problemas nele é uma boa saída.
essa semana tive uma reunião com um time Dev terceiro, 1 mês da última reunião, na última reunião tinha passado o que era pra ser feito, chegou no dia da reunião não só não tinham feito nada do que falei como chegaram com um diagrama do banco remodelado, apenas um detalhe, o projeto deles era um front específico 😂
O maior problema é quando o dev tenta explicar para o cliente que a aplicação dele seria melhor se fosse escalável 😂 E o cliente no final das contas só tá ligando para "Tá funcionando? Então tanto faz"
Sobre a parte de fila de processamento oque seria isso exatamente? Então se meu get ou post ir direto na minha base e fazer a consulta ou inser ta errado?
O ideal pro cenário que eu imagino que você está pensando é ter um load balancer intermediando essas requests. então teu post ia bater primeiro no load balancer e então no serviço que se comunicaria com o database, dessa forma cessando o problema q o lucas mencionou.
Não está errado, você pode continuar inserindo e consultando diretamente da rota sem problemas, mas ,como foi dito, isso não é escalável. O uso de uma fila de processamento vem pra suprir algumas necessidades, como diminuição do tempo de resposta para o usuário. Um banco não pode abrir infinitas conexões simultâneas, isso ocorre pq é muito custoso manter a consistência dos dados ( evitando condições de corrida, verificando constraints, etc), logo apenas um pequeno número de conexões são feitas ao banco por vez, onde, em muitos casos, se utiliza pools de conexão já que abrir conexão com o banco também é algo custoso. Então o que acontece caso todas as conexões estejam ocupadas no momento da requisição? O usuário terá que esperar até alguma conexão dessa pool de conexões estar livre para que a modificações ocorresse e, enfim, retornasse uma resposta. Esse processo pode ser bastante demorado dependendo da quantidade de requisições feitas simultaneamente. É nesse caso que as filas entram, elas guardam as informações que causarão modificações no banco e , por, terem limite de conexão, devolvem rapidamente uma resposta ao usuário. Posteriormente, quando estiver com conexões livres, o banco pode utilizar essa informações para realmente alterar seu estado. Acho que vc já deve imaginar que isso não se aplica a todo caso, já que existem situações onde é necessário uma resposta imediata por parte do banco (criação de uma conta, por exemplo). Apesar disso, em modificações não urgentes, como mudanças de preferências de perfil, essa estratégia deve funcionar muito bem.
@@edsonmartinelli Olá! Pode explicar um pouquinho melhor essa ideia de abstrair e reproduzir de forma virtual as modificações na Queue? A ideia é manter um state virtual pra ação? Se sim, como esse estado seria gerido e salvo no meio-tempo entre esse processamento e a persistencia final na database?
O exemplo da classe boleto do nubank, concordo que nao precisa da factory só pra um banco mas não custa nada fazer um NubankBoleto e uma interface pro dia que mudar de banco.
Cara concordo, mas até que ponto conseguimos criar um boa abstração que será realmente util se não tivermos mt conhecimento do dominio? Por exemplo hoje em dia existem boletos que retornam pix junto não só o codigo de barras, será q abstração q criamos anos atrás ainda é útil? Ou vamos ter que refatorar de qualquer modo? Venho pensando nisso em extender o máximo o momento da criação da abstração.
Uma duvida de leigo (bota leigo nisso) Um micros serviço pode ser compartilhado entre diferentes aplicações, tipo um sistema de gerenciamento de fezes, eu poderia usar na minha própria aplicação, como distribuir esse micro serviço para outra empresa cobrando uma taxa. Já o monólito eu somente poderia usar esse serviço na minha própria aplicação pelo fato de ele ta acoplado nela ou pelo menos seria muito complicado de reutilizar ela em outras aplicações. Esse meu raciocínio ta errado?
Como poderia dizer o mano Deyvin, em algum momento "escalabilidade" foi "pirâmide". Lembro de uma época em que pra qualquer MVP e afins essa perguntava era levantada.
Cara o que mais tem é Dev querendo papagaiar que tem que que usar kubernetes, com configuração para subir até 10 pods no pico pq pode acontecer de ter 100K usuários no mesmo segundo e bla bla bla bla bla, e o aplicativo nem ao menos está lançado. NÃO TEM ABSOLUTAMENTE NINGUÉM USANDO, então primeiro lança a parada e coloca o monitoramento e vai vendo como anda no dia a dia, a partir do momento que ver que tá começando a dar perdas aí sim tem um problema pra resolver.
Não necessariamente, porque é como o Lucas Montano mostrou no vídeo, a escalabilidade também depende de outros fatores que não estão relacionados à performance (por exemplo, desacoplamento de dependências e serviços de terceiros, facilidade de internacionalização e de edição do código no futuro). A escalabilidade tá bem relacionada a poder crescer não só a base de usuários de um software com facilidade, mas também a poder adicionar novas funcionalidades ou mudar elementos da estrutura sem grandes problemas.
@deyvid322 É mais questão de terminologia mesmo, nunca me referi ou peguei a alguém se referindo a código como escalavel, código limpo, de qualidade, seguro, é o que escuto, escalavél é a solução como um todo, acho que um código legivel é a unica coisa que importa na hora de se adicionar mais código.
O Lucas comentou que nunca se conecta o banco de dados diretamente na API, mas durante os anos todos que eu trampei como dev vejo exatamente esse padrão, uma camada de repository conectada diretamente ao db kkkkk Será que eu entendi o "diretamente" errado? De que outra maneira o mercado faz essa conexão?
Acho que é comum de isso acontecer, programadores acabam se empolgando quando aprendem coisas novas, então, acaba sendo meio que 8 ou 80 na hora de desenvolver. Pessoalmente tento aplicar o que aprendo, mas, sem exagerar demais na complexidade, até porque, excesso de recursividade vai fazer com que eu mesmo tenha dificuldade em ler meu código daqui algum tempo, por isso, acho que nessas horas o K.I.S.S. (Keep It Simple, Stupid) é uma boa prática à ser seguida pra mensurar a complexidade.
@@gabrielrissi6583 a minha solução é fazer documentação , antes de querer fazer codigo , escreve a ideia no papel , depois de um tempo revisa , ai vc vai poder perceber se a ideia é boa ou não
Ctx oto = event.getCtx(); switch(teste){ case "a": oto.blabla case "b": oto.blabla case "c": //não precisa de oto } Man, isso é escalavel é performático? não é melhor fazer switch(teste){ case "a": Ctx oto = event.getCtx(); case "b": Ctx oto = event.getCtx(); case "c" } Porque ai voce não precisa criar a variavel oto e pegar o contexto toda vez no switch, porque algumas vezes não precisa tipo no caso c man, nao é melhor colocar um final ai no parametro do método porque ele não muda de valor e não é mior a gente usar os null mesmo Optional aqui pode da atraso e não é melhor nós implementamos isso só usando static porque fica instanciando objetos pode demorar o método é chamado 20 vezes por segundo.
Eu tenho um monolito com DB direto na API atendendo de dezenas a centenas de requisições por segundo. Tá errado? Tá. Vou refatorar? Só se for pra implementar IA. Kkkk
Depende hahahahah. Na realidade se algumas requisições como alterar um dado da conta não precise ser feita de imediato, da pra jogar pra uma fila de processamento. Depende se tu precisa da resposta imediata. A fila de processamento funciona tipo: “to fazendo umas coisas aqui , assim que eu terminar eu resolvo”
Na minha opinião a arquitetura da solução em si deveria ser algo desde o dia 0. Eu já vi muita conversa: De começo vamos criar um monolito depois conforme necessidade a gente ajusta arquitetura... Ou até mesmo a implementação de uma pdrão de projeto: Vamos implementar esse aqui depois a gente muda caso precise... Ai o cara nunca refatora porque envolve testes regressivos e fere o O do SOLID Doce ilusão
Se o projeto não precisar ser mantido por um longo período de tempo (por exemplo, um MVP) ou um projeto que vai ficar rodando e nunca mais será mexido, ai realmente a Arquitetura Limpa pode ser um exagero. Todavia, mesmo em projetos simples, alguns conceitos da Arquitetura Limpa aliados ao SOLID podem sim gerar um código muito mais fácil de ser mantido ao longo do tempo e de escalar, então, acho que "depende" do objetivo do que está se desenvolvendo. Agora, também não adianta o cara aplicar Arquitetura Limpa em um código extremamente "sujo", por isso, mais do que se preocupar com qual arquitetura seguir, o ideal é primeiro se preocupar em aplicar boas práticas pra tornar o código mais simples e legível.
Tudo depende como o cara fez a aplicação.. kkkkkk tenho certeza que na empresa que trabalho, a 15 anos atras, as pessoas fizeram a pergunta "-isso é escalavel?" e a resposta foi nao.... Resolveram fazer uma tipagem por ID de produto... produtos abaixo do id 1000000, sao produtos normais, acima, produtos de assistencia.... E adivinha!!!! kkkkkk logo logo vai estourar o 100000 e nao sabem o que fazer agora pelo tamannnho da empresa.
Quando eu fui aprender a fazer edição de vídeo, eu colocava um transição diferente fodona em cada corte kkkk Empolgação existe, é um monstro que pode consumir nossa alma, cuidado. Hoje sempre faço a pergunta: é realmente necessário ou tem algo de menor complexidade que faz a mesma coisa e vou poder jogar meus games no final de semana?
Mas tem um ponto muito importante que é custo! monolito escala, escala, mas é barato escalar? definitivamente não! pense numa maquina que roda um serviço todo e o que pesa é o faturamento. Já tive esta experiencia... uma maquina que custava $1000 / mes, passamos a pagar $40/ mes por separar em microservicos... Não necessáriamente precisa ser microservico, mas um serviço separado por escopo, é essencial pensar já desde o começo, vc nunca tera o custo de $1000 já de paulada. E pense o tempo que os donos se deram conta que tavam tendo prejuizo por conta da escolha que fizeram... Foram milhares de dolares jogados no lixo, pq ignoraram essa pergunta.
concordo e entendo o ponto, mas muitas vezes ao migrar para micro serviços acabamos otimizando partes do sistema que estavam sendo negligenciadas… por isso fico sempre meio cético, eh difícil e trabalhoso de fato medir e comparar.
o que é um monólito? ele escala? ChatGPT: Um monólito é um tipo de arquitetura de software onde toda a aplicação é construída como um único, indivisível bloco. Em contraste com arquiteturas mais modernas como microserviços, onde uma aplicação é dividida em várias partes independentes, um monólito é uma única aplicação que pode ser subdividida internamente em diferentes módulos ou componentes, mas que é implantada e executada como uma unidade única. Características de um Monólito Código Único e Coeso: Todo o código-fonte está em um único repositório e é construído e implantado como uma unidade. Escalabilidade: Escalabilidade Vertical: Em um monólito, a escalabilidade geralmente é feita adicionando mais recursos ao servidor (mais CPU, memória, etc.), o que é conhecido como escalabilidade vertical. Isso pode ser limitado pela capacidade do hardware disponível. Escalabilidade Horizontal: Embora seja possível escalar horizontalmente (adicionando mais instâncias da aplicação), isso pode ser mais complexo, pois todas as instâncias precisam compartilhar o mesmo código e, frequentemente, o mesmo banco de dados. Desenvolvimento e Implantação: Desenvolvimento Unificado: Todos os desenvolvedores trabalham no mesmo código-fonte e fazem modificações que afetam toda a aplicação. Implantação Simples: A aplicação é implantada como um único artefato, o que pode simplificar o processo de implantação e gerenciamento. Acoplamento: Acoplamento Interno: Os diferentes módulos ou componentes dentro do monólito são fortemente acoplados, o que pode tornar a modificação de um módulo impactante para outros módulos. Manutenção e Evolução: Manutenção Complexa: À medida que a aplicação cresce, a manutenção pode se tornar complexa e mais difícil devido à interdependência dos módulos. Evolução e Atualizações: Mudanças em uma parte da aplicação podem exigir que a aplicação inteira seja recompilada e implantada, o que pode aumentar o risco de problemas. Escalabilidade de um Monólito Escalabilidade Vertical: Prós: Mais simples de implementar inicialmente e pode ser suficiente para muitos casos de uso. Contras: Limitado pela capacidade do hardware e custos crescentes com a necessidade de servidores mais potentes. Escalabilidade Horizontal: Prós: Possível adicionar mais servidores para distribuir a carga. Contras: Pode ser complexo devido à necessidade de sincronização entre instâncias e gerenciamento de estado. Comparação com Microserviços Microserviços: Em uma arquitetura de microserviços, a aplicação é dividida em serviços pequenos e independentes que podem ser desenvolvidos, implantados e escalados de forma independente. Isso oferece maior flexibilidade e pode facilitar a escalabilidade horizontal, mas também introduz complexidade adicional no gerenciamento e comunicação entre serviços. Resumo Monólito: Uma aplicação única e coesa que pode ser escalada verticalmente e horizontalmente, mas pode enfrentar desafios de escalabilidade à medida que cresce. Escalabilidade Vertical: Adicionando mais recursos ao servidor. Escalabilidade Horizontal: Adicionando mais instâncias, mas pode ser mais complexo devido ao acoplamento e gerenciamento. Se você está construindo uma nova aplicação ou considerando a evolução de uma existente, é importante considerar as necessidades específicas de escalabilidade e manutenção ao escolher a arquitetura mais apropriada. Se precisar de mais detalhes ou tiver outras perguntas, estou à disposição!
1:05 "Isso é escalável cara?" (são apenas 10 itens na lista) é desse jeito mesmo kkkkkkkkkkkkkkkkkkkk.
KKKKKKKKKKKKKKKKKKKKKKKKKKKKK
Fico puto kkkkkkkkkkkkkkkkkkkkkkkkkkkk
aham, só 10 itens e 12.000 pedidos só pela manhã! kkkkkk ( minha realidade.... quem dera se tivessem dado valor nisso antes)
10 itens na lista agora, mas e se esses 10 virarem 100000?
migrando java pro go com 10 users mensais
Kkkkkk ai é foda
se tiver 1 dev cansado do bloat na equipe já vale a pena kkkkkkkkkkk
KKKKKKKKKKKKK pqp, vai precisar de uma mensageria pra isso aí
Muito bom seu conteudo Lucas, estou nessa fase de desacomplamento, adicionando interfaces, para no futuro facilitar troca de banco de dados, de ferramenta de cache, de meios de pagamento... Tudo isso é muito top. Muito bom ver, como você que trabalha em uma grande empresa faz. 👏👏👏
Discutimos as mesmas coisas durante uma década , nessa area o que mais existe é conflito de egos, o importante e simplificar ao máximo para construir algo realmente de grande valor. Linguagem é só um detalhe o importante e o modelo e design.
Falou tudo, brigas de egos bestas que no final, não leva a nada.
Cara sobre i18n, eu recentemente tive que fazer isso em um projeto relativamente grande que não tinha nada implementado. Foi um desafio muito legal e consegui concluir em duas semanas, sozinho. Basicamente fazendo isso que você falou, implementando um framework do zero e substituindo todas as strings.
Eu sinceramente acho que acabou compensando mais ter feito isso em uma tarefa só, "no final", ou seja, custou menos estas duas semanas do que se os devs tivessem que ter lidado com isso desde o início, feature por feature. Mas é o que vamos ter que fazer a partir de agora, é chatinho, mas acostuma.
Então nesse caso eu diria que é melhor fazer tudo em uma vez só, quando for preciso. Ou no máximo vai dar na mesma fazer desde o início. Enfim, meu caso é só um exemplo, não sei se aplica a toda situação.
Se alguém tiver curiosidade, basicamente fiz isso em um projeto usando react-i18next junto com i18n padrão do Ruby on Rails. Usei Crowdin para pré-traduzir os YML e JSON em EN, PT e ES. Ficou muito bom com esta stack, diga-se de passagem haha.
Sim, esse comentário dele da internalização e das filas foi infeliz, também já tive que internacionalizar um app e demorei poucas semanas e foi bem tranquilo. Quanto as filas, trabalho em uma empresa que tem um app que tem 150 mil usuários pagante e não temos fila de processamento também. Ótimo canal em geral, mas esse vídeo veio com péssimos exemplos.
i18n é show, usei ele com react e usei as strings naquele formato t('string'). O resto (tradução e inserção nos arquivos de tradução) foi tudo feito com um bot em python que foi atrás de todas as strings do i18n do projeto, traduziu automaticamente com uma api externa e inseriu nos arquivos.
Eu não sou programador, tô bem no comecinho. E assisto todos os seus vídeos mesmo sem entender porra nenhuma KKKKk
Continue Mano!
Eu comecei igual você. Hoje em dia já entendo metade e até completo os raciocínios.
Foi muito bom passar por isso!
Eu também tô do mesmo jeito mano kkkk
Eu também kkkkkk
Acho que vcs estão apaixonados no mensageiro, não na mensagem 😂
Tu tá trabalhando como programador?
Cache, indexes, dB alta disponibilidade, não aguentou 4k rpm. No fim das contas as queries estavam executando no servidor redundante que tem alta latência e metade dos recursos esperados, tudo pq a equipe que mantém o serviço de banco relacional inverteu a poha das configs.
Até achar esse BO fui questionado de todos os lados sobre o design de código que sempre esteve OK
4k rpm. Tá falando de motor de carro?
@@paulopma requests per minute
Quando alguém te perguntar: "Mas isso é escalável?", responda com outra pergunta: "Precisa ser?"
14:52 rapaz o que eu mais vejo aqui no projeto é a lógica toda na controller, fazendo consulta direta no banco ou salvando as alterações, service só pra chamar outra API, repository não existe, valores como "passwordKey" pra poder fazer tal requisição sendo comparada com string hardcode. Quando eu ousei mover o código da controller pra service porque precisava de 2 controllers acessando ele quase levei uma lapada na daily kkkkk
Olá Lucas e pessoal, eu sou iniciante e fiquei em duvida no minuto 14:50. Eu desenvolvi um sistema CRUD por exemplo em Spring, essa API do CRUD não deve estar no mesmo projeto que o banco está modelado? Devem ser projetos diferentes se comunicando?
pode estar no mesmo projeto, tu pode ter um “monorepo”
@@LucasMontano Muito obrigado
50% Conteúdo
50% Inter... Internalia... Internacionalização
Perfeitamente Balanceado
Sabe aquela pessoa que depois que aprende a usar Photoshop quer colocar todos os efeitos em tudo?
A versão Dev disso são problemas de escala imaginários!
Pra mim hoje tudo tem que ser escalável, principalmente se você já tem experiência naquilo. Já planejei escalabilidade que parecia desnecessário e agilizou novas implementações para menos de 20% do tempo 2 anos depois, otherwise tudo teria que ser refeito, portanto mais que o dobro do tempo da primeira implementação. Hoje em dia boilerplate é mínimo. (Agora refactor é outra questão)
Aprendi mais nesse video que em 6 anos de trabalho, coisas que fui aprendendo e pegando aos poucos, como i18n logo de começo, log, abstrair servicos de terceiros/cloud
No meio da pandemia trabalhei em alguns projetos pra uma loja loja de roupa bem conhecida, daquelas que você encontra em qualquer shopping, essa preocupação era constante, mesmo tendo uma base de meia dúzia de usuários. Microserviço pra todo lado, serviço de mensageria, várias instâncias de CosmoDB, porque na visão de algum "arquiteto" fazer join ou separar em várias queries deixava o sistema lento. Algumas semanas atrás tentei acessar, todos já foram removidos, só serviu pra jogar dinheiro fora.
O que eu costumo fazer é desenvolver aquela solução, já pensando numa possível escala, mas espero os usuários utilizar antes pra entender a necessidade.
Quando é algo que já imagino que vai ter bastante acesso aí n tem muita mistério, é teste de carga e otimização.
Mas geralmente é uma paginação ali, um cachezinho aqui.
Conteúdo valioso! Vlws pelas dicas👏🏻
Cara, é muito real oq ele fala nos vídeos KKKKKKKK Sou estagiário e a maioria que vejo acontece. "Isso é escalável?????" KKKKKKKKKKKKK
To exatamente ajudando na "internacionalização" de um projeto, passando as strings pra chamada de localization
No ponto. 75% das vezes que programo algo eu esqueço que eu quero grana e não a obra-prima da engenharia de software
Caraca que vídeo massa, amanhã mesmo vou gerar cards para os devs do time para poder avaliar se nossas aplicações são escaláveis !
“Inter. na… inter…inter… internacioliza. nação. inter… interna… internacionalização“ 😂😂😂
Tem os níveis: jr, pleno, senior e o cara do comercial/marketing com habilidades em TI. O último se preocupa em resolver o problema do cliente, o restante fica sentindo tesão em escovar bits e new stacks que resolvem algo que as pessoas não se importam realmente a menos que afete a vida delas, e se afetar, não vão ligar como você fez pra resolver hahah
Lá na firma a gente usa o termo "expansível" pra se referir a inclusão de features e "escalável" para se referir ao aumento no número de usuários.
cara eu amei esse vídeo!!!! 👍👍👍
Meu tech lead implicou comigo porque eu fiz um if ao inverso do que ele pensou kkkkkkkkkk
Ele é gente boa, no final consegui convencer ele que dava na mesma.
Que isso, sou tech lead e não ligo pra essas perfumarias.
Existem brigas boas e brigas inúteis. Essa certamente é inútil.
Tem que cuidar só pra não deixar pra "depois" e se deparar com a necessidade de refatorar um elefante gigantesco porque não se preocupou e fez "evolutivo".
Empresa que não tem esse dinheiro sempre deixará para depois ou para ultimar hora. É sempre assim, não tem jeito.
A primeira parte do vídeo eu chamo de adolescência do programador, quando os hormónios estão a flor da pele e o programador quer sair pimbando tudo… mas acaba fazendo mais do que precisa e passando vergonha…
Eu não sou programador e a minha área de atuação é T.I mas tudo que eu aprendo aqui me ajuda de forma absurda. 😂
Em tecnologia, existe um mercado de produtos, consultorias e conhecimento. Como hoje tudo é mercadoria, estamos imersos num espaço onde tem um monte de feirante gritando para te vender alguma coisa. Quanto maior a empresa, maior será a banca e maior será o recurso gasto para chamar sua atenção. E digo isso não de forma pejorativa. Conforme o tempo vai passando (e quebrando muito a cara) vc vai pegando a malandragem e entendendo se estão tentando te vender um vaca leiteira quando vc apenas procura um peixe.
Sobre os microserviços... +- 10 anos atrás um mercado disso começou a surgir (muito impulsionado pelas bigtechs) e empresas viram uma oportunidade de lucrar em cima disso. Muita gente adotou - grande parte quebrou a cara, inclusive eu - e eles encheram o bolso de dinheiro. Algumas coisas legais surgiram, como o docker e orquestradores de serviços, mas muito chorume escorreu.
Eu tenho a impressão que microsserviços tem se tornado cada mais fácil de implementar e que pode até virar um padrão da indústria. Mas eu teria muito cuidado mesmo sobre a adoção em certos projetos. Mas até acho viável adotar desde o início, mesmo em projetos pequenos. Certamente requer um bom nível de maturidade dos envolvidos. Mas isso vale para tudo, tem gente que até hoje não sabe nem usar direito um monolito baseado em MVC básico.
nem ferrando que é mais facil de um monolitico. Nem ferrando.
só ter que ficar sincronizando dados entre varias aplicacoes, ser eventualmente consistente, nao ter ponto unico de falhav ja te faz ser MUITO mais complexo.
Agora que for pra implementar cagado, com um monte de aplicacoes apontando para o mesmo banco de dados
Eu nao penso duas vezes em fazer em monolitico se eu o projeto é pequeno.
Colega eu não disse que é mais fácil. Aliás, eu não afirmei absolutamente nada na direção do que está falando, até concordo contigo. Abraço
@@edimachzin ué... Seu comentário começa dizendo que está se tornando mais fácil implementar.
Talvez mais fácil no sentido de comparar com 10 anos atrás, e não comparado com monolítico como deu a entender. Aí sim, faz sentido
Bom dia lucas e para a comunidade, comecei a assistir recentemente o seu canal e tem sido bem proveitoso e benefíco para ampliar o meu gama de pensamento em relação ao mercado de tech. teriam alguma indicação de algum criador de conteúdo voltado para IA/ML? gostaria que o mesmo fosse similar ao Lucas para assistir os vídeos
E se eu receber 10 mil acessos por segundos, e se eu vender para china e japão, e se o mundo entrar em colapso e o pagamento agora é somente via graveto de cedro, e se....
enquanto isso o filho do zinho fez o crud básico e vendeu pro zé da padaria e você está com seu projeto perfeito só dando prejuízo por nunca sair do papel.
saber dosar o que o cliente precisa e pode pagar é muito mais importante do que produzir uma ferrari e o cliente só consegue pagar um fusca, ambos saem no prejuízo!
Eu fico me perguntando como que alguém vai aprender esses conceitos mais "avançados" sem aplicar eles em algum lugar, é obvio que ao se pensar num produto real o arquiteto vai ter que considerar uma gama gigantesca de informações pra deixar o produto factível, e que caso ele pense em problemas que ele ainda não tem vai acabar causando o over engineering. O que me preocupa é como alguém se torna capaz de resolver um problema de escala sem ter encarado um problema do tipo antes? As vezes criar um side project inchado pra tentar resolver os problemas nele é uma boa saída.
Internacionalização eh sempre early optimization. Quantos % dos negócios de vcs internacionalizaram?
"depende", a palavra mais potencialmente pretenciosa dos engenheiros de SW
essa semana tive uma reunião com um time Dev terceiro, 1 mês da última reunião, na última reunião tinha passado o que era pra ser feito, chegou no dia da reunião não só não tinham feito nada do que falei como chegaram com um diagrama do banco remodelado, apenas um detalhe, o projeto deles era um front específico 😂
O maior problema é quando o dev tenta explicar para o cliente que a aplicação dele seria melhor se fosse escalável 😂
E o cliente no final das contas só tá ligando para "Tá funcionando? Então tanto faz"
deixei e usar muitos aplicativos por causa de travamento e bugs
@@saitamablz1512mas travamentos e bugs é diferente de ser ser escalável, pode ser que não seja seja escalável mas ser rápido e sem bugs
@@saitamablz1512diz um exemplo
Sobre a parte de fila de processamento oque seria isso exatamente? Então se meu get ou post ir direto na minha base e fazer a consulta ou inser ta errado?
O ideal pro cenário que eu imagino que você está pensando é ter um load balancer intermediando essas requests. então teu post ia bater primeiro no load balancer e então no serviço que se comunicaria com o database, dessa forma cessando o problema q o lucas mencionou.
@@renejunior661 a po entendi, valeu
Não está errado, você pode continuar inserindo e consultando diretamente da rota sem problemas, mas ,como foi dito, isso não é escalável. O uso de uma fila de processamento vem pra suprir algumas necessidades, como diminuição do tempo de resposta para o usuário. Um banco não pode abrir infinitas conexões simultâneas, isso ocorre pq é muito custoso manter a consistência dos dados ( evitando condições de corrida, verificando constraints, etc), logo apenas um pequeno número de conexões são feitas ao banco por vez, onde, em muitos casos, se utiliza pools de conexão já que abrir conexão com o banco também é algo custoso.
Então o que acontece caso todas as conexões estejam ocupadas no momento da requisição? O usuário terá que esperar até alguma conexão dessa pool de conexões estar livre para que a modificações ocorresse e, enfim, retornasse uma resposta. Esse processo pode ser bastante demorado dependendo da quantidade de requisições feitas simultaneamente. É nesse caso que as filas entram, elas guardam as informações que causarão modificações no banco e , por, terem limite de conexão, devolvem rapidamente uma resposta ao usuário. Posteriormente, quando estiver com conexões livres, o banco pode utilizar essa informações para realmente alterar seu estado.
Acho que vc já deve imaginar que isso não se aplica a todo caso, já que existem situações onde é necessário uma resposta imediata por parte do banco (criação de uma conta, por exemplo). Apesar disso, em modificações não urgentes, como mudanças de preferências de perfil, essa estratégia deve funcionar muito bem.
@@edsonmartinelli Olá! Pode explicar um pouquinho melhor essa ideia de abstrair e reproduzir de forma virtual as modificações na Queue? A ideia é manter um state virtual pra ação? Se sim, como esse estado seria gerido e salvo no meio-tempo entre esse processamento e a persistencia final na database?
@@edsonmartinelli então o ideal seria usar um kafka ou RabbitMQ pra essas operações de alteração no banco?
INTERNACIONALIZAÇÃO, ufa
Para resolver problemas de escala, basta programar em Scala. 😆
É igual design pattern. Difícil mesmo é saber como, onde e quando aplicar
Muito engraçado o jeito que você fala "reAAAAct" hahahah muito bom!!!
11:06 é só pra "mim" trabalhar
O exemplo da classe boleto do nubank, concordo que nao precisa da factory só pra um banco mas não custa nada fazer um NubankBoleto e uma interface pro dia que mudar de banco.
Cara concordo, mas até que ponto conseguimos criar um boa abstração que será realmente util se não tivermos mt conhecimento do dominio?
Por exemplo hoje em dia existem boletos que retornam pix junto não só o codigo de barras, será q abstração q criamos anos atrás ainda é útil? Ou vamos ter que refatorar de qualquer modo?
Venho pensando nisso em extender o máximo o momento da criação da abstração.
@LucasMontano pq vc disse que não é mais senior??
@@RossoFala o Lucas falou que ele mesmo não é mais sênior. Eu não entendi isso, sacou?
tu da curso de programaçao ?
Scala escala?
Nem sou dev mas esse canal tá bem massa
Uma duvida de leigo (bota leigo nisso)
Um micros serviço pode ser compartilhado entre diferentes aplicações, tipo um sistema de gerenciamento de fezes, eu poderia usar na minha própria aplicação, como distribuir esse micro serviço para outra empresa cobrando uma taxa.
Já o monólito eu somente poderia usar esse serviço na minha própria aplicação pelo fato de ele ta acoplado nela ou pelo menos seria muito complicado de reutilizar ela em outras aplicações.
Esse meu raciocínio ta errado?
o que seria internacionalização?
Isso tem uma escada?
Como poderia dizer o mano Deyvin, em algum momento "escalabilidade" foi "pirâmide". Lembro de uma época em que pra qualquer MVP e afins essa perguntava era levantada.
Muitas coisas se resolvem tendo noção de big o e assíncronia.
Divida tecnica e quando vc financia um carro e depois de uma semana e demitido. Essa e a unica divida tecnica que importa.
Exatamente, tanta coisa mais importante para colocar na aplicação 🤦♂
Cara o que mais tem é Dev querendo papagaiar que tem que que usar kubernetes, com configuração para subir até 10 pods no pico pq pode acontecer de ter 100K usuários no mesmo segundo e bla bla bla bla bla, e o aplicativo nem ao menos está lançado. NÃO TEM ABSOLUTAMENTE NINGUÉM USANDO, então primeiro lança a parada e coloca o monitoramento e vai vendo como anda no dia a dia, a partir do momento que ver que tá começando a dar perdas aí sim tem um problema pra resolver.
parecia que o sr estava chapadao nesse video com tantos cortes
Nunca ouvi falar de código "escalavel" geralmente śo infra mesmo, acho que performatico é um termo um pouco melhor não?
Não necessariamente, porque é como o Lucas Montano mostrou no vídeo, a escalabilidade também depende de outros fatores que não estão relacionados à performance (por exemplo, desacoplamento de dependências e serviços de terceiros, facilidade de internacionalização e de edição do código no futuro).
A escalabilidade tá bem relacionada a poder crescer não só a base de usuários de um software com facilidade, mas também a poder adicionar novas funcionalidades ou mudar elementos da estrutura sem grandes problemas.
@deyvid322 É mais questão de terminologia mesmo, nunca me referi ou peguei a alguém se referindo a código como escalavel, código limpo, de qualidade, seguro, é o que escuto, escalavél é a solução como um todo, acho que um código legivel é a unica coisa que importa na hora de se adicionar mais código.
O Lucas comentou que nunca se conecta o banco de dados diretamente na API, mas durante os anos todos que eu trampei como dev vejo exatamente esse padrão, uma camada de repository conectada diretamente ao db kkkkk Será que eu entendi o "diretamente" errado? De que outra maneira o mercado faz essa conexão?
Ex: app Android conectado direto no firebase sem uma camada que você possa ter controle(repository)
Push -f pra main e se rodar o teste passou. Ingualzin os caras da crowdstrike kk
passei pela onda do microservices e não fui contaminado rsrs
Monolíto é tão bom de falar, que até o jeito certo 'monólito' parece errado.
eu sofro da sindrome do Overengineering
somos 2
Acho que é comum de isso acontecer, programadores acabam se empolgando quando aprendem coisas novas, então, acaba sendo meio que 8 ou 80 na hora de desenvolver. Pessoalmente tento aplicar o que aprendo, mas, sem exagerar demais na complexidade, até porque, excesso de recursividade vai fazer com que eu mesmo tenha dificuldade em ler meu código daqui algum tempo, por isso, acho que nessas horas o K.I.S.S. (Keep It Simple, Stupid) é uma boa prática à ser seguida pra mensurar a complexidade.
@@gabrielrissi6583 a minha solução é fazer documentação , antes de querer fazer codigo , escreve a ideia no papel , depois de um tempo revisa , ai vc vai poder perceber se a ideia é boa ou não
Somos 3
Me deu taquicardia ao assistir esse vídeo
Aprendi uma palavra nova: internacionalização 😅
irmão você esta a cara do jimmy neutron.
estou justamente nesse momento da vida kkkkk
Ctx oto = event.getCtx();
switch(teste){
case "a":
oto.blabla
case "b":
oto.blabla
case "c":
//não precisa de oto
}
Man, isso é escalavel é performático? não é melhor fazer
switch(teste){
case "a":
Ctx oto = event.getCtx();
case "b":
Ctx oto = event.getCtx();
case "c"
}
Porque ai voce não precisa criar a variavel oto e pegar o contexto toda vez no switch, porque algumas vezes não precisa tipo no caso c
man, nao é melhor colocar um final ai no parametro do método porque ele não muda de valor e não é mior a gente usar os null mesmo Optional aqui pode da atraso e não é melhor nós implementamos isso só usando static porque fica instanciando objetos pode demorar o método é chamado 20 vezes por segundo.
Uai, lucas montando virou staff?
Amante de Monolito aqui!!
Top vídeo
Não o problema eh resolver problema de software com soluções de infra. Quer escalar use uma linguagem q tem um bom suporte pra isso como elixir ^^
Eu tenho um monolito com DB direto na API atendendo de dezenas a centenas de requisições por segundo. Tá errado? Tá. Vou refatorar? Só se for pra implementar IA. Kkkk
Depende hahahahah. Na realidade se algumas requisições como alterar um dado da conta não precise ser feita de imediato, da pra jogar pra uma fila de processamento. Depende se tu precisa da resposta imediata.
A fila de processamento funciona tipo: “to fazendo umas coisas aqui , assim que eu terminar eu resolvo”
Mano, o vídeo está dando leg quando vc digita "internacionalização". 😆
Fico perdidinho nesses videos, queria entender mais do pensamento que está por trás de system design
No caso seria “Pare”
Na minha opinião a arquitetura da solução em si deveria ser algo desde o dia 0. Eu já vi muita conversa: De começo vamos criar um monolito depois conforme necessidade a gente ajusta arquitetura... Ou até mesmo a implementação de uma pdrão de projeto: Vamos implementar esse aqui depois a gente muda caso precise... Ai o cara nunca refatora porque envolve testes regressivos e fere o O do SOLID
Doce ilusão
Clean Architecture e Hexagonal em um projeto CRUD também é um over engineered.
Clean architecture e hexagonal são over engineering
Se o projeto não precisar ser mantido por um longo período de tempo (por exemplo, um MVP) ou um projeto que vai ficar rodando e nunca mais será mexido, ai realmente a Arquitetura Limpa pode ser um exagero. Todavia, mesmo em projetos simples, alguns conceitos da Arquitetura Limpa aliados ao SOLID podem sim gerar um código muito mais fácil de ser mantido ao longo do tempo e de escalar, então, acho que "depende" do objetivo do que está se desenvolvendo. Agora, também não adianta o cara aplicar Arquitetura Limpa em um código extremamente "sujo", por isso, mais do que se preocupar com qual arquitetura seguir, o ideal é primeiro se preocupar em aplicar boas práticas pra tornar o código mais simples e legível.
porque vc nao faz assim? kkkkkk isso e mt true
Ótimo vídeo! #chorume!
The name? Is Lucas Montano!
Tem pleno que acredita que algo "escalável" é você rodar 20 mil request por segundo em um servidor com 1gb de memoria ram kkkkkkkk
Internalização
Tudo depende como o cara fez a aplicação.. kkkkkk tenho certeza que na empresa que trabalho, a 15 anos atras, as pessoas fizeram a pergunta "-isso é escalavel?" e a resposta foi nao.... Resolveram fazer uma tipagem por ID de produto... produtos abaixo do id 1000000, sao produtos normais, acima, produtos de assistencia.... E adivinha!!!! kkkkkk logo logo vai estourar o 100000 e nao sabem o que fazer agora pelo tamannnho da empresa.
Interna sim, interna
Mandou a pio....
Meu código escala, é um projeto scala 😂
Over o ver
Perfeito para o meu momento de vida 😂😂😂😅😅
Internacionalização.
😂😂😂😂😂
Internacionalização
top
cade a chloe🐶🐶🐶🐕
Inter inter inter internacional 🇵🇱 i18n
Nunca mais vou esquecer a palavra "internacionalização" na minha vida.
Quando eu fui aprender a fazer edição de vídeo, eu colocava um transição diferente fodona em cada corte kkkk
Empolgação existe, é um monstro que pode consumir nossa alma, cuidado.
Hoje sempre faço a pergunta: é realmente necessário ou tem algo de menor complexidade que faz a mesma coisa e vou poder jogar meus games no final de semana?
Mas tem um ponto muito importante que é custo! monolito escala, escala, mas é barato escalar? definitivamente não! pense numa maquina que roda um serviço todo e o que pesa é o faturamento. Já tive esta experiencia... uma maquina que custava $1000 / mes, passamos a pagar $40/ mes por separar em microservicos... Não necessáriamente precisa ser microservico, mas um serviço separado por escopo, é essencial pensar já desde o começo, vc nunca tera o custo de $1000 já de paulada. E pense o tempo que os donos se deram conta que tavam tendo prejuizo por conta da escolha que fizeram... Foram milhares de dolares jogados no lixo, pq ignoraram essa pergunta.
concordo e entendo o ponto, mas muitas vezes ao migrar para micro serviços acabamos otimizando partes do sistema que estavam sendo negligenciadas… por isso fico sempre meio cético, eh difícil e trabalhoso de fato medir e comparar.
o que é um monólito? ele escala?
ChatGPT:
Um monólito é um tipo de arquitetura de software onde toda a aplicação é construída como um único, indivisível bloco. Em contraste com arquiteturas mais modernas como microserviços, onde uma aplicação é dividida em várias partes independentes, um monólito é uma única aplicação que pode ser subdividida internamente em diferentes módulos ou componentes, mas que é implantada e executada como uma unidade única.
Características de um Monólito
Código Único e Coeso:
Todo o código-fonte está em um único repositório e é construído e implantado como uma unidade.
Escalabilidade:
Escalabilidade Vertical: Em um monólito, a escalabilidade geralmente é feita adicionando mais recursos ao servidor (mais CPU, memória, etc.), o que é conhecido como escalabilidade vertical. Isso pode ser limitado pela capacidade do hardware disponível.
Escalabilidade Horizontal: Embora seja possível escalar horizontalmente (adicionando mais instâncias da aplicação), isso pode ser mais complexo, pois todas as instâncias precisam compartilhar o mesmo código e, frequentemente, o mesmo banco de dados.
Desenvolvimento e Implantação:
Desenvolvimento Unificado: Todos os desenvolvedores trabalham no mesmo código-fonte e fazem modificações que afetam toda a aplicação.
Implantação Simples: A aplicação é implantada como um único artefato, o que pode simplificar o processo de implantação e gerenciamento.
Acoplamento:
Acoplamento Interno: Os diferentes módulos ou componentes dentro do monólito são fortemente acoplados, o que pode tornar a modificação de um módulo impactante para outros módulos.
Manutenção e Evolução:
Manutenção Complexa: À medida que a aplicação cresce, a manutenção pode se tornar complexa e mais difícil devido à interdependência dos módulos.
Evolução e Atualizações: Mudanças em uma parte da aplicação podem exigir que a aplicação inteira seja recompilada e implantada, o que pode aumentar o risco de problemas.
Escalabilidade de um Monólito
Escalabilidade Vertical:
Prós: Mais simples de implementar inicialmente e pode ser suficiente para muitos casos de uso.
Contras: Limitado pela capacidade do hardware e custos crescentes com a necessidade de servidores mais potentes.
Escalabilidade Horizontal:
Prós: Possível adicionar mais servidores para distribuir a carga.
Contras: Pode ser complexo devido à necessidade de sincronização entre instâncias e gerenciamento de estado.
Comparação com Microserviços
Microserviços: Em uma arquitetura de microserviços, a aplicação é dividida em serviços pequenos e independentes que podem ser desenvolvidos, implantados e escalados de forma independente. Isso oferece maior flexibilidade e pode facilitar a escalabilidade horizontal, mas também introduz complexidade adicional no gerenciamento e comunicação entre serviços.
Resumo
Monólito: Uma aplicação única e coesa que pode ser escalada verticalmente e horizontalmente, mas pode enfrentar desafios de escalabilidade à medida que cresce.
Escalabilidade Vertical: Adicionando mais recursos ao servidor.
Escalabilidade Horizontal: Adicionando mais instâncias, mas pode ser mais complexo devido ao acoplamento e gerenciamento.
Se você está construindo uma nova aplicação ou considerando a evolução de uma existente, é importante considerar as necessidades específicas de escalabilidade e manutenção ao escolher a arquitetura mais apropriada. Se precisar de mais detalhes ou tiver outras perguntas, estou à disposição!