I'm trying to build a project structure for an application we are working on at my job. Really new to the fix-protocol world.
What I don't understand is, do/should all messages go trough the same client-server session or is a new session created for each user that logs in the app? I'm thinking the first option is more optimized than the other becauase it would generate less load to the fix engine, but I want to know what the best practice is.
You can think of a session as being a socket connection between a FIX client and FIX server. When a FIX client opens such a socket connection, the first FIX message it sends is Logon, and fields in this message identify the FIX client to the FIX server. The FIX server can accept the connection by responding with a Logon message, or refuse the connection by closing the socket.
Based on the limited details provided in your question, I am going to guess that your "app" is a FIX client that does not create FIX messages on behalf of itself, but rather it acts as a delegation server. For example, there might be multiple users, each of which has their own GUI that sends messages (in a non-FIX format) to the delegation server, and the delegation server then translates these incoming messages into FIX format and acts as a FIX client to forward these messages on to the FIX server. In such a case, several options come to mind.
The first option is for the delegation server to open a separate socket connection to the FIX server for each user, and to use the user-specific socket connection to send a Logon message with that user's credentials. Messages to the delegation server from user 1 are delegated to the FIX server via socket 1, messages from user 2 are delegated via socket 2, and so on.
The second option is for the delegation server to open a single socket connection to the FIX server, send Logon once, and then, in every message sent on behalf of a user, use header fields such as OnBehalfOfCompID, OnBehalfOfSubID or SenderSubID to identify the user (disclaimer: I have rarely had occasion to use such header fields, and my understanding of their intended purpose might be incorrect, so perhaps this suggestion is semantically flawed; if so, I hope another user here will correct me in a comment). Or perhaps the Account field in the message body might be used for this purpose.
The first two options are based on the assumption that the FIX server needs to know the identify of the individual users who are (indirectly) sending messages to it. A third option is relevant if all the users are trading on behalf of a single legal entity. In this case, there may not be a need to disclose the identity of the individual users to the FIX server, so the delegation server could have a single socket connection to the FIX server and sends a single Logon message to identify the legal entity, and never passes on details of individual users to the FIX server.