I work full time as a software developer, I stumbled across this while doing some research, and what can I say? you have an amazing character. Well explained :)
2:44 4:41 introduction to the problem of stateful application 5:50 problem: impossible to scale up 6:10 6:51 stateful with load balancer 8:36 stateless example 8:52 Alice is using REST, State transfer 11:14 server sends Alice a *token* 11:34 then Alice will send request always with the token
nice video! i really appreciate videos like this that talk about real concepts/use cases in a simple way that you can watch on down time. keep at it cause it looks like the videos you're making are really cool!
God bless you sir, when no one could explain me this thing...u did it in such a simple way. And yeah that accent of ur's its awesome....I can listen to your lectures for hours
Shubham Batham sending a signed and time-stamped response token of love to all my subscribers in india ❤️ passcode to decrypt “stay awesome” thanks for your comment!!
I am hooked to your videos and as a junior back end developer i am learning a lot seeing things from different perspectives in my job. Thankyou so much
Hey Nasser, your video is simply superb. Hatsoff. As your voice is BOLD and STRONG, one thing i visualised you as you will look like "Vin Diesel". By seeing your DP, then i realise you. Take a Bow.God bless you....:-)
Brilliant explanation champ! I've watch about 3 or other videos (each being 2 or 3 times longer) and NOT ONE of them came close to explaining it this comprehensively! Well don and a sub from me!
Well explained. Just watched another video on stateless v stateful and this was my exact question: Wouldnt the ideal be tokenization with API? It seems like a cache has the same issue unless the cache itself is just another word for intermediate database. Thank you for clarifying that this is exactly the case and how this can be accomplished scalably.
TL;DR: Stateful is basically keeping track of the state a user might find itself in (good example would be whether it is logged in or not). Stateless is using an alternative solution (for example using a token response solution) instead of keeping track of the state of the user to keep things scalable (especially useful for example when running a load balancer set-up). The latter often goes in hand with a lot of caching on the back-end side of the app.
Awesome video, I understand most of the good points of stateless, I guess making a web application whether a session is an important concern but not important at scaling we probably would use php session as a way to maintain the session or any other programming that gives us this set of tools. but regarding the we wouldn't scale horizontal, thanks man
It looks like the only difference is: Stateful: save the session info in service. Stateless: save the session info in 3rd party component, say database
Natalie Schulz Glad you find was useful, checkout the rest of the content in the channel where we explain other software engineering topics by example. Cheers :)
Good. I think the same way a token is stored in the DB and queried by all instances of system, a sessionID (localStorage of any kind of native app local storage) can be used with the same results in computing cost. The main PROs of using stateless is regarding to JWT, a way to validate tokens by the information it contains itself and not by querying the DB. Sessions ID and Tokens can be managed the same in backend and frontend, but for exposure to any client/platform, JWT is the way to go right now also because its granularity about granting specific permissions. Thank you.
Cool video. But got me thinking a bit. I am not sure I am completely with you in here. Please correct me if this is wrong: the difference in your examples is only the fact that in the 1st example you cache the value in server1 while on the 2nd example you don't cache the values, you always check the token against the db. Isn't a more 'stateless' example a scenario where you can rely on the information on the token to do the validation (jwt)?
João Salgado that is correct, when I mention stateless and stateful in the video I was referring to the application that is hosted on the servers. So in the first case my application is stateful (cant scale) and in the second case my application is stateless. However the entire system still has a state which as you mentioned its in a database. Building a real stateless “system” is very hard because most of the time you probably need to store your state somewhere. Thanks for your comment!
i think i got it, in a nutshel, stateful means that the server store information about that "session", but in the stateless the token doesnt have to be saved also? gonna read more about it, great video btw!
Thiago Dias That make sense, you can watch the new video about the same topic with examples. ruclips.net/video/nhwZn6v5vT0/видео.html thanks for your comment
good info. but it is actually possible to scale horizontally with stateful applications. I have done this in the past using a load balancer and sticky sessions. You can use sticky sessions to redirect the user requests to the same server that already has the session for the user.
Correct, you can scale stateful apps for sure with clever logic. However if that server to which the sticky session is locked on is restarted the application breaks.
Thanks for the easy explanation Hussein, I have two questions. 1. The concept of a sticky session is related to stateful design? 2. I am a bit confused between storing(at the client) a session id in cookie and string(at the client) a token.
Thank you for your message.. Sticky session was designed mainly because the backend app is stateful such as building websocket server.. or for performance reasons.. where you want certain requests to always go to the same server (example multiplayer game with 5 players you want all of the players in the same server for performance reason) I suggest you watch the jwt ruclips.net/video/cXxEiWudIUY/видео.html ruclips.net/video/T0k-3Ze4NLo/видео.html
Glad you enjoyed it! I made another video about how Amazon Alexa is stateless maybe you will enjoy that as well ruclips.net/video/zhwMv5RxGew/видео.html
Authentication is an excellent example of just how silly webdev can get. In a statefull application you logon to server 1, that server checks your credentials, records your loggerd-in status and you get a cookie that refers to that state. This is considered bad because server-2 needs to share some storage with server-1 to know if the cookie is valid and who it belongs to. In "stateless" application you logon to server-1, that server checks your credentials and gives you a cookie that that server-2 can also verify as being authentic (like a JWT). The problem is that the state that is received by server-2 *MUST* be verified against the same database that server-1 used to create it, for the simple reason that the user may have been denied access since the token was created. You *MUST* verify. So, statelessness does not really change anything from a serverload perspective,it just sneds bigger tokens because you need to use something like JWT. The hardware on the server side is identical, withidenticalproblems that, let's face it, are not really problems at all. Replicating data among databases is not an issueunless you are a gigantic websitewith hundreds of servers but by then you will have heard of sharding.
Explanation is good. Thank you .. Would you mind clarifying my doubt ? is this concept used only for a Web applications ? or any Services ? Sorry if its a dumb question.. As I am new to the dev, curious to know. :)
Jyotsna Doddi good question! No it applies to any kind of service that is consumed by many clients. Whether this is on HTTP or raw TCP or any other protocol. As long as the service is consumed via a client, each request should be treated independently from previous requests.. hope that helps :)
You are one of the best I've ever followed but I think you've missed something in this video. The matter is not about where to store the data (in memory or in DB or in a file or whatever the place is) !! It's all about, DO YOU STORE IT OR NOT for next requests handling purposes? If the server can process a request without relying on an earlier request then it's STATELESS. If the server needs information from previous requests to be stored (in memory or DB) in order to process the current request then it's STATEFUL. REST would help to understand that since it's stateless. It sends the STATE of RESOURCE (which could be a USER) within the request every time without saying: "Why I should send it every time. why not just set it in a DB and things will be fine and stateless! 😅" I think, as a monolith application, no way to not be stateful but as a microservice, you could have one service that is stateful (for authentication and authorization) and other services are just stateless (pure business logic and the state of that logic will be sent through REST or whatever). What do you think? Do I have a point of view?
great video as useful but i know that LB use algorithm like Consistent hashing to ensure that the same user will enter the same server to get benefit of stored data in the cash rather than resend all the info again > iam right ?
That is Correct if your app is stateful that it requires al requests from client to go to it then yes LB can use sticky session algo or iphash to make sure all requests go the server
Sir, I am just about to start my second year at university, with an assignment to develop a web application and, after watching your videos, I believe I have a higher status than God. XD Jokes aside, honestly, thank you so much!!!
Zacharias King thanks Zach for the love and comment! Best of luck in your assignment!! Take a look at the other content of the channel, more cool stuff for you! Cheers
What's the difference between a token and a cookie? Why is a cookie considered stateful and a token stateless? Is there no record of the token server side? By what process is it authenticated then?
Hantzley Audate thanks buddy for the nice comment! I work at a software company called Esri. I do these videos on the side :) glad you like the content!
Correct me if i am wrong; if use jwt for session authentication(secrets on server itself) i wouldn't have to make so many calls to db(as when using session keys), making it nearly as efficient as stateful?
Saurabh Agrawal that is correct. JWT is better than session keys, JWTs has signature in them allowing server to quickly verify it Without hitting the db. They are also still stateless because the client sends the jwt with each request. So you can restart the server and the client can hit completely a different server and still be served . With session keys (what we explained in this video we have to verify the key by hitting the db) Good question
Awesome video dude! Really helpful but i have these few qs: - Is this architecture (Client->LB->Server) common or is it just for explanation purposes? If not, what architectures are commonly used? I am guessing other designs would allow for stateful apps to not break as easy (for example, maybe state is saved on same machine so if user reloads then server doesnt have to query again) - Are developers expected to program the token requests themselves or are there frameworks that do that job Sorry if these are noob questions, i am trying to learn this to get my first full stack job xD
Farhan Fiaz Alvi thanks Farhan, these are good questions:) Yes it is common, check out my load balancing playlist or just this video on nginx load balancing ruclips.net/video/WC2-hNNBWII/видео.html For your second question, Tokens and sessions can libraries that take care of them by I implore engineers to always understand how those library works. The fundamentals are what matters This might help ruclips.net/video/V3ZPPPKEipA/видео.html
Hey , thanks for amazing explanation ! just had a question does token gets stored in database (how it gets generated )and how does it gets expired (when one doesn't login )
But in a stateful app, the server still has to use cookies to authenticate or recognize the user, and when you meant we have to hit the db every time to query for the token, it sounds pretty bad, but isn't that information also cached somewhere to tie in with the cookie expiry, because if were to really look at it sometime a single page might send around 20 to 30 requests to get different information from a stateless backend(REST) but it cannot afford to authenticate the user 20 times right ?
Ok, but while there is cluster of servers, there are schemes that applies to the cluster in that case if it is sticky session the request will always go to the server where it was initially. So server will manage accordingly in stateful for any subsequent request
Abdul Man nan correct, some load balancers have modes that can configure routing to always go to the same server for a given session to manage a stateful application or Filter certain percentage of traffic to move to another server for canary deployment. However in this case if your application in the sticky session goes down in server 1, the load balancer will have to forward traffic to the other server where session doesnt exist and you will force the user to login again. With stateless application you don’t have this problem, hope that helps
I know stateful but I'm new to stateless concept. I have a question: What if I keep session data in a shared service (like Redis) and all of the servers can reach it? Is it possible and if it is, isn't stateful a better choice than stateless?
What's the benefit of a stateless application if you have sticky routing in place on the LB? The one thing I can think of is that you somehow have few people logging out of Server1, but Server[2,3,...] have sessions ending more readily, so you *might* end up with an unbalanced load, but that seems unlikely.
JeezusJuice If you have sticky routing you still benefit from load balancing. if the backend server die mid session, the LB will does its job and point requests to another server. Now it your application is Stateful the user experience will suffer.. the user will either be asked to login on best scenarios or on worse scenarios they will get errors that they can’t get away from until they completely close the client app and restart it. If your backend app is stateless the user will have a smooth experience whether you are sticking the routes or not. Not saying stateful apps are inherently bad there are advantages of using sticking routes and stateful app for performance reasons. Hope that helps
If you were my professor, I would be ready to sit in your lecture for hours. Beautiful explanation
Nikhil Balwani im humbled ❤️ thanks
If he were my professor, I would be sitting at FAANG now.
And you would land any job you want, he exolains concerts with simplicity and efficiency
Even 3 years later this explanation is one of the best on the web. Thanks a bunch mate!
I work full time as a software developer, I stumbled across this while doing some research, and what can I say? you have an amazing character. Well explained :)
Matthew Spiteri Thank you so much for your wonderful comment. Glad to see fellow software developers here. Best of luck !
Been programming over a year and never realized the correlation between REST and Stateless. Mind = blown. THANK YOU.
Man am I glad I found someone that really knows how to really explain something. Great video ! 👍🙋♀️
Thank you Claire 🙏 I am glad you enjoyed the content and found it helpful
2:44
4:41 introduction to the problem of stateful application
5:50 problem: impossible to scale up
6:10
6:51 stateful with load balancer
8:36 stateless example
8:52 Alice is using REST, State transfer
11:14 server sends Alice a *token*
11:34 then Alice will send request always with the token
wow, indented sub-chapters. RUclips should support MD for comments. 🔥🔥
This video makes a lot of other web app concepts so much more clearer. Thanks a mil!
It is worthy of investing 14 minutes of your life. Thanks Hussein
Stateful Example: 1:10
Stateless Example: 8:30
Stateless vs Stateful pros and cons: 13:30
ونعم ابوعلي
JWT changed the world!
This is the best tutorial I have ever seen in my life. I'm awed!.
I can listen to on any topic you teach, I love your teaching style and voice. I am so glad I came across this channel.
nice video! i really appreciate videos like this that talk about real concepts/use cases in a simple way that you can watch on down time. keep at it cause it looks like the videos you're making are really cool!
mollycrime Thanks! I try to give examples where I can from my personal experience working with a technology. Appreciate it!
I'm on a marathon of your videos man. Awesome content
Enjoy 😊
Your explanation is far more better than my college lecturer
God bless you sir, when no one could explain me this thing...u did it in such a simple way. And yeah that accent of ur's its awesome....I can listen to your lectures for hours
Sending a long ass token of appreciation all the way from India !! Great & Interesting explanation.Thank you !!
Shubham Batham sending a signed and time-stamped response token of love to all my subscribers in india ❤️ passcode to decrypt “stay awesome” thanks for your comment!!
with stateless you can read the token with your secret token in server to get basic info no need to search in db or any temporary db in each requests
I am hooked to your videos and as a junior back end developer i am learning a lot seeing things from different perspectives in my job. Thankyou so much
This is the best explaination on youtube
Thank you very much for your videos , I dare anyone to watch you explaining a concept whatever the complexity of the concept and not understand it ❤❤❤
Hey Nasser, your video is simply superb. Hatsoff. As your voice is BOLD and STRONG, one thing i visualised you as you will look like "Vin Diesel". By seeing your DP, then i realise you. Take a Bow.God bless you....:-)
Raghu Vardhan Saripalli Raghu 😍😍 thanks my friend
Great video Hussein. Thanks for the example.
Just logged in to comment a word of appreciation. Glad I found this channel. Beautiful content
Appreciate it ❤️❤️
stateful : 세션변수 이용/ 서버에 저장
stateless: 토큰 사용
Brilliant explanation champ! I've watch about 3 or other videos (each being 2 or 3 times longer) and NOT ONE of them came close to explaining it this comprehensively! Well don and a sub from me!
Well explained. Just watched another video on stateless v stateful and this was my exact question: Wouldnt the ideal be tokenization with API? It seems like a cache has the same issue unless the cache itself is just another word for intermediate database. Thank you for clarifying that this is exactly the case and how this can be accomplished scalably.
It's no longer over my head. Thanks
Sir, you really explained well. I am a 9th-grade student and I was completely able to understand what you meant.
dude just thanks, really helped to quickly get a grasp of it
I am from Electrical background still understand it, nice explanation with diagram.
Plain and simple. Thanks Hussein
TL;DR: Stateful is basically keeping track of the state a user might find itself in (good example would be whether it is logged in or not). Stateless is using an alternative solution (for example using a token response solution) instead of keeping track of the state of the user to keep things scalable (especially useful for example when running a load balancer set-up). The latter often goes in hand with a lot of caching on the back-end side of the app.
your channel is a gem!
Wow ! Simply an amazing explanation, now only I understand what it means 'State Transfer' in ReST, thanks, keep explaining.
Nice explanation, but I'd add that stateless apps can be less costing if some caching is implemented between the DB and app servers.
Correct! Just make sure to add logic to invalidate the cache
just learned about load balancers too bless you ser!!!!!!!!
Very well explained. Good Job Bro. It clears my concept for stateful and stateless 🌹
This was amazing man!! Loved the way you impart things to the viewers!! High Five!
15 minutes ago I couldn't properly articulate the difference between stateful and stateless. Now? I might upload a course on Udemy. :))
Best explain ever..Many thanks
🙏
You explained nicely.. Thanks a lot.
Very well explained! keep the videos coming!
Great explanatio I think nowadays JWT solved the problem of querying db each time we make request.🤔
Awesome video, I understand most of the good points of stateless, I guess making a web application whether a session is an important concern but not important at scaling we probably would use php session as a way to maintain the session or any other programming that gives us this set of tools. but regarding the we wouldn't scale horizontal, thanks man
Kevin Montalvo Flores exactly well said. It is a trade off that you as a software engineer/architect make.
Very good explanation, i want you to teach a whole class of everything i want to learn!!!!
Such a great explanation! Thanks
15 mins of awesome ! Thank you !
Your explanation made me feel really "cool" and "lit" because I was able to understand this 😂 Definitely giving this video a like! 👍
Jordan Theisen Jordan you are cool and definitely lit 🔥 thanks for your comment!
very clear and easy to understand by the excellent explanation. Thank you so much.
It looks like the only difference is: Stateful: save the session info in service. Stateless: save the session info in 3rd party component, say database
Thanks a lot! It was crystal and clear explanation. Easy to understand. Subscribing you!
Thanks for the sub! appreciate you dear enjoy the content
Thank you for simple explanation
I finally understand this! Thank you
Man, you are a perfectionist! Prepare the slides beforehand! It drove me crazy, watching you constantly resizing and moving stuff around!!!
Awesome Video ! Glad I found this - I am VERY NEW to Web Dev and this broke this complex subject down easily :) THANKS
Natalie Schulz Glad you find was useful, checkout the rest of the content in the channel where we explain other software engineering topics by example. Cheers :)
This is outrageously good. Thank you, mate!
I enjoyed it, simple and clear explanation.,
Good. I think the same way a token is stored in the DB and queried by all instances of system, a sessionID (localStorage of any kind of native app local storage) can be used with the same results in computing cost. The main PROs of using stateless is regarding to JWT, a way to validate tokens by the information it contains itself and not by querying the DB. Sessions ID and Tokens can be managed the same in backend and frontend, but for exposure to any client/platform, JWT is the way to go right now also because its granularity about granting specific permissions. Thank you.
Very well made. Thanks for the explanation.
Cool video. But got me thinking a bit. I am not sure I am completely with you in here. Please correct me if this is wrong: the difference in your examples is only the fact that in the 1st example you cache the value in server1 while on the 2nd example you don't cache the values, you always check the token against the db. Isn't a more 'stateless' example a scenario where you can rely on the information on the token to do the validation (jwt)?
João Salgado that is correct, when I mention stateless and stateful in the video I was referring to the application that is hosted on the servers. So in the first case my application is stateful (cant scale) and in the second case my application is stateless. However the entire system still has a state which as you mentioned its in a database. Building a real stateless “system” is very hard because most of the time you probably need to store your state somewhere. Thanks for your comment!
Just amazing explanation bro!
You are a great teacher many thanks!
I try! thank you so much for your lovely comment
Wonderful explanation
i think i got it, in a nutshel, stateful means that the server store information about that "session", but in the stateless the token doesnt have to be saved also? gonna read more about it, great video btw!
Thiago Dias That make sense, you can watch the new video about the same topic with examples. ruclips.net/video/nhwZn6v5vT0/видео.html thanks for your comment
good info. but it is actually possible to scale horizontally with stateful applications. I have done this in the past using a load balancer and sticky sessions. You can use sticky sessions to redirect the user requests to the same server that already has the session for the user.
Correct, you can scale stateful apps for sure with clever logic. However if that server to which the sticky session is locked on is restarted the application breaks.
Really beautiful explanation !! Thank you so much
Thanks for the easy explanation Hussein, I have two questions. 1. The concept of a sticky session is related to stateful design? 2. I am a bit confused between storing(at the client) a session id in cookie and string(at the client) a token.
Thank you for your message..
Sticky session was designed mainly because the backend app is stateful such as building websocket server.. or for performance reasons.. where you want certain requests to always go to the same server (example multiplayer game with 5 players you want all of the players in the same server for performance reason)
I suggest you watch the jwt
ruclips.net/video/cXxEiWudIUY/видео.html
ruclips.net/video/T0k-3Ze4NLo/видео.html
Nicely explained in simple way... with real time login application use case scenario.....
Glad you enjoyed it! I made another video about how Amazon Alexa is stateless maybe you will enjoy that as well ruclips.net/video/zhwMv5RxGew/видео.html
very well explaining, thank you man !
Authentication is an excellent example of just how silly webdev can get.
In a statefull application you logon to server 1, that server checks your credentials, records your loggerd-in status and you get a cookie that refers to that state. This is considered bad because server-2 needs to share some storage with server-1 to know if the cookie is valid and who it belongs to.
In "stateless" application you logon to server-1, that server checks your credentials and gives you a cookie that that server-2 can also verify as being authentic (like a JWT). The problem is that the state that is received by server-2 *MUST* be verified against the same database that server-1 used to create it, for the simple reason that the user may have been denied access since the token was created. You *MUST* verify.
So, statelessness does not really change anything from a serverload perspective,it just sneds bigger tokens because you need to use something like JWT. The hardware on the server side is identical, withidenticalproblems that, let's face it, are not really problems at all. Replicating data among databases is not an issueunless you are a gigantic websitewith hundreds of servers but by then you will have heard of sharding.
Load Balancers can redirect the user to the same server usually by using a cookie, otherwise LB would be useless
this video is best played at 1.5x speed to make him sound like he's talking regularly.
loved it. You made it clear to me. Thanks and yes, I subscribed.
Mukesh Singh Rawat thanks Mukesh! Glad I could help and welcome to the community!! Enjoy the content
best teacher man.
Explanation is good. Thank you .. Would you mind clarifying my doubt ? is this concept used only for a Web applications ? or any Services ? Sorry if its a dumb question.. As I am new to the dev, curious to know. :)
Jyotsna Doddi good question! No it applies to any kind of service that is consumed by many clients. Whether this is on HTTP or raw TCP or any other protocol. As long as the service is consumed via a client, each request should be treated independently from previous requests.. hope that helps :)
IGeometry wow you are quick in responding ... thank you for clarifying...
Jyotsna Doddi :) i try my best ! Checkout the other content in this channel if your new software engineer
You are one of the best I've ever followed but I think you've missed something in this video.
The matter is not about where to store the data (in memory or in DB or in a file or whatever the place is) !! It's all about, DO YOU STORE IT OR NOT for next requests handling purposes?
If the server can process a request without relying on an earlier request then it's STATELESS. If the server needs information from previous requests to be stored (in memory or DB) in order to process the current request then it's STATEFUL.
REST would help to understand that since it's stateless. It sends the STATE of RESOURCE (which could be a USER) within the request every time without saying: "Why I should send it every time. why not just set it in a DB and things will be fine and stateless! 😅"
I think, as a monolith application, no way to not be stateful but as a microservice, you could have one service that is stateful (for authentication and authorization) and other services are just stateless (pure business logic and the state of that logic will be sent through REST or whatever).
What do you think? Do I have a point of view?
That's some cool explanation.
Thank you for the explanation! Enjoyed your use of "lit" and "long-ass"
great video as useful but i know that LB use algorithm like Consistent hashing to ensure that the same user will enter the same server to get benefit of stored data in the cash rather than resend all the info again > iam right ?
That is Correct if your app is stateful that it requires al requests from client to go to it then yes LB can use sticky session algo or iphash to make sure all requests go the server
Excellent explanation! Good job.
Oh, man...Wonderful!
This kind of saved my ass ... Thanks.
Nishant Singh so happy I can help!
Sir, I am just about to start my second year at university, with an assignment to develop a web application and, after watching your videos, I believe I have a higher status than God. XD Jokes aside, honestly, thank you so much!!!
Zacharias King thanks Zach for the love and comment! Best of luck in your assignment!! Take a look at the other content of the channel, more cool stuff for you! Cheers
Very helpful video, thank you!
Great Vids and Great explanation , Love From Indonesia
Steven Humam thanks! Much love to all my Indonesian subs you guys rock!
What's the difference between a token and a cookie? Why is a cookie considered stateful and a token stateless? Is there no record of the token server side? By what process is it authenticated then?
You’re the man! Great video my dude, the examples were spot on. Are you independent or do you work at a software company?
Hantzley Audate thanks buddy for the nice comment! I work at a software company called Esri. I do these videos on the side :) glad you like the content!
Correct me if i am wrong; if use jwt for session authentication(secrets on server itself) i wouldn't have to make so many calls to db(as when using session keys), making it nearly as efficient as stateful?
Saurabh Agrawal that is correct. JWT is better than session keys, JWTs has signature in them allowing server to quickly verify it Without hitting the db. They are also still stateless because the client sends the jwt with each request. So you can restart the server and the client can hit completely a different server and still be served .
With session keys (what we explained in this video we have to verify the key by hitting the db)
Good question
Check out my JWT video JSON Web Token with NodeJS & Postgres Crash Course
ruclips.net/video/T0k-3Ze4NLo/видео.html
Amaaaaaaaazzzzziiiiiiinnnnngg. I think we can also use some cache like Redis, to do this soft authentication.
Awesome video dude! Really helpful but i have these few qs:
- Is this architecture (Client->LB->Server) common or is it just for explanation purposes? If not, what architectures are commonly used? I am guessing other designs would allow for stateful apps to not break as easy (for example, maybe state is saved on same machine so if user reloads then server doesnt have to query again)
- Are developers expected to program the token requests themselves or are there frameworks that do that job
Sorry if these are noob questions, i am trying to learn this to get my first full stack job xD
Farhan Fiaz Alvi thanks Farhan, these are good questions:)
Yes it is common, check out my load balancing playlist or just this video on nginx load balancing ruclips.net/video/WC2-hNNBWII/видео.html
For your second question, Tokens and sessions can libraries that take care of them by I implore engineers to always understand how those library works. The fundamentals are what matters
This might help ruclips.net/video/V3ZPPPKEipA/видео.html
@@hnasr Thankyou! Please stream on Twitch lol, i have too many doubts
I mean what part, those 203 people disliked this awesome video , did not understand... Loosers
Hey , thanks for amazing explanation ! just had a question does token gets stored in database (how it gets generated )and how does it gets expired (when one doesn't login )
But in a stateful app, the server still has to use cookies to authenticate or recognize the user, and when you meant we have to hit the db every time to query for the token, it sounds pretty bad, but isn't that information also cached somewhere to tie in with the cookie expiry, because if were to really look at it sometime a single page might send around 20 to 30 requests to get different information from a stateless backend(REST) but it cannot afford to authenticate the user 20 times right ?
Ok, but while there is cluster of servers, there are schemes that applies to the cluster in that case if it is sticky session the request will always go to the server where it was initially. So server will manage accordingly in stateful for any subsequent request
Abdul Man nan correct, some load balancers have modes that can configure routing to always go to the same server for a given session to manage a stateful application or Filter certain percentage of traffic to move to another server for canary deployment. However in this case if your application in the sticky session goes down in server 1, the load balancer will have to forward traffic to the other server where session doesnt exist and you will force the user to login again. With stateless application you don’t have this problem, hope that helps
thank you so much that's so helpful
Great video!!! Thanks a ton Sir!
Thanks so much for this video tutorial.
I know stateful but I'm new to stateless concept. I have a question:
What if I keep session data in a shared service (like Redis) and all of the servers can reach it?
Is it possible and if it is, isn't stateful a better choice than stateless?
What's the benefit of a stateless application if you have sticky routing in place on the LB? The one thing I can think of is that you somehow have few people logging out of Server1, but Server[2,3,...] have sessions ending more readily, so you *might* end up with an unbalanced load, but that seems unlikely.
JeezusJuice If you have sticky routing you still benefit from load balancing. if the backend server die mid session, the LB will does its job and point requests to another server. Now it your application is Stateful the user experience will suffer.. the user will either be asked to login on best scenarios or on worse scenarios they will get errors that they can’t get away from until they completely close the client app and restart it.
If your backend app is stateless the user will have a smooth experience whether you are sticking the routes or not.
Not saying stateful apps are inherently bad there are advantages of using sticking routes and stateful app for performance reasons.
Hope that helps