Em 2019, concluí minha graduação em Engenharia de Software na UTFPR com um projeto que, olhando hoje, representa bem o tipo de problema que sempre gostei de resolver: pegar uma ideia, estruturar tecnicamente e construir o produto de ponta a ponta.
\nMeu Trabalho de Conclusão de Curso se chamava “Desenvolvimento de uma plataforma MEAN Stack de veiculação publicitária por geolocalização”.
\nO nome era acadêmico. A ideia era mais simples.
\nEu queria construir uma plataforma em que estabelecimentos pudessem publicar promoções e os usuários encontrassem ofertas próximas utilizando a própria localização.
\nO projeto ficou conhecido como Gastando Pouco.
\nA origem do projeto foi alguns anos antes, em uma competição de empreendedorismo: o Startup Weekend Londrina de 2016.
\nA proposta era aproximar estabelecimentos locais de consumidores que estivessem próximos.
\nImagine uma loja publicando uma promoção e, em vez de aquela informação simplesmente aparecer para qualquer pessoa na Internet, a localização do estabelecimento fazer parte da própria lógica da aplicação.
\nO usuário informaria — mediante autorização — sua localização. A plataforma teria latitude e longitude das empresas cadastradas e conseguiria responder algo próximo de:
\n“Quais estabelecimentos com promoções ativas existem perto de mim?”
\nEssa ideia acabou virando o escopo do meu TCC.
\nA aplicação foi dividida em três partes principais.
\nExistia uma aplicação administrativa para os estabelecimentos.
\nA empresa podia criar sua conta, cadastrar seus dados e localização, publicar promoções, editar publicações existentes e acompanhar informações relacionadas às ofertas.
\nNa prática, já existia ali um pequeno painel administrativo.
\nEu tinha páginas específicas para cadastro de promoções, listagem das publicações, edição, perfil da empresa e relatórios.
\nUma promoção possuía informações como período de validade, empresa responsável e categoria. O sistema precisava saber não apenas o que estava sendo anunciado, mas também onde aquela empresa estava localizada.
\nDo outro lado existia o site utilizado pelo consumidor.
\nAo entrar na aplicação, o usuário autorizava o acesso à sua localização. O frontend capturava latitude e longitude e enviava essas informações para a API junto com outros parâmetros da busca, como distância e categorias.
\nA partir disso, a aplicação apresentava as promoções disponíveis naquela região.
\nO usuário também podia visualizar uma empresa, consultar suas promoções, filtrar ofertas por categoria e salvar promoções como favoritas.
\nEra basicamente um feed de promoções baseado em localização.
\nUm dos objetivos técnicos do trabalho era justamente experimentar o uso de coordenadas geográficas em uma aplicação completa.
\nNão queria apenas pegar latitude e longitude no navegador e mostrar os números na tela.
\nA localização precisava participar da regra de negócio.
\nO frontend capturava a posição do usuário e enviava para o backend parâmetros como:
\nlatitude
longitude
distância
A API utilizava essas informações para consultar o MongoDB e descobrir quais empresas estavam dentro da região definida.
\nNo backend, a consulta utilizava recursos geoespaciais do próprio MongoDB, incluindo operações como $geoNear e $geoWithin.
Depois de localizar as empresas próximas, a aplicação relacionava cada estabelecimento às promoções cadastradas e considerava também o período de validade das ofertas.
\nIsso transformava latitude e longitude em algo útil para o produto.
\nNão era apenas:
\n\n\n“O usuário está nesta coordenada.”
\n
Era:
\n\n\n“Considerando esta coordenada e este raio, quais informações são relevantes para esse usuário?”
\n
Essa diferença era uma das principais provas de conceito que eu queria construir.
\nNa época escolhi trabalhar com a chamada MEAN Stack:
\nMongoDB + Express + Angular + Node.js.
\nUm dos objetivos do TCC era utilizar JavaScript/TypeScript ao longo de praticamente toda a aplicação.
\nNo frontend, Angular.
\nNo backend, Node.js com Express.
\nPara persistência, MongoDB.
\nPara comunicação entre as aplicações, uma API utilizando JSON.
\nTambém utilizei Firebase em partes da solução, incluindo autenticação, armazenamento de imagens e hospedagem das aplicações web.
\nO resultado era uma arquitetura com dois frontends independentes consumindo uma mesma aplicação de backend.
\nHoje isso parece uma divisão bastante natural, mas o objetivo naquele momento era justamente utilizar o projeto para estudar como essas tecnologias poderiam trabalhar juntas em uma aplicação real.
\nUma coisa interessante ao revisitar o projeto é perceber quanto trabalho de Engenharia de Software existia ao redor da implementação.
\nEu defini requisitos funcionais separadamente para empresa e cliente, requisitos não funcionais, arquitetura, modelo de dados, backlog e processo de desenvolvimento.
\nTambém adaptei o Scrum Solo para organizar o trabalho.
\nAs sprints tinham duração de sete dias e eu registrava a evolução do projeto a cada ciclo.
\nIsso provavelmente parece exagerado para um projeto desenvolvido por uma única pessoa.
\nMas esse também era o objetivo.
\nO TCC não era apenas entregar uma aplicação funcionando. Era aplicar, em um projeto relativamente completo, os conhecimentos adquiridos durante a graduação.
\nNo final, o projeto tinha um conjunto razoavelmente grande de funcionalidades para uma prova de conceito.
\nExistiam autenticação, cadastro de empresas, cadastro e edição de promoções, localização dos estabelecimentos, localização do usuário, busca por distância, categorias, favoritos, visualização das empresas, mapas, upload de imagens, frontend administrativo, frontend público e uma API responsável pelas regras de negócio.
\nEra um MVP.
\nInclusive, foi assim que defini o projeto nas considerações finais do TCC.
\nO objetivo nunca foi construir um marketplace completo.
\nNão existiam pagamentos dentro da plataforma e também não existia uma comunicação direta entre empresa e consumidor.
\nO foco era validar a arquitetura e principalmente a ideia de organizar promoções utilizando a localização como um dos principais parâmetros da busca.
\nSete anos é bastante tempo quando estamos falando de desenvolvimento de software.
\nAs versões das ferramentas mudaram. Algumas bibliotecas desapareceram. Outras abordagens de arquitetura se tornaram mais comuns.
\nEu certamente estruturaria várias partes desse código de outra forma hoje.
\nMas é exatamente isso que torna interessante manter projetos antigos disponíveis.
\nO repositório é praticamente uma fotografia de como eu pensava desenvolvimento de software naquele momento.
\nÉ possível encontrar decisões boas, decisões questionáveis, código que eu provavelmente não escreveria novamente e problemas que continuam bastante atuais.
\nAutenticação.
\nAPIs.
\nSeparação entre frontend e backend.
\nGeolocalização.
\nConsultas geoespaciais.
\nUpload de arquivos.
\nAutorização.
\nExperiência do usuário.
\nDeploy.
\nModelagem dos dados.
\nSão problemas que continuam aparecendo nos sistemas que construímos atualmente, mesmo que as ferramentas tenham mudado.
\nNo próprio TCC deixei uma seção de trabalhos futuros.
\nEntre as possibilidades estavam criar aplicativos para Android e iOS, permitir compartilhamento das promoções nas redes sociais, gerar códigos de desconto e enviar notificações push para pessoas próximas quando uma empresa publicasse uma nova promoção.
\nAlgumas dessas ideias hoje parecem bastante óbvias.
\nEm 2019, porém, elas representavam a continuação natural daquela prova de conceito.
\nEstou começando este blog e quero utilizar parte dele para registrar não apenas o que estou construindo atualmente, mas também alguns projetos que fizeram parte da minha trajetória.
\nNão pretendo atualizar o código do Gastando Pouco para fingir que ele foi escrito hoje.
\nA graça é justamente o contrário.
\nQuero preservar esses projetos como registros de uma época, explicar o problema que eu estava tentando resolver, as decisões que tomei e o que aprendi durante o processo.
\nEsse TCC foi um desses projetos.
\nFoi uma oportunidade de transformar uma ideia que surgiu em um Startup Weekend em uma aplicação funcional, passando por levantamento de requisitos, arquitetura, banco de dados, frontend, backend, deploy e documentação.
\nE também foi o projeto que encerrou uma etapa importante: minha graduação em Engenharia de Software.
\nPara quem quiser explorar o código, os diagramas, documentos e até diferentes versões do próprio TCC, o repositório continua disponível:
\ngithub.com/magnocarvalho/tcc
\nTalvez daqui a alguns anos seja interessante voltar novamente neste projeto e comparar não apenas as tecnologias, mas também como mudou minha forma de pensar software.
\n", "summary": "\"Como nasceu o Gastando Pouco, meu TCC de Engenharia de Software na UTFPR — uma plataforma MEAN Stack de promoções baseada em geolocalização.\"", "date_published": "2019-12-01T00:00:00-00:00", "image": "", "authors": [ { "name": "Magno Carvalho dos Santos", "url": "https://github.com/magnocarvalho", "avatar": "https://github.com/magnocarvalho.png" } ], "tags": [ "arquivo", "tcc", "utfpr", "geolocalizacao", "mongodb" ], "language": "en" } ] }