[00:00] In this lesson, we'll examine how a running perspective session fits into the rest of the ignition ecosystem. Now, this isn't critical information to building and deploying applications with perspective but it should give you some additional information on how the module works, which hopefully can lead to helping you make better decisions while designing a project. So say you have a running ignition gateway on a server somewhere, and it's connected to some devices some databases, and some other things it can request data from. Now say a user launches a perspective session and a web browser or it could be the mobile app or a perspective workstation. The exact approach doesn't really matter too much. The point here is that a user on a separate device starts up a perspective session. As with most things in ignition, when some subsystems such as our session here requests information from an external system, the request is sent to the gateway which then handles the retrieval of that information.

[01:04] For example, say the perspective session is displaying a temperature from a sensor somewhere. In that case the session just pulls the gateway for the data depending on how that data is being retrieved normally the gateway may already have it sitting on a tag but if not, then it has to go and query for it or make some sort of call to retrieve it. But generally speaking the session only ever requests the information from the gateway. It doesn't go and retrieve the information directly. Instead, the gateway is always acting as an intermediary. Now, when we talk about perspective sessions really there are two sides to a session. The side you're familiar with at this point is the front end of the session. This side is what your users will interact with and also see. Having a front end would imply that there's a back end, which there is. However, it's not necessarily sitting on the same device as the front end. It's actually running on the server. The reason for this is related to the tech stack we're using.

[02:03] I'm not going to delve too deeply into the details but the main takeaway is that there is a side of each session that runs on the server. It's also means that data sent to the session from the gateway is actually sent to the back end of the session which can then process the data and notify the front end if it needs to. Now this means the two sides put some effort into mirroring each other. For example, say the front end is rendering a checkbox component. All components have properties that determine their state and sometimes those properties change how the component looks. So our checkbox has a select a property. And right now it's set to false because it's not checked at the moment. The front end is aware of the selected property and the false value it has. The back end also knows that the checkbox has a false value for its selected property. The front end and the back end are both aware of the properties of all the components within the session. And they're also aware of the values on all those properties. The two sides have a fairly robust synchronization system.

[03:04] So changes to a component property on one side will cause the other side to update its value appropriately. So say our user clicks on the checkbox which should change the selected value to true. The front end knows the user did it because while they clicked on the component, that in turn changes the selected value and renders the little check mark on the component. The front end then notifies the back end that the value on the select a property of the component changed. Thus, the back end updates, the select value on its side. Now this synchronization is bi-directional meaning changes to the value on the back end will update the front end also. Since the back end is responsible for the session's data management, this means things that can automatically change the value on a property, such as a property binding actually change the value on the back end allowing the synchronization system to then notify the front end. So for another example, say we have a tag binding on the selected value of our checkbox and the gateway just informed the back end that the value on that tag has changed.

[04:07] So now it should be false. The back end updates the property value on its side which means the synchronization system will then update the value on the front end. The front end receives the new value the next time it renders the check box the check mark is removed and the user sees the false value on the component. Okay, so we see how this works but what does that actually mean for you? Is it important that, you know, a session is made up of a front end and a back end and there's some synchronization that happens automatically between the two sides? Well, not really, if I didn't mention it to you you probably would never realize that, that's how it works. That's just how seamlessly it blends in. However, the idea that each session has a back end side running on the gateway is useful. We're back here at our system diagram. Now say in a perspective view somewhere you have a button component and when the user presses the button, it calls a Python script.

[05:04] The script likely doesn't execute where you think it does. It actually executes here on the back end, not the front end even though it was triggered by a user doing something to the component on the front end. And that's because, well, it can't. User scripting, can't run in a browser and that's honestly just how web browsers work. They have a lot of security measures to make sure that pages they're displaying don't run arbitrary and potentially malicious code on the system hosting the browser. However, the front end is allowed to send a notification to the back end, saying that a script was triggered. So the back end knows the script is triggered and is able to execute the code. Now, this approach has two ramifications. First scripts use the resources of the server not the system hosting the front end. Say you have a script that does some heavy calculations. Those calculations will probably use a significant amount of system resources. Now say you call that script from some interaction in a perspective session. Okay, so the server runs the script and finishes the calculations.

[00:00] [06:07] Now a single instance of your session has the result of that calculation and a single instance, isn't really a concern but this whole process is sort of multiplied by the number of active sessions, trying to run the same code. So you start to run into this problem where the system is doing a lot of repetitive work and potentially running that same script over and over again, getting the same results which ends up being really wasteful. Even worse this could potentially lead you towards performance or just resource issues. Now, in cases like these, if you have some sort of heavyweight scripting that needs to run. It's advised to try to run the script only once at a time and then distribute the results. That way the system's doing less overall work. So you could have a gateway event script or a tag chain script to run the calculation once and then store the results somewhere that's easily accessible such as a memory tag or even in a database table.

[07:00] From there, you can use a simple binding to retrieve the information which scales considerably better in cases where you have a large number of sessions running at the same time. The second ramification you'll want to be aware of is that well, your scripts do in fact run in a different environment than where they're called from. For example, the Python standard library and also ignitions built in system library have functions that allow you to interact with the local file system. But local is a peculiar term in this case, because again, they always run on the server. So those functions would allow you to interact with the file system on the server not the system that's hosting the front end. Well that about wraps things up. Hopefully now you have a better idea of what's going on when a session is running. Those two scenarios we illustrated here aren't very common, but there's something to be aware of as you could accidentally design your project in such a way, that you do run into those issues.