Walkthrough of Deployed App

With our application now deployed, let's spend a little time actually going through our app in the production setting to verify everything works as intended. And in the end of this lesson, we'll spend a little time just quickly summar izing what we did to actually have our app be deployed. In the home page, we can see the static assets presented to us. And we can also see the premium listings in our tiny house application. And this tells us that we're able to query the highest priced listings in our database. If I search for a particular location, for example, if I search for LA here, I 'm taken to the listings/la route. That match-param LA is sent to the Google Joko API, and we get all the listings that pertain to the Los Angeles area in our database. All the data we see at this very moment is the same data we were interacting with during development. We haven't done any changes to the database and the collections within the database. If interested, you're able to now wipe this data completely, prepare it from scratch so users can now create new listings from the very beginning. But in this context, we'll keep everything the way it is, and we'll just use all the mock data we already have. Within this listings page, I'm able to see the listing cards that basically give us some information about each of these listings. I can filter from low to high pricing as well as from high to low pricing, and in either context, I'm able to impaginate and switch pages for every eight listings at a time. In this context, we only have nine listings in total, so in the second page, I see one certain listing. If I click a certain listing, I'll see more information within this particular listing. I'm giving information about the image, the title, the host of this particular listing, its description. And during the booking section, I'm told that I have to be signed in to book this listing. If I try to host a listing, I'm also notified that I have to be signed in as well as connected with Stripe to host a listing. So with that said, let's go to the login page, and let's actually sign in with the Google account. And we'll use the secondary account I've used before, host on the journey to a Gmail.com. And when successfully logged in, we're taken back to the login page very briefly, which is then navigated to the user page of the login is successful. And here I see this particular user information. If we scroll down, we can see the two bookings we've made before. Remember, we haven't done any changes to the collections in our database, so this data we see here is what we've done through development. There's no listing that's been created for this particular user as well. If I go to the same listing we've used before, and if I attempt to check in with a certain date and check out with another date, let's say in this context today is the 16th. 14th actually, I've already booked the 14th to 15th from the last booking, so in this case, let's assume that I want to check in on the 17th, and I want to check out on the 18th. By clicking the Request a Book button, I'm giving some information about my check in and check out dates, as well as the total price I will pay. Now, we can actually provide our payment information. Remember again, that we're using the test credentials that Stripe offers. So we'll use the same fake information we've done before. 424242 all the way to represent a Visa card, an expiry date that is in the future, and any three random digits, CVC code. By clicking Book, the mutation is made. Once complete, we're taking it back to the listing page, and we're told that we 've successfully booked the listing, but try to check in those same dates. They're now disabled within the date pickers, and in my profile page, I'll refresh to see the contents here. The next module will spend a little time in one of the lessons just talking about the effect of caching results, but in this context, just assume that we 've already visited the user page so that data was actually cached. We're just refreshing the page now to see the data now available. So now this tells us that bookings are successful, and using the Stripe fake information we've done before, everything works as intended. Now remember that if we actually want to use real payment information, all we 'll need to do is within our Stripe Connect accounts, make sure our Connect accounts authorized, and then simply toggle off the test data mode, retrieve the actual credentials necessary for our Stripe accounts, and simply replace them where necessary. So replace them in our client environment configuration before we compile our client code, as well as basically replacing the Stripe secret key in our server configuration, which can be done through the Heroku dashboard. If I try to host the listing, I'm still seeing the warning that tells us we still have to be connected to Stripe, though we're signed in to actually host the listing. So I'll go back to my profile page and I'll like a look to connect to a Stripe. When I attempted to connect with Stripe, I'm taken to the Stripe OAuth page that essentially gives some information about the tiny house account, or the tiny house connect account. Now if this was an actual production mode setting, I would have to activate my Stripe Connected account to be able to connect with Stripe, but since we're still using the development credentials for our Connect account, we're able to skip the account form. I won't sign in with my personal Stripe account in this context since that's for my other user, so in this case I'll just skip this account form and Stripe will simply create a fake wallet ID or a fake Stripe user ID for this particular user. When successful, I'm then taken finally back to my user page and I'm told that I'm Stripe registered and I have no income at this very moment. I'm now attempt to host a brand new listing. When I go to the host page, I'm actually able to see the form. Let's now create a listing for a city we haven't created before. We'll pick apartments. We'll say maximum number of guests will be three. The title will be condo in downtown Chicago. We won't spend a lot of time thinking about a description, so let's just say something along the lines of modern, clean and futuristic. There's the condo in the heart of Chicago. We'll use a fake address of something like 111 Cecil Road City, Chicago. State is Illinois. Postal code or zip code will be a fake zip code. We'll say something like 60605. And for the image, we'll look to add an image that we have that we've obtained from unsplash.com and just be tiny house condo. When uploaded, we see the preview and then we'll specify a price of something along the lines of $100 per day. When successful, we're taken to the new listing page for the listing we've just created and we see the information we have here. If I go to my profile page, I'll refresh it in this moment. I'll see the listing now available in my listing section. And if I search for Chicago, I'll be shown the one listing that we have that pertains to Chicago, Illinois, United States. Fantastic. All the main features of our app work just the way we expect it to. So let's spend a short period of time talking about the different steps we've taken to actually deploy the tiny house application. We had to initially compile both our client and server projects. The server needed to be compiled from TypeScript to JavaScript, while the client needed to be compiled from TypeScript to JavaScript as well, and to compile the React API to valid browser technologies. JavaScript as well as HTML and CSS. We then prepared a single Node Express app that is to be deployed. We also had this single Node Express app serve the React client code, the compiled React client code, and the GraphQL API. We compressed all responses in our Node Express application, which will have our server essentially serve smaller web files faster to the user. We pushed the actual deployment app, the Node Express app code, to a GitHub repository. We then deployed our application by essentially syncing the repo code with our Heroku app. We then declared environment configuration variables for our Node Express app within the Heroku dashboard. And lastly, we specified the redirect URLs for the Google and Stripe OAuth to have them both redirected to our deployed app as opposed to our local development environment. If we were ready to receive actual payments within our app, there would be an additional step here that involves swapping the development Stripe credentials we have in our app to the actual credentials that pertain to our Stripe connected accounts within the production setting. Whether we were to use the Heroku command line interface or the container registry approach that Heroku provides to push the code up to the Heroku application, the steps we've taken here would be very similar at the end of the day since our approach involved producing a single Node application that serves the React client code and all API requests. And that's it. We've covered practically all the topics we wanted to from part one of the course all the way to part two. We're going to have one more module in this course and that would have individual lessons where we cover certain specific topics within each lesson that are somewhat important but aren't necessarily deal breakers. We'll talk more about this in the next module. For now, do give yourself a pat in the back because it took a really big effort to get to this point of the course. We'll see you in the next module and in the conclusion of the entire part two of the course where we conclude a lot of the different topics we've talked about and summarize what we've learned so far. See you then.