DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Developing Stateless Web Apps

Ricardo Zuasti user avatar by
Ricardo Zuasti
·
Sep. 18, 12 · Interview
Like (0)
Save
Tweet
Share
4.67K Views

Join the DZone community and get the full member experience.

Join For Free

Almost all of the web apps we build nowadays (at least on the circles I usually move around) rely on the beloved and hated session. This artifact, providing a stateful user wide storage, allows us to relate several HTTP requests together and thus implement the concept of authenticated and secure web applications, that “know” who is using them several requests after they authenticated, despite the root stateless characteristic of the HTTP protocol itself.

To provide a very brief recap, sessions are usually implemented using a hash like memory structure on the server, where each session is stored using a unique identifier string. This string is stored also on the users web browser, typically via a cookie or by sending it back and forth on each request as a POST or GET parameter.

I believe it’s time to move away from this approach and start building session-less web applications that still provide the same feature set and security.

You might say that this is part of a REST approach to web applications and that it’s been already beaten enough into our heads… but the truth is it’s not, most of the new apps I see are still making heavy use of session storage and their whole architecture is based around it.

Why are session based web apps bad for us?

So why? Why are we supposed to stop using this thing we have been using for 15 years of web development? Well, session variables are no more and no less than global variables and if you still need arguments against the usage of global variables please either go back to college or ask for a refund.

Still not sure? Some stuff why session variables are mean:

  • They promote coupling: disparate pieces of code access the same variable without a defined contract
  • They reduce scalability: over usage of session storage increases the app memory usage as the user base increases
  • They promote harder to read/debug code: some page/method accesses a session variable that “magically” contains the value you need but it’s usually unclear where this data came from and who put it there.

Ok, you convinced me, now what?

Easy, just stop storing stuff on that session!! No, really, stop it!

I bet that in 99.9% of the use cases, you can build your app by just knowing who the user is. So what you must do is just store the user identification on the session and that’s it.

But you will say: ohhhh, but really, I mean, we display his first and last name on every page, isn’t it just easier and faster if we store them too on the session?

And let me tell you, it’s like crack, you don’t want to go down that road. Keep your architecture pure and stateless, let every controller method receive the information it needs from the HTTP request and return all the information the view needs to render itself. If you are worried about IO performance, implement an appropriate caching strategy on the data access layer, do not use the session for performance tuning.

app Web apps Session (web analytics)

Published at DZone with permission of Ricardo Zuasti, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Exploring the Benefits of Cloud Computing: From IaaS, PaaS, SaaS to Google Cloud, AWS, and Microsoft
  • Debugging Threads and Asynchronous Code
  • Mr. Over, the Engineer [Comic]
  • Image Classification With DCNNs

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: