Wrapping Up

[00:00:00]
>> I'm curious wondered like the cost of doing something like this. Is there one of the downsides of like keeping your state in a server?
>> So the question is, what is the cost or the downside of keeping your state in a server? Let me preface that with this is something I would be very careful about doing.

[00:00:18]
In the real world in the sense of I would have to have a good reason to do this. But at the same time, that WebSockets are pretty cheap and state itself, provided we're not dealing with like a massive amount of state is actually pretty small in terms of the foot print.

[00:00:40]
Even to the point that within Redux or NgRx you can actually, I know with NgRx you can break your state out into these individual smaller subsets and then dynamically or lazily, lazy, load them into your store. I typically avoid doing that. Because state in and of itself is so small.

[00:01:04]
The footprint is so small in comparison to the rest of the app. I just put it in one place. And so I would say, when you're looking at a single state tree as just a JavaScript object, it's very small. And so I think, the cost of it is also very small.

[00:01:23]
But, I think there has to be a good functional reason to do this. And I can think of a couple of them. I think being able to do remote assistance, remote troubleshooting, there's good reasons for there obviously take security seriously. But the cost itself in terms of the transport cost over the network is pretty small.

[00:01:49]
And I think moving a single state tree across the Internet is also pretty small. So I would obviously, you'd want to keep an eye on that. But this is not certainly I would just do as his default like every app that I get now has a remote real time back end.

[00:02:07]
But it is possible to do this in like pieces or a hybrid approach, where this becomes very effective. So to answer the question, I think if the user interaction would benefit from it, I think the cost is minimal. I think you would just have to have a good reason to do that.

[00:02:25]
>> So when we're talking about this observables pattern, you were describing how we need to like switch our thinking from input outputs like output input, and I'm curious just like, I'm having trouble with that mental model. I'm curious if you could like walk through how you apply that mental model to this use case right here.

[00:02:44]
>> So, the question is, based on a comment that I made yesterday, around we need to switch our paradigm from input to output, to output to input. How would I apply that to this particular example? So let's think about this for a second. Let me pull up another instance of this And I'm just going to interact with this.

[00:03:26]
For just a second, notice that on the right hand side, I'm not having to do anything. It's that it is receiving information to the application, and it's responding to it. And so when I talk about think of it from output to input is that when you think of a stream, the nature of a stream is that it's outputting something.

[00:03:56]
And so when you shift your mind to start to think of everything as a stream of data. That there's already an initial output, really what you have to focus on is, where do I want to put that stream into my application. And so in the right hand side is that we're pushing data to it.

[00:04:21]
Is that data is being outputted from the server and pushed into the string. And so when you start to think about interactions is not, I'm going to pull this data to me, but rather I'm going to allow you to push data to me, where I'm going to respond to the output of some event.

[00:04:47]
So you just sort of think of things in terms of events, capturing them and then figuring out how you want to input them into your application, and what shape you want it to be in. And so in this case, as we start to go through this, you can see on the right hand side, that we're interacting.

[00:05:07]
We're capturing even that output of those events, translating into something else, and then pushing that into the right hand application. But even here, if I go like this I'm pushing data or I'm outputting events that are being picked up on the right hand side and being responded to.

[00:05:29]
And so it's just everything is a stream. There's always output. You just need to figure out what you want to do with it and how it's going to affect your application when you input it into it. So it's very simple to say it like just go from input to output, output to input, and your problems will be solved.

[00:05:47]
I realized that two slides does not a paradigm shift make, that I'm constantly having to refine how I think about that. And finding new ways to apply in this case, through space and time is what happens if I'm actually pushing things, or I'm outputting events and data over the internet through space and time.

[00:06:10]
What does that mean? And this is where you have this particular example. Hopefully that was helpful?
>> Yeah, definitely. I think I was stuck thinking when you're looking at the manual step, like thinking of that as a piece of input you're sending, but definitely seems clearer to talk about that response coming from the server as output to the client.

[00:06:28]
>> Yep. I was always going to dispatch something that there is some, but even this, when I click step I'm actually dispatching, I'm creating output. And so it just helps you to think of, instead of saying, I'm pulling this to me, that I'm pushing things into the application to be responded to.

[00:06:47]
And so this concludes Enterprise Patterns featuring TypeScript, we've covered a lot of material, and I just wanna thank you from the bottom of my heart for spending this time sharing and learning these concepts with me, and please take it, apply it. And if you do something cool, please reach out to me on twitter at simpleton, I'm accept DMs and I would love to hear what you build.

[00:07:12]
I would love to hear about your successes, failures, frustrations, and as well keep your eye on the repository, as I will add in some additional resources that will help you along your journey to become a better all around programmer. So thank you so much for being here. Thank you for joining me on this journey.

[00:07:31]
I wish you all the luck in the world in your career, in your pursuit of software.