Jeff Terrell: Okay.
Jeff Terrell: We'll get started here.
Jeff Terrell: That was our long by the Foo Fighters as an intro music no particular connection to today's lecture. But just because I like it.
Jeff Terrell: Great song great video just just something fun.
Jeff Terrell: puts me in a good mood. Anyway, I don't know about y'all. All right, I'm
Jeff Terrell: Only announcement really today is the grades are up to date as of yesterday afternoon. So I have caught up with all of the mentor meetings and everything else.
Jeff Terrell: We talked about assignments last time. So I'm not going to go into that today. But any questions, concerns, anything we should talk about today. Before I dive in,
Jeff Terrell: Okay.
Jeff Terrell: Alright so today what I'm planning on doing is continuing our content from flex box from last time for Monday.
Jeff Terrell: And I'll just briefly review what we talked about on Monday, and then dive into the basically how to size flex box things out items can stretch and shrink to fill the available space.
Jeff Terrell: This is part of why it's called flex boxes because it's flexible this way.
Jeff Terrell: We'll talk briefly about grid layout and responsive layout and that will conclude what I intend to talk about for layout and then we'll move on to
Jeff Terrell: What I think will be the bulk of the lecture today, the client server architecture. It's a bit of a pivot from actually what I intended to talk about, which is infrastructure, but we'll get there and I'll talk about why I made that pivot when we get there.
Jeff Terrell: Okay. So to review from last time what we talked about with flex box and we also talked about some other things with layout like different set of display types.
Jeff Terrell: Box lame box physical box layout and or sorry block layout and in line and flow floats. We talked about those things, then we got to flex box and what we talked about with flex box last time.
Jeff Terrell: Was I remember that the element, the HTML element with the flex display property, aka display colon flex is called a flex container and the items, a direct children within that element are called flex items. And those are the things that are laid out according to flex box.
Jeff Terrell: Flex box enables flexible dimensions in one primary dimension, called the main axis and which accesses the main access is controlled with the flex direction CSS property and that could either be row or column.
Jeff Terrell: The alignment along the main access is controlled with the justified content CSS property that could be flex start flex end space between space around
Jeff Terrell: Stretch center. These are all options for
Jeff Terrell: For justify content.
Jeff Terrell: And then the other access the perpendicular to the main axis is called the cross access and that alignment is controlled with the line items CSS property which can also contain values like space or sorry, flex start flex and stretch center.
Jeff Terrell: Baseline, I think, was the other option that we saw with a line items where the text baseline is actually aligned
Jeff Terrell: And I have linked here. I don't think I'm going to show them again. But the demos for flex direction and flex alignment are here. We saw that Monday. So I don't think we need to review that so quickly so soon.
Jeff Terrell: Okay, but now I want to talk about the new stuff with flex box that I haven't covered before
Jeff Terrell: By the way,
Jeff Terrell: Let me mention briefly that I did look at all the responses from the takeaway questions last time and feedback and some of you basically kind of knew. Most of this stuff already yet seen it before, maybe in 426 or maybe elsewhere.
Jeff Terrell: And so maybe this content was little bit boring to you but various other people found it really useful to learn about layout and I think even some people who have taken for 26 found it useful to just get a an overview of everything.
Jeff Terrell: Kind of at a high level, with layout. So
Jeff Terrell: If you're bored by this. I'm sorry, I can't
Jeff Terrell: Talk about anything with regards to lay out that isn't going to probably bore. Some of you.
Jeff Terrell: So I'm trying to kind of do a happy medium year. But anyway, so moving on flex basis is the next thing I want to talk about with respect to
Jeff Terrell: Flex box basically flex basis is the first of three things that will see that affect how individual items can shrink and grow within a flex box container.
Jeff Terrell: And basis is the first. First thing to talk about here in this controls how much initial spaces given to a flex item.
Jeff Terrell: Along the main axis. So it's only controlling the main access and this is why we say that flex box is although it has some control over the cross axis, we really say it's it's about being flexible in along the primary axis not you know basically in one dimension, not in two dimensions.
Jeff Terrell: So this flex basis, as well as the next two things. It will see are only controlling things along the main access and flex basis is talking about how much initial space that we give each item in the container.
Jeff Terrell: This is a CSS property that you apply to an item to a flex box item, again, that is indirect child of a flex container.
Jeff Terrell: And this is only about the initial space, the final sizes affected by growing and shrinking as well. And we'll talk about those next.
Jeff Terrell: But the default value is auto and this just means make it whatever size, it needs to be to fit its content. So if you had a lot of text in there. This would be wider assuming flex direction of row if you had just one word in there. Maybe the with the basis with would be smaller.
Jeff Terrell: You can also give it a specific size like 100 pixels or two relative them's
Jeff Terrell: So those are things you can do. But that's flex basis. That's the first two or three things we need to understand to understand how flex items can grow and shrink.
Jeff Terrell: Okay, flex grow is controlling how an individual item may grow to fill the available space.
Jeff Terrell: I'll show examples of this in just a minute, you can disable growing completely by setting flex grow to zero.
Jeff Terrell: For an item.
Jeff Terrell: And you can enable it by having a positive number four flex grow.
Jeff Terrell: Generally speaking, you should probably stick to positive integers here. I think if you have like less than one like 0.6 or something I don't quite know what it does. There it was a little bit surprising to me but
Jeff Terrell: Anyway, if you just say 123, that kind of thing. That's fine. So what is the number actually mean
Jeff Terrell: Basically, the way the algorithm works is first you determine the initial size of all atoms all items from the flex basis values.
Jeff Terrell: So again, this is by default auto
Jeff Terrell: And what that means is the browser is actually going to figure out what is the automatic width of each of these items and then the browser figures out what is the width of the container.
Jeff Terrell: And if the width of the container is greater than the sum of all of the size of the items then some things can grow to fill the available space.
Jeff Terrell: The things that grow are the things that have a flex grow value that is a positive integer positive number, I should say.
Jeff Terrell: And what happens is the browser is actually going to just give the treat these numbers as like relative weights and divide up the available space, according to what the individual weights are so for example values of the flex items.
Jeff Terrell: For the flex grow property. If the values are two one in one, that means that the first item gets twice the space of the other two. So basically the available space in that case gets divided up into four. The first item gets to allocations and the second and third items each get one allocation.
Jeff Terrell: Alright so flex grow one is kind of a simple value to think about. I'm just like, let this grow to fill the available space and it will share equally with anything else that has flex grow one. So that's a simple value to us there.
Jeff Terrell: Alright flex shrink is kind of similar.
Jeff Terrell: Flex shrink will shrink items if the main axes overflows. So in other words, if the sum of all of the basis width of the items is greater than the width of the flex container.
Jeff Terrell: And I said, with what I really should say is whatever dimension that the main access is running along
Jeff Terrell: Then flex shrink will enable some items or whichever items, it's it's set on to shrink, so that the flex container doesn't overflow.
Jeff Terrell: You can set lecturing to zero to disable shrinking.
Jeff Terrell: And shrinking is also a little bit harder to to demo or it can be a little bit confusing to play around with in your dev tools because
Jeff Terrell: Shrinking will take into account the minimum size of items. And so it may seem broken or inconsistent or weird in what you're running into is the constraint of, you know, one or more of these items that we're trying to shrink is actually not shrink double beyond a certain amount so
Jeff Terrell: Maybe the other items can shrink to accommodate everything and remove the overflow or maybe you just can't shrink enough to actually remove the overflow and the flex containers actually overflowing.
Jeff Terrell: And so if something is ignoring your flex shrink setting that's why
Jeff Terrell: Finally, before I demonstrate these three things.
Jeff Terrell: There is a shorthand.
Jeff Terrell: Just the flex property actually combines all three of these individual properties. So for example, if you said flex one one auto what that would mean is flex grow as one flex shrink is one and flex basis is auto
Jeff Terrell: And you can also have further shorthand. Besides that, you could say flex initial and that would be equivalent to 01 auto. In other words, flex things do not grow.
Jeff Terrell: Things do shrink if need be.
Jeff Terrell: Flex auto which
Jeff Terrell: I'm actually not sure what the default is here.
Jeff Terrell: I guess maybe it depends on what the default values for each of these individual settings are but flex auto is equivalent to both growing and shrinking and again an automatic basis.
Jeff Terrell: None is equivalent to do not grow or shrink.
Jeff Terrell: And a number has the following shorthand. Basically it means that
Jeff Terrell: You can grow and shrink.
Jeff Terrell: According to whatever the allocation that you gave it whatever the weight that you gave it is, but the basis is zero.
Jeff Terrell: So if you have one item that needs to be a lot bigger because maybe it has more content in it then.
Jeff Terrell: That that's going to get ignored. It's still only going to get a basis of zero. And so each item is going to be the same width, regardless of what it might need to be to accommodate all of its content.
Jeff Terrell: I'm not quite sure how minimum went to interact with a basis of zero. That'd be something to play around with. If you're curious about it.
Jeff Terrell: Okay, let me show a demo of this. And then I'll show you a fun game to play for flex box and then I'll stop there. Any questions I have, I don't see any questions so far so
Jeff Terrell: Okay, let me see here.
Jeff Terrell: All right. Inspect Element, by the way, in Firefox. This is not a very
Jeff Terrell: What's the word discoverable feature of Firefox, but if you right click and you hit Q, it'll inspect the on it so interesting keyboard shortcut there.
Jeff Terrell: Okay so flex sizing I what I have here is a slice container which is the div with ID rapper.
Jeff Terrell: And then I have three items. As you can see, one is going to have a bit of a bigger basis because it has wider has more content.
Jeff Terrell: The flex direction is row, which of course is the default of flex layout in a browser.
Jeff Terrell: Let's look at layout here.
See here.
Jeff Terrell: So if you didn't like if we didn't have styles to find where these things are pretty obvious where one stops and the other begins, you can actually hover over each one of these things here to see, okay, what exactly is this item. Where does it stop start and stop.
Jeff Terrell: So, and it will tell you specifically you know this container has three flex items in it. In this case also, if you specify if you look at one of these things, it'll tell you how much it grew or shrink right now it's showing you that the basis and the final are the same at 28.22 pixels.
Jeff Terrell: This one has a bigger basis. It's 65.8 remember basis defaults to auto so it's looking to see how wide the element needs to be to display everything. And that's the basis
Jeff Terrell: So this third item, of course, is going to be having a big basis.
Jeff Terrell: But let's actually set some properties here. So let's set a rule that says special gets. Well, you can do it this way. So the flex shorthand, remember, is grow shrink basis.
Jeff Terrell: We could set the basis to
Jeff Terrell: 100 pixels.
Jeff Terrell: Alright, so now we've just sort of static Lee sat what that
Jeff Terrell: Should be
Jeff Terrell: We could set the grow. So if we said grow to one. It's the only thing that has any flex grow. Remember, this is the style only for this item because we, it's in the special selector.
Jeff Terrell: And so since it's the only thing that has a flex grow property set to a positive value. Then as the only thing that grows and therefore, what happens is that
Jeff Terrell: It has a certain basis which is 200 pixels. But then the item was sent to grow. We see the flex growth of this item is another hundred and 85.15 pixels.
Jeff Terrell: So that's kind of cool. We could actually take that out and say,
Jeff Terrell: I know
Jeff Terrell: And then we would see the basis is smaller, but it grows up to the same amount 380 5.15 pixels. Again, it's going to fill all the available space.
Jeff Terrell: Okay. What happens if we let's set that back to where it was. Everything's the same
Jeff Terrell: Let's set all of these actually to
Jeff Terrell: Well, if we said P that's only going to affect
Jeff Terrell: Let's see, we can disable that. There we go.
Jeff Terrell: If we set everything to grow equally.
Jeff Terrell: Then we see not that they all three have the same width. Right. They started out with different basis as bases. And so this third item is actually going to be bigger than the other ones.
Jeff Terrell: The basis was 65.7 so the final sizes 184 but it grew by about 119 which is the same amount that both of these grew by about one 118 point nine eight they all grew by the same amount. Give or take 100th of a pixel
Jeff Terrell: But their final sizes are different right one ad for for this third
Jeff Terrell: One 142 for the second one, for example, because the basis is different for each of these
Jeff Terrell: Okay, so that's flex grow.
Jeff Terrell: Um,
Jeff Terrell: Let's do something a little bit different. All right, let's say I'm just kind of making this up as we go.
Jeff Terrell: Let's say that basis for all of these is 200 pixels. So this is introducing an overflow situation. And in this case, we haven't allowed any of them to shrink and so um
Jeff Terrell: None of them do. And we just overflow, but we can actually set that to shrink so
Jeff Terrell: If we said, each of them to shrink, all of them can shrink by the same amount. And so what we see in layout is the basis was 200 pixels, but everything shrunk by 40.83 I think
Jeff Terrell: Yeah.
Jeff Terrell: Final sizes are again, actually, in this case, they're the same file sizes are the same, because we set the basis to be the same in all three cases.
Jeff Terrell: Okay, and then just for fun let's set. Let's override this and say that too does not grow or shrink and as a an automatic basis and so interesting. Why did this happen the way that it did.
Jeff Terrell: I'm surprised we didn't fill the available space. Oh, because we're not we're not allowing anything to grow. We're only allowing things to shrink. Is that right,
Jeff Terrell: Yeah, so if we stay 112 hundred pixels. Now we're at a point where we fill the available space if we set it back to zero, then what happened was,
Jeff Terrell: We just didn't get into an overflow situation to begin with.
Jeff Terrell: Hello. Now we did right because this sorry I'm not explaining this very well the special rule is overriding this one. This is where the sea and cascading style sheets comes from these styles can cascade.
Jeff Terrell: And what that means is that something that's more specific overrides something that's less specific. This is more specific. And so when we had this 00 auto all three of those properties were sat on the special paragraph. The second item.
Jeff Terrell: When we set that back to 200 pixels. We're saying the second one cannot grow or shrink and so it's with is going to be 200 pixels, just like its basis says it needs to be a three is going to start out at 200 and shrink by more than it had before so that we don't overflow that flex content.
Jeff Terrell: Okay, I think I probably beat this to death. Does that make sense. Any questions about flex box that was all. I was really going to say about flex box. Do you have something fun about flex box in just a second. But I just pause for any questions so far.
Jeff Terrell: Okay.
Jeff Terrell: Seeing none up. Keep moving. The last thing I was going to show you is flex box froggy. If you're interested in learning flex box. This is a really fun way to learn it.
Jeff Terrell: There's 24 levels.
Jeff Terrell: And basically what you're trying to do is to write CSS rules for flex properties that put the fraud that appropriate colored frogs and the Emperor brightly colored lily pads.
Jeff Terrell: Fun little way to just get some practice with flex box and learn some of the concepts.
Jeff Terrell: So check that out. Flex box Froggy calm.
Jeff Terrell: Okay. Oh.
Jeff Terrell: There we go. Okay.
Jeff Terrell: So next I wanted to talk about grid layout. I'm really not going to talk about grid layout or responsive design very in depth.
Jeff Terrell: But let me just briefly mentioned this. So grid layout is kind of like flex box, I believe, flex box came along, first, and then grid layout came along after that.
Jeff Terrell: And it's, it's a lot like flex box, but it's actually intended to be used for flexibility in both dimensions both horizontally and vertically
Jeff Terrell: It's a really nice system. It's sophisticated it's flexible and has some really nice controls that work out really well. And it's not actually that difficult to learn
Jeff Terrell: It is supported in all major browsers.
Jeff Terrell: I don't think I mentioned this last time. But can I use is a really good site. If you're looking for like browser compatibility tables. So here's a browser compatibility table for the grid layout level one spec and all major browser support this. There are a few caveats. Like I he
Jeff Terrell: Talks about some partial support.
Jeff Terrell: I guess Baidu browser, I believe, is a Chinese browser could be wrong about that does not support it apparently Opera Mini does not support it. But basically, everything else does a good job with grid.
Jeff Terrell: I think there might be like a secure grid, there might be a level to spec for grid sub grid is not well supported that's more experimental and new
Jeff Terrell: Grid row, you know, there's a lot of things here that you can check on does my browser support this her and do the browsers that I intend to support, support this feature.
Jeff Terrell: If not, by the way, I'll just mention the word Polly fill that would be the thing to search for if you're trying to use a feature that isn't well supported you can look for a poly fail, which actually will implement some of these things manually for browsers that don't support them.
Jeff Terrell: Okay, so anyway that's, can I use the point here is that red is supported in all major browsers. So I would consider it safe to use for most web apps. These days, unless you're trying to support older browsers.
Jeff Terrell: If you want to learn grid layout. I am really not going to talk about it here. If you want to learn it. I would suggest, I really like MTN for pretty much anything related to web dev
Jeff Terrell: I think they have really good documentation. There are other good sources of documentation. But I don't know I'm partial to MDM is MTN is Mozilla Developer network.
Jeff Terrell: But this basic concepts of grid layout is a good overview of of what great it was great. It is and how it works.
Jeff Terrell: Also there's a similar kind of tutorial game for grid as there is for flex box froggy. This is CSS grid card and calm 28 levels. This doesn't talk about all aspects of grid, but it at least gives you some practice with some of them.
Jeff Terrell: Questions about grid.
Okay.
Jeff Terrell: Alright, so now I want to talk about responsive design.
Jeff Terrell: The idea behind responsive design is that you're trying to make your site or your app, your web app look good on any size screen.
Jeff Terrell: One thing that you need for a web app to be able to look out at any size screen is this incantation that I'm just
Jeff Terrell: Giving you here. It's an important meta tag to put in your head tag of your document.
Jeff Terrell: Without this, things are a little bit funky. So just
Jeff Terrell: I don't, I don't have a lot of depth on exactly what this means, or why it's needed, but just something you need
Jeff Terrell: The idea behind responsive design.
Jeff Terrell: And one of the one of the principles of doing it effectively for kind of the modern landscape is that you want to design for mobile first.
Jeff Terrell: And the reason for that is because there are some really basic phones in us out there globally that do not support.
Jeff Terrell: Technique and CSS called media queries. This is something that all modern browsers support. But a lot of these older phone browsers do not support.
Jeff Terrell: And I mean, think about, like, you know, we're kind of privileged in the Western world. Right. And a lot of us have sophisticated relatively new phones that that have i mean they're fairly effective computing devices in their own right, with some pretty solid computing power, etc.
Jeff Terrell: But not everybody has access to those kinds of phones, especially in third world countries, you're dealing with phones that if they have internet access and all
Jeff Terrell: Have some really basic browsers that need that are running on some pretty old and slow hardware and the screen sizes might be incredibly small.
Jeff Terrell: I don't know what the actual numbers are. But imagine maybe 320 pixels wide or 240 pixels wide pretty small compared to modern you know monitors that we use.
Jeff Terrell: So, you know, think about that and think about the fact that
Jeff Terrell: The use of these websites that you create might be incredibly clunky, but could be relatively easy if you spent a little bit of time.
Jeff Terrell: Learning about responsive layout and using some of the tricks there.
Jeff Terrell: Basically, I'll just give you a total crash course in this. For starters,
Jeff Terrell: If you just designed for a really narrow screen size first
Jeff Terrell: So that things look reasonable, they don't have to look like picture ask. But if it just kind of looks reasonable. And you don't have to do horizontal scrolling unnecessarily.
Jeff Terrell: That's a good start. And then what you can do is add media queries to
Jeff Terrell: Make things look better on bigger screens. I'll show you an example of that.
Jeff Terrell: So, for example, the app lab website.
Jeff Terrell: By the way, plug for the app love. Remember the app live exists. This is a place where you can get help on your app.
Jeff Terrell: So check that out. Alright, so at some point. Look at that. It breaks. That's called a breakpoint. And that's determined by the media query that I have in my CSS, which I'll show you in just a second.
Jeff Terrell: You've seen this thing kind of happened on pages, probably, if you do much resizing of your browser window.
Jeff Terrell: But I can go all the way down to really, really narrow and I guess at this point, I have to do a little bit of horizontal scrolling so
Jeff Terrell: That I guess is about as far as I can go without having to do horizontal scrolling. So ideally, I should probably have something that brings the menu down lower. So that I can go even narrower. So today I learned
Jeff Terrell: But, but I can go pretty narrow here. And the idea is to make it look good, even on a really narrow device. And so all I'm doing is putting links and other information below the main article body.
Jeff Terrell: And as I make things wider.
Jeff Terrell: I've actually had a break point where a media query kicks in and says, Oh, here's a new style that you need to apply to a certain elements now.
Jeff Terrell: So let me, let me show you how this works.
Jeff Terrell: If I go to this aside.
Jeff Terrell: If I do that, if I see if I make that a little bit narrower that this style that's applying to this.
Jeff Terrell: They're basically no custom styles applied to this element. And this is designing for mobile first. So you use your media queries, only to define styles for larger screen sizes, not for smaller screen sizes. That's, that's what it means to design for mobile first.
Jeff Terrell: And then once you get to a certain screen size the style, a new style gets applied. OK, so now we have a style for sidebar, which is this element here.
Jeff Terrell: That has max width box sizing margin border box margin left to ram and this main actually is the more important thing main becomes a display flex
Jeff Terrell: Okay, so without display flax, we're back to our old style with a little bit few other things change. But this is kind of the main thing.
Jeff Terrell: Display FLEX FLEX kicks in at 768 pixels wide.
Jeff Terrell: Okay, so let me briefly show you this.
Jeff Terrell: I style sheet if I if I just want to look at the raw style sheet I can pull it up in the network panel.
Jeff Terrell: And down at the bottom, I have this media query. Alright, so I've got on my style rules, blah blah blah selector, you know, rules.
Jeff Terrell: And here I have immediate query at media only screen which I forget what that means. I think there are other things.
Jeff Terrell: That we could use maybe touch pad or something. I don't really know.
Jeff Terrell: And men with a 768 pixels. And in that case, if you know we're running on a device that has those properties. Then we define the following styles.
Jeff Terrell: All right. And these might override what the defaults are
Jeff Terrell: So hopefully that makes sense. That's all I really was intending to show you about responsive design.
Jeff Terrell: Oh, and let me show you. Responsive Design Mode and your browser dev tools.
Jeff Terrell: This is a button here for doing that. So I think Chrome is similar but a little button. And so this, this gives me a sense of what this is like to use on a phone gives me a pretty small resolution.
Jeff Terrell: I can say I want iPhone 10 and it gives you that resolution.
Jeff Terrell: Apparently have to reload to apply settings or something. I don't really know what that means.
Jeff Terrell: This gives me a sense. Okay, this is what this app with their the site or app or whatever we look like on a particular phone
Jeff Terrell: Or
Jeff Terrell: I lost my understanding, but anyway.
Jeff Terrell: Okay. Anyway, I'm playing around here.
Jeff Terrell: Right, so that's responsive design mode and that can give you a sense of what it will look like on a phone, even without having to deploy it, and accessing it on your phone.
Jeff Terrell: Okay, any questions about responsive web design.
Jeff Terrell: Okay.
Jeff Terrell: I'd like to stop here and do a quick poll on just how you're feeling about your project. I had, I learned one of the neat things I like about the way y'all have mentors, is that I learned from the mentors and one of the mentors mentioned asking one of asking one of you, one of your teams.
Jeff Terrell: This basically the same question, just how are you feeling about your project right now. So go to polivy.com slash Jeff Terrell and let me know.
Jeff Terrell: Look through all of the
Jeff Terrell: Feedback later see if there's anything. Remember, if you ever are feeling stuck or frustrated or not. You don't even just want to pick my brain for advice or whatever.
Jeff Terrell: You can always schedule office hours and you can also go to the app lab. I mean, you might not meet with me, necessarily, although you might
Jeff Terrell: Not remember if you if you are frustrated by something you can go there, but I'll read all of the responses later here is, I guess. Overview
Jeff Terrell: Yeah, so, Christopher asks, just as an aside, is there a reason I prefer Firefox or Chrome. What I say their dev console is much better, not really.
Jeff Terrell: No, I think Firefox and Chrome are really pretty similar in a lot of ways these days.
Jeff Terrell: I think I like Firefox better just because I feel like they respect my privacy, a little bit more, but it's just my personal preference. I don't think there's a lot of a reason even from the perspective of depth tooling to use one browser over the other.
Jeff Terrell: I think there is. Last time I checked, Chrome had better
Jeff Terrell: Accessibility Checkers. So they were able to do a pretty thorough audit of your site to see, are there some common accessibility mistakes that you're making or things that you
Jeff Terrell: have forgotten about. Sometimes I'll switch over to Chrome to test that out. But for the most part, it's a pretty similar experience even in terms of the developer tools.
Jeff Terrell: Okay, so we got 25 people still working on the open ended questions. I'll give it another minute or so.
Jeff Terrell: Looks like
Jeff Terrell: If one or two of you are totally freaked out. I think it's probably would be one of you. Sorry, get help if you need help.
Jeff Terrell: Mildly freaked out about one out of five of you. So I'm sorry if you're in that boat again get help if you need help. So so 21% okay fair enough, and half of you are actually mildly optimistic. That's great, and a handful of you may be to re are saying, It's going great so that's awesome.
Jeff Terrell: Um,
Jeff Terrell: Let's see where we're at. Here 24 people still working on
Jeff Terrell: I'll leave this open for a while. I don't think it's going to deactivate it by itself for for a little while. So if you want to fill in.
Jeff Terrell: The open ended response as I move on, feel free.
Jeff Terrell: But I'm going to move on because I think other people are done in waiting
Jeff Terrell: Okay. OK.
Jeff Terrell: OK, so now I want to talk about client server architecture.
Jeff Terrell: This is a bit of a pivot from what I intended to talk about today, which was infrastructure, I realized that
Jeff Terrell: It would be helpful to describe what we're deploying and what the infrastructure is supporting before I talked about actually deploying and what the infrastructure needs are.
Jeff Terrell: So, last time I taught this course I I don't know why I didn't catch this when I was creating the calendar, but I
Jeff Terrell: I did talk about the back end first before I talked about infrastructure. So I realized, basically, this would be useful background information when we move on to deployment and infrastructure which I intend to talk about next time.
Jeff Terrell: I also got one piece of feedback from a student on the takeaway questions last time that it would be helpful to
Jeff Terrell: Get some understanding about like what the overall architecture of an app might be
Jeff Terrell: And so that was that that's actually what kind of made me say, hey, wait a second. Am I going to be talking about that. And then I looked at the calendar and realized I wasn't planning on it. I should
Jeff Terrell: So, and then the other thing is, this is useful for almost all projects for assignment eight. The Walking skeleton. This is
Jeff Terrell: Useful for web apps, it's useful for mobile apps of any variety
Jeff Terrell: It might even be somewhat useful for our, our VR app this semester I feel bad for you guys to see that you're doing a bunch of VR stuff. And a lot of what I'm saying here has very little bearing on your project.
Jeff Terrell: Sorry, but you know what do you do, maybe I should have given a caveat, at the beginning of the class. Like if you choose the art project might be some lectures that you don't like very much more benefit from anyway.
Jeff Terrell: But almost all the rest of you're going to benefit from this. So I think it's useful. Useful background. All right. Now, as with layout content.
Jeff Terrell: That I talked about over the past two lectures. Some of you're going to find this useful. Some of you are not. It depends a lot on where you're coming from. What courses you've taken what experiences you've had
Jeff Terrell: With app development and web development.
Jeff Terrell: So if you've taken for 26. Well, let me say this way. If you haven't taken calm for 26
Jeff Terrell: And you're not clear on like what, for example, front end and back end actually are referring to and what the, what the technical differences are.
Jeff Terrell: That I think this is going to be really important background information for your project and help you get a big picture view of what the big pieces of your application are useful for example in the architecture diagram coming up.
Jeff Terrell: But also just an understanding how the whole thing is working together.
Jeff Terrell: If you have taken for 26 and or you're actually clear what is meant by friend and versus back end, then I think this will be important for your project.
Jeff Terrell: Or sorry, this, this, this might be boring, it's what I meant to say. And this might be something that you already know pretty well.
Jeff Terrell: But that said, I'm hoping it won't be too boring. I'm, I'm hoping that seeing the high level picture of everything might be a helpful review.
Jeff Terrell: Or even maybe a clarifying overview that helps things. Click together. Maybe it's been a while since you took 426 and getting a refresher on the big picture view will will help. So anyway, again, some of you might find this less useful and sorry if that's you. But what you know.
Jeff Terrell: Not sure what to do about that really
Jeff Terrell: have wondered actually about making for 26 and maybe even 521 pre record for this class, that would mean that everybody has a lot more consistent background.
Jeff Terrell: I don't know if you have strong feelings about that. Feel free to let me know. Just kind of an idea. I'm playing with
Jeff Terrell: Okay so CSA meeting client server architecture, what I plan to talk about in this topic is
Jeff Terrell: Just the motivation for the client server architecture and I'm going to get that get there by talking about what apps need in general and what some commonalities of apps are
Jeff Terrell: And I'll talk about what the architecture actually is. And I'll talk about how the client and server are connected to provide the API.
Jeff Terrell: And I'll talk about HTTP, in particular, because that is by far the most common way that people write API's these days at least. This kind of API.
Jeff Terrell: And then finally, I'll just give you some tips on implementing client server architecture and debugging apps that are using the client server architecture.
Jeff Terrell: Okay, so some commonalities among all apps is that they all have to do some amount of API that is human computer interfaces.
Jeff Terrell: They have to do this both kind of in the input and output directions. So, for example, an app is going to need to show screens and information to users somehow
Jeff Terrell: And maybe that's what the graphical user interface. Maybe that's with a text interface like on the command line.
Jeff Terrell: Maybe that's even like with team see a VR interface and they're showing stuff on screens, kind of a head mounted display. I guess that was still the screens, but it's not exactly a gooey.
Jeff Terrell: And on the other side of things apps are going to need to handle some sort of input usually maybe not always but but usually an app is a lot more useful if it has some way of responding to user events or to input in some fashion.
Jeff Terrell: So, these might be mouse events, you know, mouse move and hovering over different things. Or it might be clicks, you know, left click right click, double click
Jeff Terrell: It might be keyboard events or it might even be something more like form submissions where users are typing into a form and they have various fields and then they hit submit. Submit is an event.
Jeff Terrell: So that's a pretty common thing for all apps, I would say all apps need to do this at some level, again, with the caveat that maybe there are certain really simple apps that don't do input.
Jeff Terrell: It's possible have an app that doesn't do output.
Jeff Terrell: I guess maybe, but it probably wouldn't be very interesting.
Jeff Terrell: And I should say, too. When I say app. I really intending to talk about things that are used by people. There are certainly programs that
Jeff Terrell: Don't have to do. Human Computer Interfacing
Jeff Terrell: You know, maybe the kernel of an operating system or, you know, low level command line tools and things like that don't really need to interface with the human much, if any.
Jeff Terrell: But when I say app. I'm talking about something that guys have a user interface of some sort.
Jeff Terrell: Okay. Note that this human computer interface requires code running on user devices.
Jeff Terrell: So,
Jeff Terrell: That's an important thing to note, and we'll get into some of the implications of what that means. And just to, just a bit.
Jeff Terrell: But the idea of an app is that you're going to have code that is running on multiple devices. I mean, if you have multiple users, which I think most apps are intended to support
Jeff Terrell: And so somehow you got to get that code on that device and that device has to actually execute it. And that would be like an instance of your app.
Jeff Terrell: Okay.
Jeff Terrell: Now, many apps, maybe even most apps, these days have some need for some some amount of shared data. Alright, so one use case here might be that an app wants to provide a similar experience for the same user regardless of device. So imagine checking your email on your phone or on your laptop.
Jeff Terrell: The same data needs to be present in both instances of the app.
Jeff Terrell: All right, or you're checking your, your Insta feed or something like that.
Jeff Terrell: You want the same data to be available, regardless of whether you're checking it on your phone or on your browser on your laptop.
Jeff Terrell: You might also ask might also want to provide continuity in case of a lost or broken device. Most platforms lets you store some data locally on device, including web. You can do this on the web with web apps.
Jeff Terrell: But then if that device is lost or stolen or broken, then all of that data is lost, unless it is replicated somewhere else.
Jeff Terrell: Another use case here is that there might be a need to access data generated by other users.
Jeff Terrell: And here again you know email is, you know, is a little bit different because it's kind of a distributed algorithm that that's kind of out of scope here but
Jeff Terrell: But, you know, Instagram, Twitter, Facebook, all that kind of social networking stuff you're reading things that other users have created
Jeff Terrell: And all of these different use cases imply that you have data that is stored off of the individual devices running this human computer interface.
Jeff Terrell: Right. You've got some interface on your phone or whatever. And if that phone or maybe that web browser is accessing data from out there you know off device. And we sort of generically say it's in the cloud.
Jeff Terrell: I was. Yeah. I remember when cloud computing became a thing and people started using this word all the time anyway.
Jeff Terrell: Right. So anyway, the code on devices has to talk to some other computer and fetch all the relevant data and potentially push other data that this devices in this user is generating to that shared place.
Jeff Terrell: And that is the sort of groundwork for the client server architecture.
Jeff Terrell: Okay, so that idea there is
Jeff Terrell: Yeah, basically, you just have some need for shared data.
Jeff Terrell: So, yeah. Next, I want to talk about the client server architecture of what it is.
Jeff Terrell: And what it is, okay, the client is what I've been talking about is the device that's running this human computer interface. This is user interface.
Jeff Terrell: This is the code that's running on the user's device and the common term that we use for a client when it comes to app that the kinds of apps that most of us are building in this class is front end.
Jeff Terrell: That's what people mean when they say front end. This is all of the code that is running on a user's device.
Jeff Terrell: On the other hand, the server in the client server architecture is referred to as the back end. This is the code that's running on a server somewhere.
Jeff Terrell: So there's some differences here between the front end and the back end the front end code runs only when being used, but the backend code runs all the time.
Jeff Terrell: It needs to always be available and ready and listening for requests. This is connected to the word server, right, you have a service.
Jeff Terrell: The server is providing a service and service. It doesn't necessarily imply, but I think in most cases, it tends to mean something that you want to be always on.
Jeff Terrell: Especially when it comes to a back end, you generally want that to always be running and available.
Jeff Terrell: Now, the difference between front end back end is that the front end code is running on many devices. So one device per user. Maybe even multiple devices and for some users.
Jeff Terrell: But the back end code runs on only one device or maybe on a small number of devices.
Jeff Terrell: Will see some examples of this next time when we talk about deployment and infrastructure. There are cases where you might have a pair of servers that are sort of a call it like a highly available pair.
Jeff Terrell: But it's the same code running on both of those servers and it's still a pretty small number.
Jeff Terrell: Another difference is that front end code runs on untrusted devices but backend code runs on trusted devices. And what I mean by that is that
Jeff Terrell: Assuming you don't do something stupid or you don't accidentally have some security hole in your back end.
Jeff Terrell: Generally speaking, you're going to be able to trust that the code that is actually running
Jeff Terrell: For your server is code that you created that you pushed if there's a bug. It's your fault if there's a security all it's your fault.
Jeff Terrell: And that's not true with front end code front end code is malleable by the user, especially when it comes to web apps. You saw all the things that I could do with different styles in the browser dev tools.
Jeff Terrell: You can do the same thing with JavaScript code, you can run arbitrary JavaScript code that executes in your current environment of, you know, the front end web app code. So you could redefine functions.
Jeff Terrell: And there are there are ways to kind of protect against that at a JavaScript level, but it's still, it's all there. And somebody can even if they're bypassing your browser.
Jeff Terrell: What are we trying to say they can still connect to your back end completely apart from the front end that you actually shipped to them.
Jeff Terrell: So they might, you know, bypass all the clever protections and security mechanisms that you have in your front end and just talk to the back end directly, you can't trust that they're not. There's no way to prevent them from doing that. It's an untrusted device. And so that has some implications.
Jeff Terrell: By the way, I forgot to mention
Jeff Terrell: I'm having some issues deploy deploy the latest updates to the website and I apologize if you are normally or if you're used to following along with the slides from the website, they are not available right now and
Jeff Terrell: It's some kind of issue with my nullify setup. I don't, I don't know what's going on it saying it can't fetch the code from
Jeff Terrell: From get lab.
Jeff Terrell: Work that time. No.
Jeff Terrell: So anyway, I'm not going to debug there, and I wish I could try it for 30 minutes and then it just times out. So I don't know. Anyway, I'll get that up as soon as I can.
Jeff Terrell: But sorry if you are trying to follow along with the slides and can't
Jeff Terrell: Okay anyway client server architecture front end back end.
Jeff Terrell: Let me talk a little bit more about the back end. And what is
Jeff Terrell: The responsibilities of the back end include being available at a known location 24 seven but known location might be some particular domain name that you've configured to point to the server that is running your back end code, you know, API example calm.
Jeff Terrell: The backend also needs to when it gets a request, I guess I should say it needs to listen for requests means to always be listening.
Jeff Terrell: When it gets a request it means to identify which endpoint is being requested. I'll talk about what an endpoint is in just a bit. But
Jeff Terrell: Yeah, I'll just, I'll save that for later. But basically this is like routing.
Jeff Terrell: Which which particular service is trying to be invoked.
Jeff Terrell: And needs to check the authentication of the request. In other words, is there a known user that is sending this request. And do we do we trust that that is who the request. My indicated is
Jeff Terrell: The backend needs to check the authorization of the requests, does the user have the news access. For example, you might not want every user to be able to access an admin panel. So even if they're authenticated, you might not want to let them.
Jeff Terrell: Finish that code or fetch that data.
Jeff Terrell: The back end also needs to check the validity of the content type and payload. If there is any
Jeff Terrell: So I'll talk about this in a little bit, but the
Jeff Terrell: Requests can have a payload with some data in it and if there is data, the back end needs to check that it can understand that the data is and that it's valid according to whatever rules as
Jeff Terrell: And then there might be other policies that the
Jeff Terrell: The either the app defines for all endpoints, or that are defined for particular endpoint, the backend needs to do all of that.
Jeff Terrell: And then if the request has kind of passed all of the needed checks and
Jeff Terrell: You know, I've been vetted appropriately, then probably the backend is going to be accessing some sort of a database.
Jeff Terrell: To service that request, whether that's, you know, putting new data in the database or updating existing data deleting data just reading and fetching data certain kinds of data.
Jeff Terrell: That's the back ends job, assuming it did all the vetting of the request it needs to, then probably do something with the database in order to actually generate a response and send that back.
Jeff Terrell: And so the really 10,000 foot overview of a back end. Is that a backend is the gatekeeper for the central database of data.
Jeff Terrell: I haven't really talked about a database or what that is. I think many of you have had 521. I don't know whether most of you have had that or not, but
Jeff Terrell: That's files and databases, by the way.
Jeff Terrell: Basically that what the thing that the database provides is persistence. So in case a server crashes or there's an outage or something like that database means that all the data sticks around it's written to hard disk and still accessible and efficient ways
Jeff Terrell: And the backend is the gatekeeper for that data because we do not want any front end to be able to access the database.
Jeff Terrell: If any front end could access the database, then that would be a total security failure, anybody could change data and read data and whatever. And okay, maybe that's what you want.
Jeff Terrell: You know, you have your Google Doc set to totally public anybody can write to this, but in most cases, that is not very useful. And so most apps will say,
Jeff Terrell: There needs to be some some sort of gate keeping to make sure that uses of the data, you know, whether it's asking accessing data or changing the database.
Jeff Terrell: They need to be vetted and constrained in certain ways to keep everybody safe and happy.
Jeff Terrell: So that's what the back end does I'm
Jeff Terrell: Trying to think if there's anything else I need to say about that. I don't think there is. All right. Question. Just to check, you know, check your understanding and think about this. Do all apps need a front end and do all apps need a back end.
Jeff Terrell: So feel free to just think about this for a second. I'm going to wait for maybe 10 seconds to give you some chance a chance to think and then I'll, I'll give you the answer.
Jeff Terrell: The answer, according to me anyway.
Jeff Terrell: Is that I again. I'm assuming the apps involve a user interface of some sort. And in that case, all apps have a front end.
Jeff Terrell: Now that might be a really simple one. It might be command line interface. So it's just standard in a standard out simple stuff.
Jeff Terrell: But there's some sort of a front end interface.
Jeff Terrell: And therefore there. Sorry, there's some sort of user interface and therefore, there needs to be some code that runs on the user's device. Therefore, there needs to be a front end and therefore there is a front end the front end is the code that's running on that device.
Jeff Terrell: But not all apps needed back end.
Jeff Terrell: So remember, just to jump back a few slides. There are some criteria for when you would need it back end.
Jeff Terrell: If you need to provide a similar experience for the same user regardless of which device they're using. You need to back end, you need some sort of shared data some source of truth. Some centralized authority for what the data is that is accessible to front end code.
Jeff Terrell: Or if you need to provide continuity in case of a lost or broken device and you need a back end, you need some source of truth. It's out there in the cloud.
Jeff Terrell: Or if you need to access data generated by others than again having a source of truth is helpful.
Jeff Terrell: Let me mention briefly that
Jeff Terrell: I am assuming a centralized back end.
Jeff Terrell: And that's not necessarily always the case. So there are ways of doing peer to peer algorithms and distributed algorithms and approaches to storing data.
Jeff Terrell: Where maybe you've got a bunch of nodes communicating with each other directly and different nodes, sort of, save different pieces of the data.
Jeff Terrell: And that's complicated and I think really interesting. I like studying those things, but
Jeff Terrell: It's usually not practical. It's usually a lot easier to stick with a centralized authoritative single source of truth in terms of a single database that's accessible at that central location that your domain name points to to connect to your back end service.
Jeff Terrell: So I just wanted to mention that as a possibility, but I don't think it's a possibility that any of you, at least in this class are going to encounter.
Jeff Terrell: Okay, so as an example about when you might not need a back end calculator app does not need a back end. It's generally a calculator app is not going to me to provide the same experience.
Jeff Terrell: Well, okay. So maybe, maybe I haven't said this very clearly, it will be a similar experience for the same user regardless of device.
Jeff Terrell: But there's no real notion of user. I mean, it's the same experience for everybody globally. And so there's no amount of customization needed for this user versus that user. Just don't personalization. So I guess I didn't include that as an aspect here and my slides.
Jeff Terrell: A calculator app doesn't need to provide continuity in case of a lost or broken device. I mean, I suppose, if it's something really industrial strength and maybe there's like a
Jeff Terrell: Audit tape of what transactions have been entered in. And maybe, maybe you want to save that I don't know but basic calculator apps certainly don't need that.
Jeff Terrell: And there's no need to access data generated by other users, at least not from some sort of central database.
Jeff Terrell: If you want to share data with another user, you can actually just do them manually right you could send them a text message with the answer of the calculation, if need be, but it's not something the calculator app itself needs to support
Jeff Terrell: As another example of photos app doesn't need a backend, but it might have been any way to backup photos so that if your devices lost or whatever that it's still all your photos are still available.
Jeff Terrell: So anyway, front ends are essential back ends or not.
Jeff Terrell: Okay questions so far about what the client server architecture is
Jeff Terrell: Okay.
Jeff Terrell: So how do the client and the server, talk to each other.
Jeff Terrell: This is generally called the API. When you're talking about an app that uses the client server architecture.
Jeff Terrell: Now there's more than one API your app is going to be using all kinds of different API's at different levels and all API really means is an interface that is consumed by a program, rather than by a user
Jeff Terrell: So for example, if you're using some library that does something that library is publishing an API. And that's just how do you actually use the library. So you're using. If you guys have a lot of different levels. But this is sort of like the API of a client server architecture application.
Jeff Terrell: Okay. So how does this work, generally speaking, the API is going to have multiple endpoints. I suppose it's possible to have an API with a single endpoint, but
Jeff Terrell: Probably that's not going to be very interesting.
Jeff Terrell: And each endpoint does a particular thing.
Jeff Terrell: So for example, you might have an endpoint that authenticates a user given a email and password.
Jeff Terrell: You might have an endpoint that fetches the feed for the authenticated user
Jeff Terrell: You might have an endpoint that follows another user, you know, adds that to your follow list or you might have an endpoint that creates a new posts and you can imagine you know where you can go from there.
Jeff Terrell: And most cases. Most of your requests are going to need to be authenticated. So they're sort of relative to a particular user that has proven who they say they are
Jeff Terrell: And usually the way that works at least with HTTP, which we'll talk about in just a second is with a cookie.
Jeff Terrell: And the cookie is going to be attached to every request that you send
Jeff Terrell: Okay, so I'm bleeding into HTTP, a little bit, but basically just about every API that you're going to see these days when you're talking about
Jeff Terrell: A interface between client and server is going to use HTTP the Hypertext Transfer Protocol originally created and still used to carry HTML data. So the HT is the same in both of those acronyms HyperText Markup Language Hypertext Transfer Protocol.
Jeff Terrell: And for whatever reason.
Jeff Terrell: Maybe because the web became such a popular platform for using apps, creating apps and using them.
Jeff Terrell: HTTP is kind of a de facto standard these days for creating an API.
Jeff Terrell: So I've talked about endpoints, a little bit before the API is is consistent multiple endpoints and in HTC in HTTP and endpoint is defined by a combination of method and a path where method might be GET or POST or put or delete or there are other ones as well.
Jeff Terrell: And paths are essentially everything that you see.
Jeff Terrell: After the host name in your
Jeff Terrell: In your address bar if your browser. So that would be an example of a path. You could imagine slash login dot html posts slash posts 123 to get a particular post all that kind of stuff.
Jeff Terrell: There's a few exceptions to that that I don't really want to get into. But like this start this hash 31 is an anchor. That's not technically part of the path.
Jeff Terrell: There's also like you can say, question mark, or this or that, I guess, others come before the hash mark but question mark food equals bar, etc. Those are things that are not technically in the path, but
Jeff Terrell: Anyway, the point is that
Jeff Terrell: In HTTP endpoint is defined by a combination of method and path and this needs to be unique, so that it can identify which endpoint you intend to do
Jeff Terrell: And then the responses need to include a status code.
Jeff Terrell: And they might also include some payload data.
Jeff Terrell: That payload data, just like with requests would need to be interpreted by a particular content type of content type of saying
Jeff Terrell: Hey, did bites that I'm sending you should be interpreted as HTML or these by should be interpreted as JSON or these bite should be interpreted as CSS or binary data or or a movie or an audio file or whatever it is. These are different content types.
Jeff Terrell: But responses must include a status code.
Jeff Terrell: And the status codes are somewhere usually between 205 hundred ish and the different hundred levels have different sort of different categories of status.
Jeff Terrell: Do hundreds imply success three hundreds imply redirection for hundreds imply client errors. In other words, the client did the wrong thing. Somehow, and five hundreds imply server errors. In other words, the request was valid, but the server failed to handle that for some reason.
Jeff Terrell: Some specific examples of issues to be status codes would be 200 being probably the most common that's I just means. Okay, everything was fine.
Jeff Terrell: To have one means successful creation of some new resource or entity.
Jeff Terrell: To a four is one that I use a fair bit to indicate
Jeff Terrell: Yeah, everything's fine. But I don't have anything in my payload to give you maybe you gave me something and I created. Well, if I created it. I would say to one.
Jeff Terrell: Maybe, maybe you sent me something to delete and I responded with to a four, meaning I was able to delete it, but I don't have anything to share with you right now. And this response.
Jeff Terrell: For three would be a client error. So for three forbidden means
Jeff Terrell: Maybe there wasn't a cookie attached to this request. And so we can't authenticate that the request is from a valid user therefore we're going to say this request is forbidden.
Jeff Terrell: For for means something that was requested was not found.
Jeff Terrell: And this is actually a legit thing for 18 is I'm a teapot and that's just a joke that the people who originally created a specification
Jeff Terrell: Included in the specification in it. It's arrived. So you'll, you'll see jokes in reference to that occasionally
Jeff Terrell: And then 500 is it is a classic thing that you never really liked seeing that means there's an Internal Server Error of some sort, which means that as far as the server knows the request was valid but it crashed.
Jeff Terrell: Okay. And I'll talk about what to do in the case of a 500 in a little bit.
Jeff Terrell: Okay, let me demo.
Jeff Terrell: HTTP. Think about where I am in terms of time. Okay, so
Jeff Terrell: Let me just give you the user simple example of an API. This is JSON placeholder, it's a fake online REST API for testing and prototyping pretty popular 350 million requests per month.
Jeff Terrell: And as a really simple example. Here is some JavaScript code that you can execute in your front end, whether that's on the web or maybe in a React Native or Cordova context.
Jeff Terrell: And this issue. If you execute this code is JavaScript, then you'll get back the following in
Jeff Terrell: That will be actually this JSON.
Jeff Terrell: So what's actually happening here. If I go, so this is bringing up my network and my dev tools and there's a network tab here. Again, this is similar for Firefox and Chrome
Jeff Terrell: And I'm going to switch over to X HR, which means these are requests that are sent by the front end code that's running in my browser window.
Jeff Terrell: I reload, or actually I didn't even remember if I hit try it again. This is the request that was sent, and you can you can see it popping up as soon as I click the button.
Jeff Terrell: I can actually inspect attributes of this request and response.
Jeff Terrell: So here is the raw HTTP HTTP information.
Jeff Terrell: I can actually look at the raw request that was sent over the wire to the back end. Maybe it was encrypted with HTTPS. But
Jeff Terrell: The unencrypted version of this, this is these are the actual bikes that were sent. So that's kind of cool to see. And this is kind of the interpreted version of the same information.
Jeff Terrell: I sent to them a cookie. I didn't mean to, but probably something is tracking me and sending a cookie along with this request. So you can actually dig into all the details here. And then here's the response. In this case, we got a 200 status back meaning, everything is okay.
Jeff Terrell: There is a content type of application JSON. So it's indicating that these bytes should be interpreted as JSON and it even gives the character set for
Jeff Terrell: The, the data. So character settings ETF eight which is a particular way of
Jeff Terrell: Encoding characters.
Jeff Terrell: There's a lot of other useful information here. Well, maybe to swim. Maybe it isn't. But certainly more information in the response.
Jeff Terrell: And I can actually look at the response data. This is the raw response payload text and Firefox hopefully gives me a kind of interpreted JSON view of this data. And it's the same as what we see here, right.
Jeff Terrell: So that's a way to kind of investigate individual requests and responses. Let me mention one thing that I'll come back to you in a little bit, you can actually copy a particular request as curl.
Jeff Terrell: You can copy the URL that it was sent to you, but you can also copy it as curl. I'll talk about what that means in just a minute.
Jeff Terrell: So that's a HTTP.
Jeff Terrell: Any questions about HTTP.
Jeff Terrell: Okay, seeing none I'll keep going.
Jeff Terrell: Finally, I want to talk about some implementation and debugging tips and then I'll have another poll for you after that.
Jeff Terrell: When you are working on an app that conforms to the client server architecture.
Jeff Terrell: I recommend defining the API first because then you can implement the front end and back end in parallel, without having to continually negotiate.
Jeff Terrell: How they're going to talk to each other. So if you specify all that needs to be known about either front end or back end.
Jeff Terrell: And how they talk to each other, first by defining an API, then one person who work on the front end where one person can work on the back end and all this stuff can happen in parallel.
Jeff Terrell: I realized as I was reading the slides that if I just said to find the API that's a little bit fuzzy. Like, what actually needs to be defined. And so I thought I'd give you some
Jeff Terrell: tips about how to define an API and what kinds of information you need to specify
Jeff Terrell: So, you certainly need to specify, at least the method and path that would define you. That would define the end point. Remember endpoint is a combination of method and path.
Jeff Terrell: And I mentioned that the path might be not a string that static, it might actually be a pattern that kind of
Jeff Terrell: It's a like posts colon ID meaning like okay some something goes here. And you might have either rules that are really specific, like this is only numbers or you might have some other way. Maybe dashes are allowed in the ID. I don't know. But you might specify that
Jeff Terrell: You need to specify for each endpoint whether authentication is required or not. And what happens if authentication is required and not provided. I assume that probably a four three forbidden.
Jeff Terrell: Specify for each endpoint. If any requests data is respected, and if so, what kind of content type. It should have in order to be interpreted by the backend.
Jeff Terrell: And then any different conditions that you need to have for your response. So was there a resource that wasn't found, we need to specify. Okay, what's going to be returned as a response if the requested resource was not found. What happens if
Jeff Terrell: The request wasn't authorized, you know, these are different conditions that you need to specify. And then for each condition.
Jeff Terrell: You would say what status code. It's going to be returned and if there's any response to you know what that data is going to be sort of semantically and what the content type for that data is going to be
Jeff Terrell: Most of the time, by the way, API's these days are transferring JSON as the content type, just like we saw with that JSON placeholder API.
Jeff Terrell: And then the last thing. Or maybe not. The last thing, but one of the thing that you need to define sort of globally for your API is how authentication works.
Jeff Terrell: And in most cases, you could say that it is a certain cookie, maybe a session ID cookie.
Jeff Terrell: And if you're dealing with a web app. The browser is automatically going to attach that cookie to every request that it sends to your back end. If you're not using web app, you might have to do some sort of attachment of a session ID manually, but the API should specify the details there.
Jeff Terrell: Okay, implementation and debugging tips. Let your clickable prototype drive your API, so that you don't over engineer your API.
Jeff Terrell: In other words, only support endpoints that you know you're going to need and you can look at your clickable prototype and click through it and think about what actual API requests that you'll need. Let that be what drives what you actually specify
Jeff Terrell: So I'm trying to start from all the things that you could do.
Jeff Terrell: So what about debugging say something API related isn't working in your app. Here are some suggestions.
Jeff Terrell: First of all, you could modify your client code to fetch something from or post something to a known working API, like the one we just saw JSON placeholder. That would just make sure that the code that you have in your front end does work, and it is doing what you think it should do.
Jeff Terrell: I would kind of isolate the problem to the back end, or else you're calling the back end in a way that the API doesn't specify
Jeff Terrell: Another thing you can do is you can test the back end code by using a known working client to send requests and that way you can make sure that the client really is sending the request as you needed to
Jeff Terrell: This could be the browser, like it's kind of soften JSON placeholder example, it could be a desktop app called post, man.
Jeff Terrell: A lot of people use their also COI tools like curl or a CD pie that you can use on your command line, I would show you that, but we're kind of out of time. And then just pay attention to your response details.
Jeff Terrell: So make sure that if there is an exception occurring on the back end that you actually see all of the details for the exception, either in a standard output of your server process that you should keep an eye on or potentially in the response like the 500 response from the back end.
Jeff Terrell: And then finally, that thing I just showed you about copying and request has curl, you can actually paste that into a terminal. If you have a cURL command installed and replay that same request if you're able to cause a problem, then you can replay it on demand as you're debugging.
Jeff Terrell: Okay, that's all I have. Except for this final poll for comfort, although
Jeff Terrell: Yeah, let me just shouldn't take long. I'm sorry if I'm giving you a little bit late, but I'm going to activate this please just fill this out and let me know how comfortable you are with get
Jeff Terrell: And that's all I got. So I'm going to stop sharing and stop the recording.