I always applaud the idea of using well known, highly used authentication and authorization methods. The only other response I have at this time is the group will probably be more help if you begin implementing your system and ask specific questions. The architecture side of things will always be debatable and to be honest nothing you are suggesting is standout wrong per say. That being said I would imagine your troubles here won't be with your architecture so much as the network jitter and delay interpolation etc on a space shmup.
I debated about this: start now, and ask questions later, or sit back and contemplate. I chose to ask about architecture first, but ended up diving into the project. I initially wanted to ask about jitter, latency and how to combat that with dead reckoning/path interpolation. I've read some papers online, but wanted to go over the specifics of it once I actually had something implemented. I ran into the issue of writing my Asteroids MMO using TCP sockets a few years back. It was a nightmare attempting to convert it to UDP, and I never finished UDP support. The game was plagued by jittering when 2 players weren't playing off of the same access point.
I started writing a REST API for user account management. This allows users to create new accounts, verify them via email, change emails, rename usernames, etc. I'm thinking about using it for login purposes too, but my NodeJS server could handle this as well since it'll have database access as well. At my old job, we would pass an API-KEY key-value pair in each of our REST API's requests. The request would return an error if the call didn't include it with the correct value. I've seen the use of API keys mentioned online, but I don't see the point of using them. Anyway monitoring the API calls via proxy can figure what the key is, so why bother using one? Is this to help stave some type of automated attacks not specifically targeted at my application?
REST-ful-ness and real-time do not mix well. REST is almost purposefully not a real-time design approach, as it trades overhead for long-term evolution robustness. Games can almost always update client and server in parallel, and thus don't often benefit from this (but still have to pay the cost.)
I think your approach sounds like it can work. Some caveats:
Web sockets are TCP -- there will be occasional lag. However, if you've played agar.io, or Realm of the Mad God, you would know how good/bad this is.
Use HTTPS or TLS for all requests if possible. While HTTP and TCP is easier for debugging, there are so many weaknesses with plaintext these days that HTTPS and TLS is pretty much a must.
Amazon may suffer the "noisy neighbors" syndrome, where suddenly you suffer a lot of performance degradation, jitter, packet loss, etc. Beware, monitor, and be prepared to move to another availability zone if it gets bad.
Feel free to come back and ask for more specific questions if you need to, or just keep us all up to date on how the project goes!
I thought agar.io used WebSockets. Player movement didn't appear to have any jittering unless players broke into smaller pieces since you'd suddenly have a bunch of objects moving much faster onscreen. I'll ask more specific questions when I get to that point. Working on the sign-in system.
I have been using redis a lot for a bunch of work projects as a lightweight message bus (as opposed to the bulky more feature rich and complex enterprise ready RabbitMQ)
I've used both in Python projects at work in the past, but not in PHP yet. I'm considering Redis for sessions, possibly
Note that you can WebRTC datachannels to get UDP communication going.
Perfect! I've wondered if there was a UDP counterpart to WebSockets. I've searched online in the past, but found nothing. When I first read about WebRTC, I also wondered how supported it'd be client-side in browsers, but I think it'll work for my purposes. I'm writing stuff that's meant to be more experimental than mass-supported.
In regards to WebSockets I personally wouldn't bother with socket.io. You can just use the ws module for games. Falling back isn't necessary anymore for any browser or device. (Nor for a game is it really worth it).
I've wondered about this myself. It seems like WebSockets have been widely supported since 2012.