8
respostas

[Projeto] Projeto Pessoal - r-Beauty (Full Stack)

Salve pessoal!

Há muito tempo queria tirar este projeto do papel, e finalmente consegui!

Minha esposa é consultora de beleza e trabalha com a revenda de produtos de marcas como Boticário, Eudora, Avon e Natura desde que fez sua transição de carreira da confeitaria. Com o crescimento da consultoria, ela começou a ter dificuldades para controlar vendas, lucros e estoque. Foi aí que desenvolvi a primeira versão do r-Beauty usando Google App Script, HTML e CSS, integrando tudo ao Google Sheets, o que aumentou muito sua produtividade.

Agora, com a demanda ainda maior, a versão inicial já não atende suas novas necessidades. Por isso, comecei a trabalhar na versão 2.0 do r-Beauty. Nos ultimos dias estive fazendo o levantamento dos recursos necessários e iniciei o desenvolvimento.

Nesta nova versão, estou utilizando React.js pela sua eficiência na criação de interfaces dinâmicas e escaláveis, TypeScript para garantir maior segurança e qualidade no código, e SCSS para organizar melhor o CSS e tornar o design mais modular. Neste momento, estou focado nas funções de login, cadastro de usuários, marcas e produtos.

Quanto ao BackEnd, planejo utilizar Typescript pelas mesmas razões, estou decidindo entre MongoDB e Firebase para minha base de dados e Jest para garantir uma cobertura de testes dentro do projeto.

Caso tenham interesse, deixarei o abaixo. Fico à disposição para qualquer feedback ou sugestão sobre o projeto.

Repositório: https://github.com/DanielEmidio1988/r-beauty-web

Grande abraço!

8 respostas

Olá Daniel. Tudo bem?

Obrigado por compartilhar seu projeto aqui com a gente. O desenvolvimento do r-Beauty para auxiliar sua esposa é uma excelente oportunidade para praticar suas habilidades em tecnologia e ainda resolver uma necessidade real.

Sobre a escolha de tecnologias, React.js, TypeScript e SCSS são ótimas ferramentas para garantir um frontend dinâmico e modular. Faz muito sentido.

Eu baixei e testei ele aqui e funcionou certinho! Parabéns pelo trabalho. Continue assim com essa dedicação.

Conte com o apoio do Fórum e bons estudos.

Olá Renan! Tudo bem e você?

Muito obrigado pelo feedback. Atualmente estou quase finalizando a primeira etapa do projeto, onde quero aplicar uma funcionalidade minima para os processos de login/cadastro de usuários, cadastro de marcas e produtos para que seja possível já ter uma noção mais clara de como o projeto funcionará.

Para o BackEnd, vou construir um BackEnd chamado CommerceFlow, que será uma API que poderá ser utilizada em aplicações de fluxo comercial. Penso em utilizar NodeJs, ExpressJs, Typescript, Jest e estou na dúvida entre utilizar MongoDB ou Firebase. Você tem alguma sugestão sobre a Base de Dados?

Grande abraço!

Olá Daniel.

Tanto o MongoDB quanto o Firebase são boas opções, mas cada um tem suas particularidades:

  • MongoDB é uma excelente escolha se você precisa de um banco de dados NoSQL flexível, que se adapta bem a dados sem estrutura definida e é ótimo para aplicações que têm alta demanda de leitura e escrita. Combinado ao Mongoose, você consegue ter um controle bacana sobre os dados e até mesmo definir esquemas para validação e organização.

  • Firebase oferece muito mais do que só um banco de dados. Ele é ótimo para quem quer uma solução completa, já que inclui autenticação, hosting e uma série de outros recursos. O Firestore (o banco de dados da Firebase) também é NoSQL, mas ele tem uma integração muito forte com o Google Cloud e pode ser útil se você quer crescer a aplicação com facilidade, sem se preocupar muito com a infraestrutura.

Se você está buscando maior flexibilidade e controle sobre o banco, eu recomendaria MongoDB. Agora, se a ideia é ter um backend mais simples de gerenciar, com menos preocupação com a infraestrutura, o Firebase pode ser a melhor escolha.

No fim, acho que vai depender do que você visualiza para o crescimento do r-Beauty e do CommerceFlow. Se você está mais inclinado a usar um banco de dados que ofereça escalabilidade automática e um ecossistema robusto, Firebase pode facilitar. Mas se você quer algo mais personalizável e que se encaixe em um ambiente tradicional de backend, MongoDB é uma excelente opção.

