O WebSocket protocolo (WS) fornece a capacidade de trocar dados entre um navegador e um servidor através de uma ligação persistente. Os dados são transmitidos através dele em ambas as direcções sob a forma de "pacotes", sem quebrar a ligação e pedidos HTTP adicionais.
O WebSocket é bom para serviços de comunicação constantes, tais como salas de chat, jogos em linha, mercados em tempo real, etc.
Como exemplo, vamos criar um backend para um simples chat. É necessário fornecer as características básicas:
- Envio de mensagens para chat.
- Determinar a autoria da mensagem.
- Notificações de acção. Por exemplo, um novo membro a entrar no chat, a sair do chat, indicador de digitação (alguém está a digitar...)
Modelo de base de dados
Comecemos por criar um modelo para a base de dados. Mesmo que inicialmente não planeemos armazenar o histórico de mensagens e correspondência na base de dados, ainda precisamos de um modelo para estruturar o envio de mensagens e notificações.
Vamos criar um modelo genérico chat_event modelo que contém:
- Relação com o utilizador. Qualquer mensagem inclui informação sobre qual o utilizador a que se refere.
- Type (enum) campo com 4 opções possíveis. Connected e Disconnected - para notificações quando um utilizador está ligado ou desconectado. Typing - para transmitir informação de que o utilizador está actualmente a escrever uma nova mensagem. Message - para uma mensagem de texto padrão.
- Message (text) - para o texto da mensagem.
Configuração do ponto final
A próxima etapa de desenvolvimento é ligeiramente diferente da abordagem padrão que é comum a outras características da aplicação. Normalmente, é criado um processo de negócio, e depois é configurado um ponto final para o executar. No caso de WebSockets, tudo acontece de forma diferente, e o ponto de partida é a criação de um ponto final baseado nos gatilhos dos quais são criados processos empresariais.
Precisamos de uma secção de endpoint. Aí criamos um novo ponto final, seleccionando a opção apropriada - WebSocket Endpoint.
Para WebSockets não há escolha de método de pedido - é sempre GET. Vamos especificar um URL simples - /chat/ e criar para ele um grupo com o mesmo nome.
A seguir, precisamos de criar variáveis que determinarão o formato de intercâmbio de dados dentro do WebSocket.
- Client-to-Server. Semelhante aos parâmetros de entrada para processos empresariais padrão. No nosso exemplo, criaremos uma simples mensagem variável de texto (enviaremos mensagens de texto normais para o servidor).
- Server-to-Client. Aqui são criadas variáveis para mensagens do servidor, enviando dados do servidor para o utilizador. Note-se que isto não é o mesmo que uma resposta a um pedido do utilizador. E embora possa ser enviada como reacção a acções do utilizador, é mais frequentemente causada por alguns eventos externos. No nosso exemplo, o servidor enviará notificações de todos os eventos no chat, pelo que definiremos o chat_event modelo como variável.
Depois de criar as variáveis, pode proceder ao principal - criar a lógica do WebSocket. Baseia-se em gatilhos que disparam quando uma nova mensagem é recebida num WebSocket, bem como quando uma ligação é estabelecida ou desconectada.
Criação de um processo empresarial
Vamos usar o connect desencadear e criar um processo de negócio para ele. Será lançado no momento em que o utilizador estabelecer uma ligação com o WebSocket, e a sua tarefa será enviar uma notificação sobre isto a todos os utilizadores ligados.
Note-se que o bloco de início inclui dois parâmetros: User ID e Connection ID. Assim, é possível não só determinar imediatamente o utilizador que estabeleceu a ligação mas também obter um identificador único para esta ligação. No futuro, este identificador pode ser utilizado, por exemplo, para enviar mensagens direccionadas ou para terminar a ligação à força.
Сreate todas as etapas necessárias do processo comercial:
- Make User. Vamos utilizar o parâmetro inicial User ID para criar um modelo de utilizador.
- Make chat_event. Сreate um modelo de notificação de eventos. Iremos ligá-lo ao utilizador utilizando o modelo criado no passo anterior e também seleccionar o tipo de evento e definir Type = Connected. Não utilizamos o parâmetro de mensagem uma vez que, neste caso, não é uma mensagem que é transmitida, mas uma notificação de ligação.
- WSS Connections /chat/. Utilizando este bloco, obteremos uma lista de todas as ligações WebSocket activas.
- For Each Loop. Utilizamos a matriz de ligações como parâmetro de loop, enviando notificações a cada utilizador ligado.
- Expand WebSocket Connection. Expandir a informação da ligação para obter o Connection ID.
- WSS Send /chat/. Utilizamos o Connection ID e os gerados chat_event para enviar a notificação.
Utilização de carteiros para testar WebSockets
Nesta fase, o WebSocket, embora não tenha uma funcionalidade significativa, já está operacional e pode ser testado na prática. Para tal, pode utilizar qualquer ferramenta que lhe permita trabalhar com WebSockets. Vejamos como fazer isto com Postman como um exemplo.
Deve clicar no New button e seleccione WebSocket Request
É necessário especificar o URL para o WebSocket. Pode ser encontrado utilizando a Swagger, onde o WebSocket está na lista com o resto dos pontos finais.
Ao contrário dos pedidos normais, os WebSockets funcionam utilizando o wss protocolo, pelo que necessita de substituir https com wss. O resultado deve ser um URL semelhante: wss://qvlxglh-app.apms.io/api/chat/
Em seguida, é necessário acrescentar um símbolo de autenticação ao pedido, uma vez que a ligação não pode ser anónima. É necessário criar um Authorization cabeçalho com um valor como Bearer lBCiunRWg6BfogDrLml4jrC4iJiWucKo. Em vez de lBCiunRWg6BfogDrLml4jrC4iJiWucKo, precisa de inserir a sua própria ficha, que pode ser obtida como resultado de autorização (POST /auth/ endpoint).
Se tudo for feito correctamente, então ao clicar no Connect será estabelecida uma ligação, e a primeira mensagem será recebida do lado do servidor, o processo comercial para envio que foi criado anteriormente.
Ao mesmo tempo, é possível assegurar que a recepção de mensagens do servidor não ocorre apenas como uma reacção a alguns pedidos nossos. As acções de outros utilizadores podem causá-las. Para testar isto, pode estabelecer uma ligação num outro separador utilizando o token de autenticação de outro utilizador. Uma mensagem do servidor notificando isto será enviada para todos os separadores com uma ligação activa.
Processo comercial para envio de mensagens
Agora pode continuar a desenvolver as capacidades do WebSocket e criar um processo comercial para o envio de mensagens. A propósito, pode enviar mensagens agora, mas sem primeiro criar a lógica, isto não faz sentido, a mensagem não conduzirá a qualquer reacção. Portanto, voltemos às definições do ponto final e criemos um processo de negócio para o receive gatilho.
Em muitos aspectos, será semelhante ao processo comercial anterior. Quando uma mensagem é recebida, será necessário gerar um chat_event e enviar notificações sobre o assunto a todos os participantes do chat. A diferença é que a própria mensagem terá de ser acrescentada ao chat_event, e o autor da mensagem não precisa de ser incluído na lista de correio.
Os mesmos blocos são utilizados na primeira parte do processo comercial. No Make chat_event bloco, precisa de definir type = message e anexar a própria mensagem desde o bloco de partida.
No laço, temos de verificar (Equal bloco) e enviar a mensagem apenas se o ID de ligação do receptor não corresponder ao ID de ligação do remetente (If-Else = False).
Pode publicar o resultado e iniciar os testes. Note-se que a mensagem em si está em JSON por isso, ao utilizar a variável de mensagem, terá este aspecto:
{"message":"Some text here"}
No exemplo, pode ver que recebe uma notificação de ligação de chat, enviar a sua própria mensagem (Hi!), e receber uma resposta (Glad to see you!)
Isto completa a criação do backend básico para o chat utilizando WebSockets. Pode começar a construir o front-end e desenvolver a sua própria aplicação de mensagens em tempo real.
