Building Better Go Web Apps with the Gorilla Toolkit

Gorilla/Securecookie: Securing Sensitive Information
Hello. Welcome back. The last several modules of this course have introduced small but powerful tools that are targeted at improving Go's ability to produce web applications in several areas where the base library is light on functionality. This module isn't going to be any different. This time we're going to be talking about the secure cookie package and how it can be used to protect information stored in the cookies that are transmitted to and from the client. In my experience, I have always been a little concerned about storing data in this way since cookies are sent as clear text and easily manipulated by the browser's development tools. In this module we're going to see how to ensure that cookies are authentic as well as how to encrypt their contents so that prying eyes don't have access to their content. Let's start out with a reminder of what cookies are in the first place and why they need to be secured.

Gorilla/RPC: Creating Remote Procedure Calls
Hello. My name is Michael Van Sickle. Welcome back to this course where we are talking about the Gorilla web toolkit for Go. So far in this course we have been talking about packages that Gorilla brings to enable you to build better web applications. They have been focused on enhancing the way that requests are routed through your application. This time, however, we are in for something a bit different. Remote procedure calls are typically not part of the request pipeline. Rather they are used to connect the current application to another one. That remote application might be running on the same computer or in a data center on the other side of the world. We are also going to talk a bit about the differences between the gorilla/rpc package and the base implementation in the net/rpc package. This time, however, I think you'll agree that the Gorilla implementation is just going to provide another option with advantages and disadvantages of its own. The basic net/rpc package is already very good. Gorilla adds in a couple of additional options to make your Go applications more flexible. Finally, we're going to touch on the JSON/RPC protocol that Gorilla uses as one of the schemes that are available out of the box. My intention of talking about this is not to make you an expert in JSON/RPC, rather I think that it's valuable to see how things are working behind the scenes in order to make it easier to introduce this package and debug your applications if things don't go according to plan. While the RPC package has a lot to offer, it isn't the only way to handle web services in modern applications. Let's take a look at some other methods so that we can understand the context of web services that the gorilla/rpc is a part of.

Gorilla/Sessions: Persisting Information Between Calls
Hello. Welcome back to this course on the Gorilla toolkit. In this module I'd like to introduce you to the Gorilla/Sessions package. Session management is often a small but vital part of a web application since it allows user information to be tracked and stored across multiple HTTP requests. While the base library in Go doesn't have any direct tooling to support sessions, Gorilla builds upon the secure cookie and context packages to deliver a simple, yet complete solution to allow sessions to be stored with ease. Just so we're all on the same page, I'm going to use this diagram to remind us of what a session is. When a client calls our web application via an HTTP call, there may be some information we want to remember about them, such as their account information the case of an eCommerce site. To do that, we create an object that holds the information that we're looking for. This information is then stored in the user's session and a cookie that links that session to them is sent back to them so that any future requests that they make can be associated with the session. Meanwhile, the session is removed from memory on the server and saved off so that the application keeps its memory footprint down. When a request comes from the same browser again, then the cookie is used to find the matching session, which is then reloaded and made available to whatever needs it. This allows an application to act as if the web application were a stateful system instead of the stateless one that is the default of the HTTP protocol. Gorilla comes with two built-in mechanisms for storing sessions. Let's look into the first one of those by learning how to store the session information inside of a cookie.