So if you've worked with Angular for any amount of time, you're probably aware that one of the best ways to work with a backend is through a data API, and in particular, a data API that accepts and returns JSON data. Now, this obviously isn't the only way that we can work with data in our Angular application, but it's ultimately one of the easiest and most flexible ways to go about it.
So when we do this, what we're effectively doing is we're building two different applications, two distinct and separate apps. And one of them is for the client side. That's the Angular application. And it's really just concerned with the user's browser. And then we have our server side application, which is built with something like Node.js or Ruby on Rails or PHP or whatever server side language or framework we like.
And then we connect these two applications through a data API. And that communication happens via XHR requests from the client to the server. So when we build our data API, chances are that we're going to want to build a RESTful API. And one of the core tenets of REST is that things should be stateless. And so what this means is that when we construct a request that goes to our API, that request should always return the same resource.
And with traditional roundtrip authentication where we set up sessions to check if the user is authenticated, well that sets up some state on our server, which can effectively change the result that we get back for a given request. And so this breaks that core tenet or REST being stateless. And then there's some issues related to how modern application ecosystems work. And so things are changing with the way that we build and distribute applications these days, and this has some implications for authentication.
So for instance, we can't easily share a user's session across multiple servers. What we're seeing more and more these days is that an application is not going to use just a single server for all of its resources and all of the things it needs to do, but rather it's going to rely on multiple different servers. So with traditional authentication, everything works fine if we have just a single server, but as soon as we get more than one involved, then things get tricky.
There are ways to share sessions across different servers, but it's not really easily done. Another issue is that cookies don't flow downstream. So another pattern that we're starting to see in modern application development is that our server--our application server--might rely on a downstream server or multiple downstream servers to get its work done. Now, the problem with this is that since we need cookies to properly authenticate in a traditional authentication setup, well, cookies can't flow to those downstream servers so we can't really go beyond our single application server.
And then we ultimately want to be able to share our API across different applications. We want to be able to write an application for the web and then maybe also a mobile application. And then, who knows, maybe even a desktop app. But we don't want to have to rely on different data resources for each of those applications. Instead, what we want to be able to do is use that same API across our different apps. And with traditional authentication, this is just pretty tricky when we have to deal with cookies.
So those are some of the issues that are more related to the server side, but what about the front end? What about Angular in particular? Well, like we talked about, in a good Angular setup, our Angular app doesn't have any kind of stateful connection to a backend. Rather, it's going to fulfill its data needs, whatever those needs may be, for sending data or receiving data, through XHR requests to the API.
And so because of this, because of this statelessness, we need to take some things into consideration. So firstly, we need to be able to limit access to certain routes in our Angular app. So certain parts of the application should only be accessible to users who are authenticated. This is just sensible application design. So even though we don't have any kind of stateful authentication going on, we still need to make it possible for Angular to know that a user is logged in or not.
We also need to be able to show or hide certain parts of the user interface depending on the user's authentication state. So for example, we might have a spot in our navbar where the user's name and profile photo show up. Well, we need to be able to either hide or show that depending on whether or not the user is logged in. So again, Angular isn't connected in a stateful way to a backend.
And given this, how can Angular know whether or not the user is authenticated if there's no kind of session or stateful connection made? And even more fundamentally, how are we able to do any authentication at all if we don't involve sessions and cookies and state? Well, it turns out there's a really nice way to do this with a newer standard called the JSON Web Token. And we'll talk about the JSON Web Token and what it's all about in the next lecture.