Como desenvolvi um planning poker com Laravel, Ably, InertiaJS, Tailwind e Vuejs.
naaando
/
planningpoker
Planning poker
Planning Poker
Overview
This is a Planning Poker project developed using Laravel as the backend framework, Vue.js for the frontend, Inertia.js for the middle layer, and Ably for real-time communication.
Usage
| Welcome | Playing |
|---|---|
 |
 |
Technologies Used
Requirements
- Docker
- Docker Compose
- Database (e.g., MySQL)
Installation
- Clone the repository:
git clone https://github.com/naaando/planningpoker.git
- Copy the environment file:
cp .env.example .env
- Configure the environment file:
Open the .env file at the root of the project and configure your environment variables, including the database configuration and Ably credentials.
- Start the project with Sail:
./vendor/bin/sail up -d
- Install PHP dependencies:
./vendor/bin/sail composer install
- Generate the application key:
./vendor/bin/sail artisan key:generate
- Run database migrations:
./vendor/bin/sail artisan migrate
- Install Node.js dependencies:
./vendor/bin/sail npm install
- Compile assets:
./vendor/bin/sail npm run dev
Contributing
Contributions are welcome! Please follow the instructions in CONTRIBUTING.md.
License
This project is licensed under the MIT License.
Meu time de utiliza scrum na gestão dos projetos, uma parte desse fluxo de trabalho envolve estimar o tempo gasto nas atividades, e para isso utilizamos um jogo chamado planning poker para fazer as votações das estimativas.
Já existem diversos produtos prontos para esse propósito na forma de sistemas web então decidi criar mais um.
Login
A utilização de sistema de login foi descartada por se tratar de um sistema simples em que um sistema de login poderia atrapalhar a adesão dos usuários e gerar mais complexidade que o necessário, os nomes dos usuários são passados na hora do voto no payload.
Mecânica
A mecânica de um jogo desses não é complicada, você tem salas, onde ocorrem partidas e nas partidas são feitos os votos.
O trabalho da sala é manter um guardar a partida atual, assim pode ser utilizado o mesmo link em vários jogos e os usuários sempre vão conseguir acessar a partida certa.
A partida tem informações de inicio, fim, e o vínculo com a sala, por regra de negócio só pode ter uma partida aberta na sala.
Os votos possuem nome do usuário e valor (atualmente em fibonacci), como não tem usuário logado, o nome é necessário no voto para se ter o contexto.
Modelagem relacional
A modelagem relacional foi algo feito a contragosto já que não vejo necessidade de armazenar esse tipo de informação e queria simplificar ao máximo, mas dada a integração do eloquent ORM optei por utilizar uma modelagem com Postgres, mas algum sistema de dados em memória como Redis seria melhor aproveitado.
Modelagem
A modelagem pensada de forma relacional para se integrar com uma infra de postgres, mas poderia estar estruturada direto com redis em memória para otimizar performance.
Realtime
Um dos requisitos de um sistema de planning poker é funcionar em tempo real, dada a forma que os runtimes de PHP funcionam, existem poucas alternativas de websockets utilizando, a prática comum é a utilização de um serviço especializado na comunicação via websockets, como pusher, soketi, ably.
Aproveitando as integrações do Laravel eu utilizei o sistema de broadcasts do Laravel e o driver do Ably.
Fluxo
Aqui o fluxo completo do aplicação, o usuário deve inserir o nome ao acessar a aplicação, pode entrar em uma sala através de link ou criar.
Os eventos que ocorrem na API (backend) são enviados para a Ably que encaminha as mensagens por websocket para os usuários que estão escutando os eventos da sala.
Cada um desses eventos de websocket é tratado na interface e a cada alteração no estado da partida e das votações reflete imediatamente na interface.
Layout
A parte de layout foi a mais dificil, eu não tinha pensado sobre a complexidade do layout, acreditei que seria mais simples mas ao me deparar com várias alternativas (flexbox, grid, table, position absolute) de implementação, cada uma com seus problemas (e evitando usar js para não aumentar a complexidade).
Acabei optando depois de alguns testes, pela visualização com uma table e divs nas células posicionando os cartões, não fica muito adequado nas pontas mas foi o que ficou mais semelhante ao formato que eu buscava (formato de mesa de poker oval).
O responsivo ficou para ser implementado posteriormente e foi dada pouca atenção ao design da aplicação, pois o foco era em velocidade de entrega e funcionalidade.
Finalização e deploy
O deploy inicial foi preparado em uma VPS da Digital Ocean com Ubuntu, docker e PostgreSQL.
Preparei as actions do GitHub para validar os testes automatizados e fazer a imagem docker a partir do php oficial com apache.
O deploy continua manual mas é um script simples, então também pode ficar para uma melhoria futura.
Primeiro uso
Invés de lustrar muito eu quis mostrar o projeto conforme o que eu tinha conseguido produzir no período que eu me propus para não virar um projeto imaginário.
Aconteceram alguns problemas durante o test drive:
Durante a primeira votação meu sistema morreu e não levantou mais, tinha esquecido de habilitar o docker restart, outro agravante é que eu não preparei o monitoramento então nem acompanhei o log de crash.
O sistema foi feito usando o Firefox, quando foram executar pelo Chrome o layout ficou quebrado.
Mas já deu pra ter uma dimensão do que eu preciso corrigir e espero que em breve já esteja dando para utilizar como ferramenta principal para nosso planning poker.
O código está publicado no github com licensa MIT
https://github.com/naaando/planningpoker
Top comments (0)