That DMV analogy to explain the difference between stateful and stateless was genuinely brilliant. I will carry that one with me throughout my whole career i can tell already... amazing.
Jeno thank you so much, glad I could help thats my goal 🥅 as long as you guys benefit that makes me really happy. Funny that I wasn’t sure that I should make this video since there are ton of REST videos out there. Stay awesome!
@@hnasr you should make videos on EVERYTHIING no matter how many videos there are out there because you have a unique way of teaching which is amazing. keep doing what you do!
I am really happy to find your channel. Telling all my friends and colleagues about your channel and telling them "I found a guru", follow him. Thanks for the awesome videos. You are doing an awesome job
brilliant hussein. keep up the good work. i just started watching your video and i already know that im going to be here for a long time watching many other videos to clear my concepts.
I almost never comment on any video but you really deserve a lot of views, not just for your sake but for people who want to learn in a clear and concise way, it's better for them to find this video than some random convoluted mess.
- Traditional way ( old way) : to load a website, the client app will download the whole thing. Try to build a website in old way with SQL database ( SQL database is really old - it is really painful to build one ) - ruclips.net/video/yAmXgDKu2go/видео.html - REST API : using JSON format file to exchange the data ( when NoSQL appears such as MongoDB, the web developer uses it to build web for prototype quicker than using SQL ) . As he mentions 2 things about REST API : "Representation and State transfer -Representational The resource is a representation or metadata, but the actual backend could be something else and stored differently. An Example, could be a user resource could be represented as a JSON object but it is stored on the backend as relation DBMS tables such as postgres. -State transfer The application server is stateless, and when we want communicate we transfer the current state of with each request. Thus the state transfer. ====================== I think the most confused part is about Stateless : www.interviewbit.com/blog/stateful-vs-stateless/#:~:text=Q.,the%20server%20to%20understand%20it.
Dude another souls fan, awesome! I love those games. Thats why we study back end i think. Something about the challenge or the reward of the hunt or something lile that. Haha
Would like to know your opinion about single wss endpint. Take an Redux. Basically event sourcing. You can metatag actions, intercept them in the wss middleware and send to the server. Same for incomming messages. Look up for the type and call the reducers. You could even sync message signature with protobufs and TS .ds.ts type declarations. You probably know about grpc-web, its downsides and upsides. With all this http/2 and http/3 udp thing i have a feeling that we eventually will get native RPC in the browsers. Whole world is moving into real-time communication. I'm not talking about chats. Im talking even about blog articles and ERPs, CRMs and what not updating UI/data in realtime incrementally. And so... if i don't care/want to deal with REST API maintanance overhead... wouldnt it be neat to have single wss endpoint? Sure... you need to deal with sticky sessions and what not to keep connection live or all that reconnection thing... but... lowering bandwith and reactive UI/UX outweights those challenges. What do you think?
Dzintars Klavins a very interesting take I liked the way you are thinking of having secure web sockets as ingress essentially. Not a conventional way for sure. You are right the world is moving in real time bidirectional communication, IETF figured that out a while ago that is why HTTP/2 supports PUSH and streams (for more throughput) and now HTTP/3 natively in QUIC. So I do share your vision that the web will be more “realtime” and we have the technology to enable it. I have to ask though what are your clients that are consuming the wss? If they are just browsers your solution is clean. If they are more than just a browser than you are in a world of hurt, because you need to teach those clients websockets and you are responsible of these client libraries. That is the problem that gRPC trying to solve they solved it elegantly, unfortunately they didn’t bring it to the web. I don’t personally like gRPC-web and waiting for a more native support. Thats my two cents
@@hnasr Tnx. In my case i have only two kinds of clients. Browsers and native apps. So... im good with browsers, but for native clients i already have a gRPC stubs. So... native clients is the smallest pain. When i started to make some REST API... it's quite easy to do with few grpc plugins... but.. still i somewhat disliked all that implementation, swagger and all that jazz overhead. Writing Sagas for every fetch... nah... Because i had some minimal kafka, ddd, cqrs knowledge... i thought about this idea. I already somewhat implemented it in minimal setup. Still researching, but so far it looks really good to me. Like it a lot. Still its not yet clear how to make something like Swagger to document message signatures for other potential developers or probably external users. Current options is protobufs and TS declarations, but i would like to have something more user friendly.
@Hussein I am posting my understanding of API. Is this correct? please confirm API :- Any piece of intermediate code which allows communication(exchange of data) of other two codes without compromising the security of the two codes.
Hey Hussein, thanks a lot for this great video. But I was just wondering if we use session ids instead of jwt for authorization then will it violate the restful constraint?
Not really, because you will still require to send the session id with every request and your REST application remains stateless because you are querying the DB to check the state of the session
Can some one please explain what Hussein means by 'Cache Invalidation' at 8:42? If we don't store any thing in application memory at the backend, why would we need to invalidate cache? As far as I know, Cache Invalidation means clearing or replacing your cache entries. I'm sorry if this is something really obvious. I'm just starting out on my journey as an engineer. Thank you.
fen1x_ it means if you did store a temporary cache on the server to avoid hitting the database, you need to invalidate it if the state sent from the client changes, caches are great for fast access but cache invalidation is tricky and causes lots bugs.. Hope that helps 😊
That DMV analogy to explain the difference between stateful and stateless was genuinely brilliant. I will carry that one with me throughout my whole career i can tell already... amazing.
Best explanation of rest on the whole web
At last, a clear, beginner friendly explanation about REST ...
Looking forward for the GraphQL video ...
Thanks! GraphQL video up! ruclips.net/video/fVmQCnQ_EPs/видео.html
Representations and State transfer 3:00
Rest constraints 12:14
Example: REST API github api 18:18
I have watched several Udemy courses and none of them made it so clear what REST is than this video. You deserve more views !!
Jeno thank you so much, glad I could help thats my goal 🥅 as long as you guys benefit that makes me really happy. Funny that I wasn’t sure that I should make this video since there are ton of REST videos out there. Stay awesome!
@@hnasr you should make videos on EVERYTHIING no matter how many videos there are out there because you have a unique way of teaching which is amazing. keep doing what you do!
I came across your channel while brushing up on my fundamentals about APIs for my interview. You're amazing!
Great example to illustrate representational and state transfer I think no one could forget it
Thanks Mohd! Glad the REST video was helpful 🙏
Could you share with me yr Twitter account?
Sure @hnasr its on my website
Very knowledgeable. Thinking like an engineer in life
Nasser never say sorry when you speak absolute gold
Only proper thorough explanation out there. All other explanations are very shallow and cover nothing but the syntax. Awesome!
THE MOST AUTHENTIC VIDEO ABOUT REST I HAVE FOUND SO FAR!!!
So simple explanation of about REST.
I have been learning a lot because of your videos.
Glad you like them Joshy!
I am really happy to find your channel. Telling all my friends and colleagues about your channel and telling them "I found a guru", follow him.
Thanks for the awesome videos. You are doing an awesome job
brilliant hussein. keep up the good work. i just started watching your video and i already know that im going to be here for a long time watching many other videos to clear my concepts.
Thanks Riyaz!
I almost never comment on any video but you really deserve a lot of views, not just for your sake but for people who want to learn in a clear and concise way, it's better for them to find this video than some random convoluted mess.
That was a really good analogy for the difference between stateful and stateless!
Amazing explanation. Some years back all bureaucratic offices everywhere where stateful :-)
Thanks a lot for such an amazing video. After watching countless videos, I was still not clear what Rest API actually is. Thanks a lot man
- Traditional way ( old way) : to load a website, the client app will download the whole thing. Try to build a website in old way with SQL database ( SQL database is really old - it is really painful to build one ) - ruclips.net/video/yAmXgDKu2go/видео.html
- REST API : using JSON format file to exchange the data ( when NoSQL appears such as MongoDB, the web developer uses it to build web for prototype quicker than using SQL ) . As he mentions 2 things about REST API :
"Representation and State transfer
-Representational
The resource is a representation or metadata, but the actual backend could be something else and stored differently. An
Example, could be a user resource could be represented as a JSON object but it is stored on the backend as relation DBMS tables such as postgres.
-State transfer
The application server is stateless, and when we want communicate we transfer the current state of with each request. Thus the state transfer.
======================
I think the most confused part is about Stateless : www.interviewbit.com/blog/stateful-vs-stateless/#:~:text=Q.,the%20server%20to%20understand%20it.
You are a living legend!
this is the quality content I looked for, great video
Great explanation with great examples👌 Thanks
cannot wait to watch the graphQL video!
my man, as good as always
Can’t wait till the graph QL tutorial
Thaanks GraphQL video up! ruclips.net/video/fVmQCnQ_EPs/видео.html
Dude another souls fan, awesome! I love those games. Thats why we study back end i think. Something about the challenge or the reward of the hunt or something lile that. Haha
DataSurgeon 369 fear the old blood 🩸! Great to see a souls fan!
@@hnasr We are born of the code, made men by the code, undone by the code. Praise the Solaris!
Great vid!
Hire meeeeeeeeeeeeeeeee! I would love to learn from such an awesome and knowledgeable person!
Thank you!!! Your videos have helped me so much
Would like to know your opinion about single wss endpint. Take an Redux. Basically event sourcing. You can metatag actions, intercept them in the wss middleware and send to the server. Same for incomming messages. Look up for the type and call the reducers. You could even sync message signature with protobufs and TS .ds.ts type declarations. You probably know about grpc-web, its downsides and upsides. With all this http/2 and http/3 udp thing i have a feeling that we eventually will get native RPC in the browsers. Whole world is moving into real-time communication. I'm not talking about chats. Im talking even about blog articles and ERPs, CRMs and what not updating UI/data in realtime incrementally. And so... if i don't care/want to deal with REST API maintanance overhead... wouldnt it be neat to have single wss endpoint? Sure... you need to deal with sticky sessions and what not to keep connection live or all that reconnection thing... but... lowering bandwith and reactive UI/UX outweights those challenges. What do you think?
Dzintars Klavins a very interesting take I liked the way you are thinking of having secure web sockets as ingress essentially. Not a conventional way for sure. You are right the world is moving in real time bidirectional communication, IETF figured that out a while ago that is why HTTP/2 supports PUSH and streams (for more throughput) and now HTTP/3 natively in QUIC. So I do share your vision that the web will be more “realtime” and we have the technology to enable it.
I have to ask though what are your clients that are consuming the wss? If they are just browsers your solution is clean. If they are more than just a browser than you are in a world of hurt, because you need to teach those clients websockets and you are responsible of these client libraries. That is the problem that gRPC trying to solve they solved it elegantly, unfortunately they didn’t bring it to the web. I don’t personally like gRPC-web and waiting for a more native support.
Thats my two cents
@@hnasr Tnx. In my case i have only two kinds of clients. Browsers and native apps. So... im good with browsers, but for native clients i already have a gRPC stubs. So... native clients is the smallest pain. When i started to make some REST API... it's quite easy to do with few grpc plugins... but.. still i somewhat disliked all that implementation, swagger and all that jazz overhead. Writing Sagas for every fetch... nah... Because i had some minimal kafka, ddd, cqrs knowledge... i thought about this idea. I already somewhat implemented it in minimal setup. Still researching, but so far it looks really good to me. Like it a lot. Still its not yet clear how to make something like Swagger to document message signatures for other potential developers or probably external users. Current options is protobufs and TS declarations, but i would like to have something more user friendly.
Excellent work !!!
@Hussein
I am posting my understanding of API. Is this correct? please confirm
API :- Any piece of intermediate code which allows communication(exchange of data) of other two codes without compromising the security of the two codes.
Hey Hussein, thanks a lot for this great video. But I was just wondering if we use session ids instead of jwt for authorization then will it violate the restful constraint?
Not really, because you will still require to send the session id with every request and your REST application remains stateless because you are querying the DB to check the state of the session
@@hnasr thanks Hussein, just watched your jwt authentication video, that cleared everything. You are doing a great job man. Thanks for the help.
Do you have a course or book to recommend on REST?
very informative.
akshay gh thanks! I was hesitant to post this video since there are so many REST videos out there .
Can some one please explain what Hussein means by 'Cache Invalidation' at 8:42?
If we don't store any thing in application memory at the backend, why would we need to invalidate cache?
As far as I know, Cache Invalidation means clearing or replacing your cache entries.
I'm sorry if this is something really obvious. I'm just starting out on my journey as an engineer. Thank you.
fen1x_ it means if you did store a temporary cache on the server to avoid hitting the database, you need to invalidate it if the state sent from the client changes, caches are great for fast access but cache invalidation is tricky and causes lots bugs..
Hope that helps 😊
@@hnasr Oh...this clears things up. I love your channel. You're an inspiration! Thanks for the quick reply 👍
Awesome Possum
David Ross someone made it to the end ! Stay awesome 👏
Sorry, I'm digressing...how did u get a GC if u came to USA in 2015 ! :D
Can you make a video about couchbase database?
Yes! Its on my list 🙏
@@hnasr Thank you!! 🤲🙏
What do you think about the JSON API Specification jsonapi.org which added ideas of sparse fields and relationships?
🙏🙏🙏🙏🙏
I like your tutorials but I have a suggestion you voice goes high, sometimes very high and suddenly drop it to very low. It's really irritating.
im sorry but i find difficult to listening to your accent. please change it back to indian.. no offense or pun intended..