This video uses the model created in the previous video to retrieve data from the backend. We learn how to use the kosFetch utility, which creates a fetch-like experience for UI development. We will map the data result to a model and update properties, and we learn how the KOS model lifecycle can be used to load data consistently.

So that’s all well and good, but what does that actually give us?

So we have this model and the interface, more importantly, that we can start working against.

We could have enough there that the contract is established that I know that this model represents certain parts of data that is really just a projection of the back-end state.

This point is static data, but the point remains the same.

We haven’t done any of the implementation of how to get the data out of the back-end yet.

We haven’t hooked in the UI yet, but the data model itself is sound and we know that we can make use of it.

So we could actually go into our model and print out a little bit more information if we wanted to.

Let’s say, for example, here I can just say thislogger.warn.

We’ll give the app ID and pass it in here.

So when we take a look at the UI and refresh it, we see the data that’s available to us.

Again, not very exciting, but we can build on this.

So the next thing that we want to do is look at how we’re going to start getting the data off of the back-end.

So we’ve got a model in place, we can go back to our model code, and we can say, create a new folder where we’re going to start putting our services.

So in here, let’s create our SystemInfoService, and all I want to expose here is the code that I need to access the back-end.

So I’m going to export a function here called GetSystemInfo, and it’s going to be an asynchronous method, it’s going to make a call to the back-end.

And let’s take a look again at what we’re going to be getting back.

If you recall, there is a bunch of payload in here that sort of says, I’m going to get all of the status and the version and all of the information, but the important part is what’s encapsulated here in the data section.

And again, what I like to do is, within my services, I like to create an interface that represents that response.

So I would say, export interface SystemInfoResponse, it’s going to look a little bit like this.

So when I save it, it’s going to autocorrect it for me, and what I’m going to do is just substitute in the types rather than the static strings.

So now I’ve got a response, and I can start to grab that data.

So going back to the endpoint, we can see that it’s going to be called here, is the API KOS descriptor system app.

As I go into the service, in most broader applications, you can use the Fetch API.

You can see with the dispenser, we have a slightly different setup in that communication between the front end and the back end via the model is happening over WebSocket.

So Fetch isn’t going to necessarily work, and we didn’t want to expose the WebSocket interface directly, so we created an abstraction that allows for HTTP-like communication over the WebSocket transport.

So what that means is that I can, in a very familiar way, say, get a response, which is going to be awaited, and then this is the first time we’ll take a look at a utility called KOS Fetch, and in there, we need to say what URL do we want to go to.

Because it likes to have a protocol, we can put in a KOS protocol, but we can put in anything at that point.

Again, when we look at generating out models and all of the tooling that’s available, you’ll see how this becomes a little bit easier to manage.

But for now, just understand that the KOS Fetch requires a basic protocol, and we’re using the KOS protocol as a placeholder here.

So if you’re familiar with the Fetch API, I get a response.

It has a response object that it returns, and I can do things like, if the response is not okay, then I might throw a new error that says I couldn’t get the information.

Otherwise, I’ll return JSON, but to do that, much like the Fetch API, I’ll say the JSON is equal to await response.json, and this thing is returning a KOS service response with a payload of the system info response.

KOS service response is provided by the SDK, and it really encapsulates the data and status and all those messages that are wrapped around all of our HTTP payloads.

Basically, I have a JSON object that I can await on, and I’ll return JSON.data.

I’m just complaining because I need to say it could also potentially return null.

So I’ve now got a service here making a raw KOS fetch call.

It’s going to get the data from this particular location, do a bit of error handling, and send back the data as is defined in the payload here.

Now, where do I use it in the model?

There are some convenient places that I can do this.

We talked before about how every model has a lifecycle.

When the framework initializes a model, that’s going to make sure it goes through its initialized phase where you can collect some low-level information.

There is a load phase, which is generally reserved for where you’re going to do things like fetching data from the backend or from an endpoint.

Then there’s a ready phase, which is really just a final check to make sure that all of its dependencies are in place.

For now, the only thing we need to implement is the load method.

Now, load is asynchronous because we’re going to go fetch some data here.

We’re going to say the response is equal to await getSystemInfo that we created before.

In terms of writing solid code where we have single responsibility for any particular method, it’s one of the reasons why I create this service layer is so that I can encapsulate it in its own function, reduces the complexity in the model, but it also allows me to keep those concerns separated.

Now, I’ve got a response that’s coming back, and it’s going to have some data in it.

If I get a response, then I want to take the data that’s in there and update the model.

Again, just in terms of keeping things separate, if I were to create a private function here, which is just going to be updateModelData, and let’s say it’s going to take in an object which has my app class and my app ID, and what it’ll do is update the values.

This basically allows me to take the data that I’m getting from here and construct an update that I want to be able to create.

In this case, I’ll say this updateModelData, and it gives me the opportunity to map in the data as I need to.

I could, for the purposes of in a regular situation, I would probably create a mapping file, so we could again encapsulate the mapping logic into a separate place, but for now I’ll just say that the app class is going to be responseKOSAppClass, and the app ID is going to be likewise set there.

Again, what’s happening here is the data is coming back, it’s going through the lifecycle, and then updating the model with the new data.

Again, if I reload the page, everything is there.

I can go into the network tab if I wanted to and take a look at the WebSocket events that are now going back and forth.

Clicking on here, going into WebSockets, I do a search for the events, which is the WebSocket connection that was established by the framework.

I can see the messages going back and forth here.

In this case, there is a GET going to the system app, and the response is coming back with all of the data as we expected.

You don’t generally need to live in the low-level WebSocket events.

I just wanted to show it for instructive purposes to see that the actual request is being handled.

What’s important is that I didn’t have to tell it to do this.

The framework was driving that for me, so it was going through making sure that the load methods was getting called at the appropriate time when all the dependencies are realized, and then it’s updating all of the values.

Bye!