Server rendering and routing for login - popularity?

Learn
1

So, I am around a large crud app that is split into a login app and the other actual business logic apps for authenticated users.

My ideal way to handle this division would be to implement the login using server side rendering and routing, and then implement the actual business logic apps as a regular elm SPA, but then that introduces two places where html and css need to be organized. So, you would have to replicate the branding across those two areas.

Some other alternatives:

  • Implement the login app as a small separate SPA
  • Use some advanced method of doing server side rendering with Elm

I like server side rendering and routing for the login portion of the app because it lets you reuse existing libraries for auth, and seems conceptually simpler.

How popular is such a hybrid approach?

2

Personally I like to do auth in the client as well but you can easily reuse the CSS - you don’t have to do CSS in Elm.

2 Likes
3

Having separate auth and app is very common and has been since well before Elm came around. Having shared branding should be fairly minimal effort too.

1 Like
4

Let’s speculate that react and python is the most popular combination right now. Do you think teams using that combination typically use flask auth with server side rendering and then navigate to react apps that rely on the authentication being established and injected?

5

I think that speculation is unrelated to whether your login page is separate from your main app. I’ve been on large (many hundreds of thousands to millions of loc, React, Ember, Elm, etc) apps that do both approaches, with a variety of backends.

1 Like
6

We do the login server side in Rails.

Makes the Elm app simpler as it mostly doesn’t need to handle the possibility of being unauthenticated. If you get the Elm app, you are already logged in.

There is the case when people logout in another tab or the login expires. In that case you will see an unauthenticated message and you will need to refresh the page to login again.

The trade offs are the duplicated styling.

And that this page needs to be served by the backend framework. Eg putting the front end in a CDN is a common approach, which this makes more complicated.

1 Like
7

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.