Startup Clix: Pre-Authentication & Webhooks with Pusher

K - May 10 '18 - - Dev Community

Today I realized that this activity task issue probably won't be fixed soon and I need some extra storage to get around it, but I also made a few improvements.

Pre-Authentication

Until now my channel join process relied on two requests, but Pusher allows for custom authorisers, which helped me to get it down to one request.

My idea was, a player comes on the site and requests a game channel ID. Then they subscribe to it and will get their updates through it.

The subscribe method will call an authoriser, which in turn will call my back-end to authorise the player.

But with a custom authoriser I was able to get the auth credentials right with the request for the channel ID. A small win and one possible race condition eliminated (still one left, hurr)

Step Function Activities could be better

There are two ways to interact with a state-machine via Lambda.

One is to simply let the state-machine call a Lambda and push its input into it, then wait till the Lambda returns the data.

Two is to create an activity. This has an ARN that can be used to poll a state-machine task via a API-Gateway Lambda, do some stuff with it and give it back to the state-machine so it can go on. Problem is, there can be multiple parallel executions of a state-machine and you can't filter when polling a task.

My idea was, every game will be one state-machine execution, but since I can't get the right tasks there doesn't seem to be a simple way to push data into the right state-machine execution.

Webhooks

I added a Lambda that gets called via Pushers Webhook functionality. Every time a Player joins a game channel, the Webhook is called. The Lambda that is run in response to that will check if that joined channel is full and send a game:start event to all players in the channel.

Next

While today was mostly filled with thinking about how Step Function can be bent to my will, the next step is to bend myself to the will of AWS, hurr...

Anyway, kicking off a state-machine execution when a channel is full.

Only allow players to channels that aren't full and have no running state-machines.

Adding a DynamoDB to store game data that is sent every round via a HTTP request to the back-end.

Define a state-machine that gathers game data from DynamoDB every round, checks who has lost and who one etc.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .