Construiu uma ferramenta de automação do LinkedIn e sobreviveu 206 cometidos posteriormente 🫠

Yo Devs! 👋 Então, acabamos de lançar nosso primeiro produto (Post0 – uma ferramenta de automação do LinkedIn) e, honestamente, a jornada técnica foi absolutamente selvagem. Pensei em compartilhar como passamos de “Vamos construir um aplicativo simples” para criar acidentalmente um pesadelo distribuído que, de alguma forma, realmente funciona agora, o começo “simples” começou com o que todo aluno faz – um bom monólito velho. Um repositório, uma implantação, uma enorme dor de cabeça esperando para acontecer. Nós éramos jovens, ingênuos e pensamos que “os microsserviços são apenas super-engenharia corporativa” 🤡 Post0-app/ ├── Frontend/ ├── back-end/ ├── Trabalhadores/ └── Banco de dados/ Digite o modo de saída da tela cheia parecia simples o suficiente? ERRADO. Quando tudo passou por cerca de 3 meses, nosso CI/CD começou a levar mais de 20 minutos. As implantações estavam quebrando constantemente. Um bug na lógica de postagem derrubaria todo o front -end. Problemas clássicos de monólito nos atingindo como um caminhão. O ponto de ruptura foi quando empurrei uma “pequena correção” para o serviço de postagem e acidentalmente quebrei a autenticação do usuário por 2 horas 💀 A grande migração (também conhecida como microsserviços completa) disse que o F*ck e decidi dividir tudo: o serviço de postagem do dianteiro e o serviço de postagem do dia. que parece decente PRISMA-Service (13 Compromits)-Esquemas de banco de dados compartilhados acionados por eventos com o modelo de sub-sub-sub-sub: // Quando o usuário agenda um post aguardo pubsub.publish (‘post.scheduled’, {userId, pós-conteúdo, agendado, plataforma: ‘linkedin’}); // Serviço de postagem pega o pubsub.subscribe (‘post.scheduled’, assíncrono (dados) => {Aguarda schedulelinkedInpost (data); aguarda pubsub.publish (‘post.status.updated’, {…});}); Digite o modo de saída do modo de tela cheia de tela cheia Os pontos problemáticos (também conhecidos onde choramos) PRISMA Schema Syncing Nightmare Compartilhar esquemas de prisma entre serviços é … interessante. Tentamos: Pacotes Git Submódicos (Hell Não) NPM (versão Hell) Monorepo (Voltar onde começamos?) Acabou com um repo separado do Prisma-Service que publica atualizações de esquema. Não é perfeito, mas funciona. vercel + github orgs = 💸 vercel não implanta repositões de org em camada gratuita. Tive que configurar as ações do GitHub para construir e implantar: Nome: Implante Frontend On: Push: Branches: [main]
Trabalhos: Implantação: Runs-On: Ubuntu-Lates Etapas:-Usos: Ações/Checkout@V2-Nome: Implante para VERCEL Usos: AMONDNET/Vercel-ACTION@V20 com: vercel-token: $ {{Secrets.vercel_token}} vercel-org-id: $ {{Secrets.org_token}} vercel-org-} chaos deploying 4 separate services to azure container instances while maintaining secrets, environment variables, and not going broke as students = pure chaos what we learned (the hard way) start simple, split when it hurts – monolith wasn’t wrong initially, we just grew out of it event-driven architecture is beautiful but debugging async flows at 3am is not shared schemas are hard – there’s no perfect solution, pick your poison free tiers have Limites, mas as ações do GitHub + alguma criatividade vai muito longe – 162 COMPRIMENTOS NO FRONTEND REPO salvaram nossa bunda várias vezes status atual: de alguma forma funcionando ✨ Todos os serviços implantados no Frontend do Azure na Vercel (por meio de nosso CI/CD Hack) Eventos de subestimados para o Publicação para o Postagens do Linkedin, sem que tudo explodisse a conversa real foi sobre o projeto de subestimados para um projeto para o aluno que o LinkedIn Postin sem explodir a verdadeira palestra foi exagerada para um projeto de subestimado? provavelmente. Aprendemos muito sobre sistemas distribuídos, arquitetura orientada a eventos e investimento? Absolutamente. Faria isso de novo? Honestamente … sim, mas com melhor planejamento 😅 Se você está construindo algo semelhante, meu conselho: comece com o monólito, divida quando sentir a dor e não tenha medo de cometer erros. É literalmente assim que você aprende essas coisas. De qualquer forma, estamos ao vivo em busca de produtos hoje se você quiser verificar o que saiu deste belo desastre: https://dev.to/mdkaifansari04/how-two-students-built-a-linkedin-automation-tool-and-survived-206-commits-later-384g

Qual é a sua maior arquitetura falha? Solte -o nos comentários, vamos sofrer juntos 🫡 pilha de tecnologia para os curiosos: next.js + datilografript (frontend) node.js + express (serviços) prisma + pós -fgressql azure pub/sub – + instâncias de contêiner são também uma ação do Github (CI/CD), que hospeda minha hospedagem: Ps: Vamos chorar juntos 😭

Fonte