africanpenguin / coffit Goto Github PK

Feel free to propose new names, modification to the actions or whatever we have in the next list:

From client to server:

• GetBatches: Get the coffees between from and to with all the details.
  • Event: "get_batches"
  • Message: { "from": date, "to": date }
• GetBatch: Get the information about an specific batch.
  • Event: "get_batch"
  • Message: { "id": number }
• CreateBatch: Create a a batch in poll status.
  • Event: "create_poll"
  • Message: { "creator": id, "batch_at": date }
• BatchStatus: Notification to the client about a batch done.
  • Event: "set_batch_status"
  • Message: { "batch_id": status }
• EnrollToABatch: Submit to drink a coffee.
  • Event: "enroll_to_a_batch"
  • Message: { "enroller": id }

From server to client:

• Batches: Send the information about batches.
  • Event: "batches"
  • Message: [ { "creator": id, "batch_at": date, "enrolled": [ {"name": name" } ] } ]
• Batch: Send the information about a batch.
  • Event: "batch"
  • Message: { "creator": id, "batch_at": date, "status": status, "enrolled": [ {"name": name" } ] }
• BatchStatusUpdated: Update the status of a batch
  • Event: "batch_status_updated
  • Message: { "batch_id": number, "status": status }
• NewEnrollment: Send to the client that a new person is in for a coffee.
  • Event: "new_enrollment"
  • Message: { "name": name }

I think it is too coupled to our current problem. Most of the cases can not be easily extendible, probably it is easier to create a CRUD for both tables. However, we can go with this and deal with the problems once they start happening.

About the user session, from the server side, we should be able to identify uniquely each WS connection, so we will need only a "login" event. To keep the session we can use a dictionary for now.

Ideally in our application you'll have to be able to log-in/authenticate yourself, in order to be able to do things like creating coffee batches, participating/enrolling in batches, and all sorts of stuff that may be implemented in the future and require some form of "authorization" (eg. an anonymous user can see batches, but cannot create a batch or participate in one without being logged in as an identified user of coffit).

The workflow that most people recommend over the internet for SPA's is:

1. Make a request with the user's credentials to the server's login endpoint (eg. /login).
   • We could also make this endpoint a websockets "namespace", just to keep the "websockets-only" spirit strong. However we have to check if there are any implications or security hazards in doing so...
2. The server checks the credentials and replies with an access_token in the response's body.
   • We should use JWT for this. There is a bunch of information we can store in a JWT token, and the good thing is that it holds all the state that is needed to be validated by the server (aka the server only needs to access the DB only once, when it creates the JWT)
3. The client stores the received access_token somewhere persistently.
4. The client opens a SocketIO connection, passing the access_token in its Authorization header (or any other place that may suit our needs).
5. The server validates the access_token, and connects the client.
6. The client can now send and receive messages/events through the SocketIO connection.
   • On page refresh the client can reopen the connection normally, including of course the access_token it has stored.

This method eliminates the need to store any session on the server side at all. We should later see how me can also integrate OAuth login in the application.

To play as my own devil's advocate though there is this guy, who says that JWT instead of session storage is dangerous and bad...

Problem
The current method to switch off the machine is: the human-relè (ask to @omelkonian through gitter to turn off).
This method is deprecated because is poorly reliable and with a high latency.

Solution
We need a API to remotely turn off the machine.