Projeto Planning poker realtime com Laravel
Tags: laravel, scrum, beginners, webdev
Published: 2023-11-24 04:02:40

Como desenvolvi um planning poker com **Laravel**, **Ably**, **InertiaJS**, **Tailwind** e **Vuejs**.

[Link para planning poker](planningpoker.fssoftware.com.br)

{% github naaando/planningpoker %}

![Roda de poker do Planning poker](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/52tks4k49x8w4gec96ja.png)

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*

![Modelagem do banco de dados](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yodnvrauf8wl0ahvcxsj.png)

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.

![Fluxo detalhado](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vjx4ctk6hh8r5gqjcnuy.png)

### 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).

![Imagem do layout completo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vhrus8i0kjhbnwaze27p.png)

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.

![Github actions](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u284tdn8r7g4urghc6hj.png)

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