How to make stateless web applications? Especially with Spring MVC?
Asked Answered
H

1

2

The stateless web application seems promising. How to make one? Especially with Spring WebMvc? Any guidelines?

Here are a few things on my mind:

  • Avoid creating session
  • Use a centralized storage for state info and share that among web application instances.

ADD 1

I think it is not a question of whether to keep state info or not. State info is always necessary if you want to do something useful. It is actually a question where/how to keep the state info. This article is useful. It mentioned in-proc/out-of-proc session, data cache, and why not to use session.

Related:

Use Spring MVC for Stateless web application development (no response yet)

Stateless Spring MVC

How to make a java web application fully stateless

How do I make my Web Application stateless yet still do something useful?

http://brockallen.com/2012/04/07/think-twice-about-using-session-state/

Honorific answered 7/1, 2016 at 9:41 Comment(2)
Don't re ask the same question because that got downvoted/closed... You haven't improved or updated the question...Chanty
@M.Deinum Actually, I deleted the previous question myself. It is downvoted before I add enough details. And there were some non-constructive comments. Well, I should have completed the question before the it is published.Honorific
G
9

Here are some contributions. I'm not familiar with Java and Spring, but I believe these guidelines are valid regardless of your technology stack.

Stay away from sessions for authentication

As you anticipated in your question, avoid using a session to authenticate users. Sessions are peremptory and it's very difficult to replicate it consistently in a distributed, scalable infrastructure.

Also, load balancers don't work well with sessions: see Problem with Session State timeing out on Load Balanced Servers.

Use a token-based authentication system

A stateless app will preferably use a token-based authentication system. Firebase is a good example. Map the immutable user ID extracted from the token to the user data persisted in whatever storing mechanism you want to use. Since this user ID won't change, you'll be fine in a distributed database.

Don't confuse stateless with 'data persistence'-less

Sometimes people think that, by mapping a user ID to user data in a database, you are making a stateful app. It's not true. Let me make it clear:

An application that persists user information in a database and has dynamic responses for authenticated users IS NOT NECESSARILY STATEFUL. Stateless means the app won't have to distribute mutable authentication sessions across multiple servers and won't change its internal state to a particular client depending on session data.

The trick of stateless is: once a user validated its token by logging in, the server don't have to distribute anything new across the database servers and it won't change its state to that client. It can extract user info from the token and carry out what's needed to answer the request. If the token expires, the client will require a new authentication, which will generate a new token, but this is isolated from the app server, since the user ID will remain the same.

Use cookies for caching while remaining stateless

If caching in cookies some frequently requested data will improve performance, that's fine, go ahead and cache. Just make sure the cookie isn't connected to any server state and your app will not break if the client loses the cookie.

Grory answered 10/4, 2017 at 23:21 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.