Using GrapphQL api for web app vs. directly calling module functions

We built the web application first and directly access modules, and use GraphQL to server to iOS so a slightly different scenario.

I would be personally be inclined to talk directly to the module functions and bypass a whole load of overhead of handling the GraphQL call, encoding the response, decoding the response, rebuilding structs for the web application to interact with - it will make coding harder and the system less performant to have all those extra, unnecessary layers in there.

Could you elaborate on your worries about session management, cookies, caching etc that you think using GraphQL will solve for?

Thanks for the response @mindok.

I am just generally asking about any issues we will run into with session management, cookies, caching etc. Have you guys ran into any of these issues?

If you decide to separate the web application code from your server-side code (for whatever reason - like running it on a separate server etc.) having this direct coupling would be bad and have to refactor to make api calls. That is not in our plan currently, but just thinking about it for the future.

No issues so far. We use Phoenix infrastructure with very little modification for cookies and session. We do have a custom plug to handle auth - there are plenty of examples around for that if you deviate from Phoenix gen auth. Passing session state (e.g. user identity) into liveviews is also well covered and documented now.

For caching, it depends on your use-case. We primarily use liveviews throughout our web application. State is held in the process backing the liveview which is great for long-running editing sessions. However, ours is a pretty specific use-case - a small number of power users that use the system all day every day. The templating engine in Phoenix is so ridiculously fast, the need for caching is a lot less than for other frameworks (there’s an article on IO Lists that explains why: https://bignerdranch.com/blog/elixir-and-io-lists-part-1-building-output-efficiently/). You have straightforward and direct access to the HTTP response headers, so if you need to manipulate http cache control, you can. There’s also the excellent cachex | Hex for keeping data in memory across requests & sessions.

Fair enough. However, you are likely to need to consider scaling a lot earlier if you create unnecessary system overhead . The way we’re looking at it is to keep our team as tiny as possible for as long as possible while the business ramps up around the product. A well-structured monolith lets us do that. If we need to scale, we can run the main application on multiple servers / VMs and have them talk to each other using the baked in capabilities of Erlang and Phoenix. If, for whatever reason, we do need to separate API server from web server, we’d be wanting to be extremely well paid for it so will organise for one or more of the luminaries in the community to sort it out for us! But thinking about it, we’d probably look at compile-time settings to enable / disable the graphql routes or the web application routes and maintain the same codebase for both.

Thanks for your details response @mindok - really appreciate your feedback.

I am now able to call the module.function to get the login working. Since the liveview doesn’t have access to conn object and only the socket - what is the approach to store the current_user (logged in user) in the session? I see there are libraries like phoenix_live_sessions (PhoenixLiveSession — phoenix_live_session v0.1.3).

Any suggestions would be helpful as I am trying to figure out the logged in sessions and how to keep track of it during page reloads and opening new browser tabs on the same browser etc.

Hi @kxkannan,

Transferring credentials from the conn to the socket is discussed in the LiveView docs here:

Security considerations — Phoenix LiveView v1.2.5.

There is a pretty decent explanation of how it all hangs together here: Securing Your Phoenix LiveView Apps | AppSignal Blog

Basically, the “session” parameter in the mount callback in your liveview should contain the credentials, and you transfer the credentials to the liveview socket there. However, rather than do this across all liveviews, you can define a hook shared across them. The wire-up to connect a specific on_mount hook to a group of liveviews is done in the router using live_session.