How does remix app scales

[pete88290]

Seems remix services rely on http session for authentication. If I have multiple instances, I can set up a radius cache to store the session data so that the remix services can be stateless. But this approach looks old school. Manage the cache is not flexible and not street forward. Using a token is a better idea as the token is signed and the auth info can be carried in the request rather than managing them in data store. I am not sure if there are good practice to apply token approach in remix.

Another thing of cookie session is that it is hard to combine multiple micro services into a big app. Every service needs their own auth. So the auth service and resource service cannot be seperated.

[kiliman]

Remix is not opinionated. You are free to architect your app in whatever way makes sense.

If there was a "Remix" way, I suppose that it encourages doing as much as possible on the server.

[pete88290]

Thank you for the prompt @kiliman . What I want to achieve is when submitting a form, I want the client carry a bearer token in Authentication header. Then in server side, the middleware (e.g. in express) can verify the token before proceed. This approach is a common practice in ajax. I am not sure if it is a convenient way to achieve this remix form submitting (I guess not). For the form submitting, it only can use a hidden field to pass the token. It is not possible to set Authentication header and verify it in either loader or action,.

[sergiodxa]

Instead of storing the auth token client side and probably in an unsafe place like localStorage it’s better (even in a traditional SOA) to store the token in an httpOnly cookie.

The cookie will also travel in every request to the server not only on an Fetch/AJAX request but also a document request so you can know if the user is authenticated also on the first page load, something impossible otherwise and required in Remix to do SSR with actual data.

If you use createCookieSessionStorage to create your session the whole session data will be stored in the cookie, this means you can store the token there, you get a httpOnly cookie with the token and your server is stateless since the browser is storing the token and not the server.

The only possible drawback is if the token is larger than 4kb (the shortest maximum cookie size between all browser), in this case you have two options

1. Use a smaller token, think shy do you need an access token that large, if it’s an id token you can probably fetch that data when needed.
2. Use a different session storage like Redis where there’s no size limit, and still have the benefit of being stateless.