elixir-raknet VS phx_gen_auth

The core of the X-Plane server is our RakNet UDP protocol, which is open sourced under the MIT license here:

https://github.com/X-Plane/elixir-raknet

It's not a full game server, but the "Usage" section of the README provides a sketch of what the rest of the server (the part that implements the business logic) looks like.

Happy Elixir user here. At work we have a use case that isn't covered by José's high-level overview of the domains Elixir's used in: we run a massive multiplayer game server on it.

This is actually a really good fit. (It kind of rhymes with the original use of Erlang, being telecoms infrastructure.) We get outstanding concurrency support, high reliability, and really efficient development times. I can't imagine shipping this feature with a server written in C++ (the language I'm most comfortable in), and I can't imagine scaling it the way we need to if we'd gone for a traditional web language like Node, PHP, etc.

If you're interested, you can see the RakNet (game networking protocol) implementation we use on the server here:

https://github.com/X-Plane/elixir-raknet

The README gives a good overview of the full MMO server's architecture, too: each client connection is a stateful Elixir process (not to be confused with a heavy-weight OS process!), acting asynchronously on a client state struct; clients then asynchronously schedule themselves to send updates back to the user.

This code assumes you've used the Phoenix Auth generator to add authentication to your Phoenix app. The details of authentication aren't important for our purposes here. Just know that the survey route is a protected route that requires an authenticated user. This means that when a logged-in user points their browser at /survey, the SurveyLive view will mount with a session argument that contains a key of "user_token" pointing to a token we can use to identify the current user. The generator also gives us a function, Accounts.get_user_by_session_token(user_token), that we will use to fetch the user for that token.

We're also using a test helper provided for us by the Phoenix authentication generator—register_and_log_in_user/1. This function creates a conn struct with a logged-in user, a necessary step because visiting the /admin-dashboard route requires an authenticated user.

Thanks for the suggestion. I started off with a Phoenix-only app but then I realised that it would be really nice to have a separate frontend. My Phoenix app was using phx.gen.auth, but according to the readme on their GH page, the `--no-html` option is not supported, so I'm thinking about trying POW. I've found this example which looks a little full-on, especially compared to how simple this is done in Django.

Thank you for your work on adding user registration and authorization to Phoenix!

I'm setting up a new Phoenix app for a side project this weekend and have just run Arron Renner's [auth generator](https://github.com/aaronrenner/phx_gen_auth). Having user registration out of the box will save a big chunk of time and energy!

Even though phx.gen.auth seems to be the hip solution for authentication at the moment in Phoenix land, I still prefer to use Pow for my small hobby projects and a side project I am working on. A short statement why I prefer Pow can be found at the end of the post.