Queria uma opinião sincera e pessoal sobre a stack... #1643
Replies: 10 comments
-
|
Antes de entrar nos detalhes é bom pensar no que te deixa confortável. Poderemos te indicar várias stacks possíveis, mas, vamos supor que na stack atual, vc está mais confortável. Dependendo da sua curva de aprendizagem, você pode acabar se complicando. No meu caso, sinto-me bem com o PHP. Iria sugerir um framework (ou micro framework) para adiantar algumas coisas básicas.
Acho muito válido, documentar as regras e coisas afins no seu projeto, já que vc tem um tempo. Há varias possibilidades. Tenho um pequeno conhecimento nelas, por isso, vou deixar o pessoal discorrer sobre assunto para podermos debater mais |
Beta Was this translation helpful? Give feedback.
-
|
Cuidado com stack otimizado de mais para sua demanda, entenda o limite máximo de acesso. Quando construímos um projeto imaginamos pegar o melhor stack para atingir milhões de usuários sem necessidade, a medida que a empresa cresce o software pode ser aprimorado ou refatorado para ter mais acessos afinal as empresas também começam a faturar mais. Dois fatores são diferenciais nessa decisão qual sua demanda máxima atual para atingir o objetivo de vocês no momento, esquece longo prazo. Tenha em mente manter tudo estupidamente simples até que seja realmente necessário. Como decido meus stacks? Estudo a necessidade atual vs necessidade de curto e médio prazo. Muita leitura dos pros e contras das alternativas e Sugestão sobre seu projeto, eu iria de Laravel, pois ele atende a uma quantidade legal de Request Per Second (RPS), fácil de modelar e programar, tem uma quantidade interessante de plugin, suporte, documentação etc. E quando sua aplicação crescer, você migra ou para SSG (no Laravel não tem uma framework tão interessante, quanto Gatsby) ou migra para Swoole (muito ganho de RPS mantendo todo código) Recomendação de Benchmark: Recomendação de pros e contras: |
Beta Was this translation helpful? Give feedback.
-
|
Valeu @MatheusRV e @HmmerHead! Show, na vdd já tenho uma idéia bem sólida de stack e acredito que vou seguir na direção do fullstack js meio que usando MERN, node + mongo + mongo + typescript no backend, reactjs com next fazendo o SSR, e assim que a parte web ok vou partir para o mobile com react native. Ao menos de início pretendo seguir assim. Vocês citaram tecnologias mais para o lado do PHP, além da afinidade com PHP, claro, teve mais algum ponto que pesou também nesta opção de php sobre node ou .net? (Eu comecei minha careira com PHP, passei por Laravel, Phalcon, puro, com redbean, com twig, gostei demais, atualmente na empresa atual o foco é em .Net framework e Core + ReactJS no front, meu foco principal também é .Net Core, mas to introduzindo alguns projetos com Node lá na empresa, pois muita api pequena e projetos menores com node tem uma produtividade extraordinária, mas lá é 80% C# com .Net Framework e Core, por isso este projeto que é meu, e além de um empreendimento, quero intensificar meu contato com o node e a stack js geral, para conseguir realmente ver os prós e contras de cada uma.) Veem algum ponto contra o node e a stack full js neste contexto frente as stacks apresentadas? Quero ganhar bastante R$ com o projeto rs Mas também pretendo usar ele como sandbox, muita coisa que não posso ver em produção na empresa atual por questões de segurança, em algo meu posso colocar para rodar e ver os prós e contras tranquilo, se der ruim só voltar, só refatorar e tal rs Mas também vou usar as respostas aqui como uma pesquisa de mercado para ver o que está mais em alta, o que vocês mais usariam e tal, para ver como está o mercado mesmo. Abraços! |
Beta Was this translation helpful? Give feedback.
-
|
Fala mano! Otimas perguntas. Eu estou empreendendo também (há 3 anos já), vou compartilhar um pouco dos meus aprendizados. Nossa stack é bem dividida, temos um front em Vue com Nuxt.js, um back-end com Node.js, GraphQL e MongoDB e alguns serviços que utilizam ELK e coisas do gênero. No nosso caso, já começamos a startup com 2 devs, um back e um front. Então ter essa divisão logo no começo foi bom, pois dessa forma os dois trabalhariam independentemente. No seu caso, eu não acho essa uma estratégia boa no começo. Daí você pode falar: "Beleza, mas eu vou crescer algum dia". Sim, você vai. Algum dia... Eu recomendaria uma plataforma que fosse fullstack e que você realmente domine. Algo como Laravel, Rails, Django ou no meu caso, Nuxt.js mesmo. O mais importante nesse seu tamanho, é o seu crescimento do produto. Ou seja, mais gente utilizando, mais vendas sendo efetuadas. A qualidade do código é legal, mas não da dinheiro. Os problemas dos seus usuários são outros que performance (a não ser que seu site seja uma completa bosta em performance, o que eu já vi que não é). Como dev, a gente fica muito apegado a stack, mas isso é pouco relevante em um produto. Conforme o produto cresce, aí sim precisamos nos preocupar com isso, para que isso não impeça nosso crescimento acelerado. Honestamente, eu só reescreveria seu projeto se ele estivesse em uma situação que é tão difícil dar manutenção que não vale a pena continuar crescendo aquilo. Espera o produto continuar dando mais grana e você ficar 100% focado nele para que você contrate pessoas que vão te ajudar a crescer essa base de código e uma hora você faz a troca (quando de fato ficar ruim de dar manutenção). Se o momento já for esse, tudo bem também. Mas pensa em crescer o número de acesso e etc... |
Beta Was this translation helpful? Give feedback.
-
|
Show @kavalcante! Muito obrigado por todo o conhecimento compartilhado e dicas, tenho essa impressão as vezes, fico empolgado com a stack e em features mais pela tecnologia ou desenvolvimento envolvido do que por resultado ou UX do usuário de vdd rs. É que este é bem o mvp mesmo, fiz o mínimo tanto em layout quanto em código, atropelei muitas regras de boa arquitetura e padrões para soltar e testar o produto logo, foi legal, teve aceitação e rodou. Mas agora ele vai evoluir bem em questão de features novas e até em como vai ser o fluxo, acredito que a base de códigos vai aumentar muito, apesar de ainda não ser um peso a manutenção, assim que tiver masi features e uma base maior vai ser rs VOu refatorar já pensando na escala tanto de produto, código quanto base de usuários. Um exemplo é a área de usuários q será praticamente uma nova, painel para organizadores que ainda não temvai ter, fora o front que será todo reescrito, mas isso é idéia para colocar tudo para rodar ainda este ano, tenho um roadmap das features e do que preciso para virar e depois vou incrementando mais... Enfim, é que vai ser tanta coisa nova que o que tem hoje acho que corresponde a quase que 10% do produto final, então acho que o melhor caminho é reestruturar agora... O backend que citou de sua stack é o caminho que vou acredito, só no front que vai ser um pouco diferente mas no mesmo conceito da sua, vou de reactjs + next, a dúvida ainda está entre rest ou graphql, acho q vou começar com rest e logo mais pegar uma base melhor no graphql. Não conhecia ELK, já vi bastante o elastic search não esse conjunto formando o ELK, estou lendo sobre aqui, me pareceu bem interessante. Sobre seguir nesta stack com node e mongo do back, alguma dica para quem vai começar agora? Bom, muito obrigado pela ajuda até aqui, abraço! |
Beta Was this translation helpful? Give feedback.
-
|
@wilsonneto-dev cara, sobre banco de dados. Nós escolhemos mongo pq é um banco que trabalha como se fosse com objetos JSON (de forma bem simplista, claro). Como nossa stack é 100% javascript, funcionou bem pra gente. Hoje tem coisas que a gente fez errado no mongo (como ficar fazendo muito join de collections) e o graphQL na verdade serviu como muleta pra isso, mas erros acontece e esse erro não é um problema tão grande ainda. O ponto é, na real tanto faz qual banco você vai utilizar. Se preocupa com o custo que tu vai ter e a facilidade de crescimento conforme seu produto evolui. Hoje nossos custos de banco são bem elevados por conta de ser mongo. Mas pra gente ainda faz sentido usar ele. Nosso custo pra mudar pra MySQL seria ainda maior que o custo que pagamos pelo mongo. Pode ser que um dia não seja, ai a gente vai lá e troca de banco.... Uma recomendação honesta, seria utilizar algo como o Now.sh, nós só não utilizamos pq temos algumas melhorias que estamos fazendo que nos forçaram a usar EKS (nós temos clientes enterprise e segurança está na nossa prioridade, no momento). Faz seus custos serem os menores e o seu deploy ser o mais simples possível. Então, usa Now.sh ou Heroku. Com um deploy automatizado em uma ferramenta (tem muita que é gratuita ou muito barata, da pra usar até Github Actions). Escolhe um banco que seja online, um provedor, tipo Compose.io, Cloud Atlas (se for mongo), ScaleGrid (estamos migrando para ele), mLab ou outro qualquer. Alguns desses aí tem até planos gratuitos. E foca em desenvolver suas features e fazer seu produto crescer e sua base de usuários também crescer. Sobre Elasticsearch, utilizamos ele bastante e vamos utilizar ainda mais em 2020, pois vamos migrar nossas buscas 100% pra ele (antes utilizavamos em uma parte da aplicação somente). Ele é bem legal, mas relativamente caro. Se você ainda não tiver tanta grana pra gastar com infraestrutura e tal, faz do jeito simples e tu melhora depois. Reconstruir coisas não é algo ruim se te ajudou a economizar no momento certo. |
Beta Was this translation helpful? Give feedback.
-
|
show @kavalcante , muito obrigado pelas indicações e dicas, acho que vai ser isso mesmo. Uma última dúvida que gostaria de opinião também, penso em talvez, no lugar de contratar o mongo em um DBaaS, fazer toda esta parte em containers e subir na mesma vps, assim centralizar o investimento na vps para ser mais potente. Tem alguma observação quanto a colocar a base, o sistema e os demais serviços como redis em containers na mesma VPS? Abraço! |
Beta Was this translation helpful? Give feedback.
-
|
@wilsonneto-dev cara, particularmente não sou fã dessa abordagem. Prefiro que a escala seja feita em máquinas diferentes e conforme a necessidade. Além disso, na nossa equipe nós só temos uma pessoa mais focada em devops agora. Então pra gente foi muito importante que tudo fosse feito de forma mais automatizada possível. Caso você domine isso, não vejo problema também pra esse primeiro momento. Mas pra gente, essa tática não era a melhor. |
Beta Was this translation helpful? Give feedback.
-
|
Entendi, show @kavalcante , muito obrigado por todo conhecimento compartilhado e pelas dicas! |
Beta Was this translation helpful? Give feedback.
-
|
Que bom que te ajudei de alguma forma! Abraços e boa sorte! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Fala galera,
gosto de ver a opinião de outros devs, principalmente por aqui que vejo que tem uma galera muito experiênte...
Fizemos um MVP, o site http://zedoingresso.com.br/, e a aceitação foi legal até aqui, agora é hora ed reescrever o projeto mas agora "pra valer", o mvp foi feito como dava na correria rs (a stack usada foi PHP/LAMP + twig de template engine, mas posso continuar com esta stack, ou posso não continuar também rs)
Mas o que mais quero aqui é a opinião sobre qual stack você optaria em usar, sei que quase tudo na tecnologia e até na vida, vai ter um "depende", mas pense aqui que este projeto é seu, o lucro vai ser seu, o custo e se for o caso o preju também rs e vc tem este poder de decisão seguindo as premisssas abaixo:
Neste projeto teremos apenas um dev (eu, mas imagine que seria você, apenas você), se escalar depois pode ser que tenhamos mais 1 ou 2, talvez freelas, enfim, por hora seria apenas um/vc.
Em dezembro tivemos 8,2 mil sessões com uma média de 4 páginas vistas por sessão, totalizando cerca de 33 mil pageviews, bem pouco ainda mas pretendo escalar com algumas novas parcerias e estratégias de marketings, uma stack que eu possa continuar até quando tiver dezenas de milhões de sessões por mẽs.
Não tem presssão aqui,legal seria entre 3 meses e 6 meses soltar a versão 2.0, mas como o projeto é meu/seu, a qualidade é o foco, o prazo é bem tranquilo.
O projeto atual está em uma hospedagem linux de R$ 15,90/mês e ninguém reclamou de performance rsrs Mas seria legal ser bem rápido, mas pelo que o mvp mostrou e rendeu, poderia investir até R$ 500,00 / U$ 100 por mês tranquilo com os números atuais, mas quanto menor melhor se não interferir na qualidade, escalabilidade nem UX...
O projeto será feito para ser escalável futuramente, seja em equipe, seja em base de usuários
Enfim, já tenho uma idéia quase que sólida da stack que farei, mas gostaria de opiniões para conhecer mais sobre a comunidade e o mercado... se fosse você qual você escolheria? O projeto é seu, todo o ônus e o bônus é seu? Qual vc optaria e pq?
Claro que existem várias variávei, depende de muita coisa e etc, mas gostaria de uma resposta citando as tecnologias mesmo.
Beta Was this translation helpful? Give feedback.
All reactions