Is this a correct way to handle multiple concurrent users where the application accepts a client connection and spawns a new process to serve it.

Absolutely! That’s the way to go! For example, in a nutshell, Phoenix Channels and LiveViews hold a process for each stateful web socket connection.

Since I am starting a http server the terminal blocks. Is there a way to hook into the server using :observer.start() or other means and see how many users are currently playing?

The simplest, in your scenario, probably would be somewhere in application.ex in start callback just call :observer.start() so once you start the app - it first would start the observer and then start the server itself (though you don’t want that by default for users, maybe via some ENV variable can be configured?)

However, some notes for the reference:

1. as mentioned in docs:

   Escripts should be used as a mechanism to share scripts between developers and not as a deployment mechanism. For running live systems, consider using mix run or building releases. See the Application module for more information on systems life-cycles.

   So one alternative option would be if running the app with mix (either release or just mix run) we could start it as named node, for example:

   iex --sname server -S mix
   

   (here we start our mix project in a Node named “server”)
   and now from another terminal we could attach iex as a remote shell with

   iex --remsh server --sname observer
   

   (Here we start a node named “observer” and attach remsh (a remote shell) to the node “server”)

   As of now, it would require to manually start the HttpServer..

   Games.HttpServer.start(9000)
   

   so once we start the server - it will block the shell, just as with your escript. But we have another shell attached to the server! where we could run :observer.start()! or whatever we want!
   (though it would probably make sense to have that Games.HttpServer.start to be part of the main Application supervision tree.. so it starts automatically and doesn’t block your shell)

2. In your scenario I’d recommend to spawn a “supervised” process either through DynamicSupervisor or Task.Supervisor, instead of just bare bone spawn(fn -> ... end).

   We encourage developers to rely on supervised tasks as much as possible. Supervised tasks improve the visibility of how many tasks are running at a given moment and enable a variety of patterns that give you explicit control on how to handle the results, errors, and timeouts.

   Task — Elixir v1.20.2

   Plus, processes that are parts of a supervision tree are not only more flexible with tree are nicely shown in the “applications” tab in :observer