Espero ter ajudado. Qualquer dúvida manda aqui.

Abraço.

Bacana Renan,

Sua explicação deixa muito claro a diferença entre ambas as soluções e até mesmo acrescentou uma visão mais ampla sobre o Firebase que eu não levei em consideração. Essa análise sera fundamental na escolha entre as tecnologias na hora de montar o CommerceFlow.

Ajudou pra caramba.

Grande abraço!

Salve pessoal,

Na semana passada, compartilhei com vocês o início da nova versão do r-Beauty, um projeto pessoal que desenvolvi para ajudar minha esposa, que trabalha como revendedora de produtos de beleza como O Boticário, Natura, Eudora e Avon. Ela precisava de uma solução prática para gerenciar suas vendas, e é aí que entra o r-Beauty.

Nesta semana, dei mais alguns passos importantes. Já comecei a trabalhar nas páginas que o revendedor usará no dia a dia, como o area administrativa, cadastro de marcas e produtos, além da homepage e página de cadastro e login. Embora o foco ainda não seja a estilização, implementei um layout básico para manter tudo no lugar certo enquanto trabalho nas funcionalidades.

Uma coisa que tem me surpreendido ao longo desse processo é quantas vezes precisei mudar de ideia sobre como aplicar algumas funções. São vários detalhes que me fazem repensar as escolhas que fiz inicialmente, mas estou gostando bastante desse desafio. Cada mudança me faz evoluir no projeto, e mal posso esperar para ver o resultado final!

Para quem quiser acompanhar mais de perto ou dar sugestões, deixo o link do repositório e do deploy abaixo. Toda crítica ou sugestão é sempre bem-vinda.

Repositório: https://github.com/DanielEmidio1988/r-beauty-web Deploy: https://r-beauty-web.vercel.app/

Grande abraço!

Opa, Daneil.

Esses dois links que você compartilhou estão quebrados, porém consegui ver o seu projeto no link da resposta anterior.

Fico muito feliz em ver a evolução do seu projeto, realmente está avançando muito bem! A implementação de tela de login, gráficos, checklist para marcar os produtos e o cadastro de produtos com React e SCSS mostra um salto desde a última vez que o vi.

Isso não só melhora a usabilidade do sistema, mas também reflete o quanto você tem se dedicado. Continue com essa dedicação.

Estou à disposição para ajudar se surgir qualquer dúvida ou para oferecer mais feedback à medida que avança.

Parabéns pelo ótimo trabalho e pela dedicação!

Abraços!

Opa, Renan! Tudo bem?

Tem razão, acabei de corrigir os links na postagem anterior.

Muito obrigado pelo feedback. Uma das coisas que tenho pensado bastante é do módulo de cadastro, a principio minha ideia era utilizar um unico componente para o cadastro de marcas, produtos, etc e eu enviava um array de objetos com a estrutura de como os dados seriam montados na página. Contudo, as páginas de cadastro possuem algumas particularidades entre elas, por exemplo, o cadastro de Marcas é bem simples, pois básicamente eu apenas informo o nome da marca e o percentual de desconto.

Já no cadastro de produtos, eu tenho outra estrutura de informações, mas o principal é algumas das funcionalidades. Por exemplo, cada produto precisa ter uma marca cadastrada. No momento em que o usuário começar a preencher o nome da Marca, aparece uma listagem de marcas cadastradas com nome aproximado do que o usuário está cadastrando, caso não tenha a marca com o nome citado, é acionado uma função que cadastra essa nova marca (algo semelhante ao Wordpress quando você cria um post para o Blog e informa a categoria). Além é claro que, assim que é escolhido a marca, e o usuário informa o preço de custo, a aplicação irá sugerir um preço de venda com base nessas informações.

Dito isso, é normal que muitas aplicações grandes possuam esses componentes de cadastro individualizados ou o melhor caminho é centralizar tudo em um unico componente? Até pensei em algumas formas para centralizar, mas todas tornariam o componente muito complexo e ruim de manter a manutenção.

Grande abraço!

Opa, Daniel!

Centralizar tudo em um único componente pode não ser viável nesse caso, pode acabar ficando complexo e difícil de manter, especialmente com as diferenças entre os cadastros. O ideal é separar os componentes para cada tipo de cadastro, reutilizando apenas o que for comum, como inputs e validações. Isso deixa o código mais organizado e fácil de evoluir.

Abraço! Bons estudos.