Let's Build a Go version of Laravel: Part Two

Let's get started by setting up our project structure and creating a Workspace.

Let's make sure things are set up correctly before going any further.

An overview of what we are going to build in the coming sections.

Docker makes it ridiculously easy to create our remote file systems. Let's set them up.

Before we can use Minio, we need to set up an account. Let's do that.

Before we can use sftp and WebDAV, we have to set things up. Let's do that.

We want our file system services to have the same functionality, so let's set up a Go type to make that happen.

Let's write the connection logic for Minio, and implement the first of the four required functions: Put

Sometimes we need a listing of everything that is in a remote bucket. Let's write that code.

Let's take care of deleting one (or more) files from the remote file system.

Usually, you don't need to get a remote file and pull it down to the server, but at some point you might need to, so we might as well be complete and implement a Get function for our Minio filesystem package. Let's take care of that now.

Before we begin connecting our Minio filesystem to Celeritas, it will make things a lot simpler if we implement stubs for S3, sFTP, and WebDAV. Let's take care of that.

Before we can use our Minio filesystem, we need to make a few changes. Let's get started.

Let's run a quick test to make sure we can connect to our Minio file system.

Let's create a handler that will allow us to display the contents of our Minio file system.

Let's create the handler and route to display the upload page.

Let's create the handler and route to process uploaded files and copy them to the remote filesystem.

The final step in testing our Minio file system is implementing the delete functionality. Let's do that.

Let's get started with the Put function for sFTP file systems.

Let's implement the list function for our sFTP package, so we can list the contents of a remote directory.

Let's complete the stub Delete function so we can remove files from the sFTP server.

The last function we need to implement is Get, so let's take care of that.

Before we can use the sFTP  filesystem, we have to let Celeritas know that it exists. Let's take care of that.

Let's add support for our sFTP file system to our handlers.

Let's update our code to allow for putting this on our remote sFTP file system.

Let's implement deleting files from the remote sFTP file system in our handlers.

There is a (very well hidden) potential resource leak in our sftp.go file; let's find and fix it.

Let's get started with WebDAV by implementing the Put function to put files on the remote system.

Let's take care of listing the contents of a directory on the remote WebDAV file system.

Let's implement the delete function for our WebDAV file system, and update our handlers to use it.

Let's implement the Get function for WebDAV, so that we can pull a file from the WebDAV server to the server where our web application lives.

Let's try out our new WebDAV file system.

Let's get the necessary Amazon package installed, and implement the List function for our Amazon S3 file system.

Let's build the Put function for our Amazon S3 file system.

Let's take care of the delete function for our Amazon S3 file system.

Let's take care of the Delete function for our Amazon S3 file system.

Let's let Celeritas know about our S3 file system.

We need an S3 compatible bucket to connect to, so let's create one.

Let's update our handlers in the myapp project to work with our S3 file system.

Let's make sure everything worked.

Let's make uploading a file -- to any file system -- a one liner in our Celeritas project.

Let's make it easier to use our file systems by adding four fields to the Celeritas type.

Let's get started writing the code to make uploading files to any file system as simple as possible.

Uploading files to a server can be a major security risk. One important way to secure this is to limit uploads by mime type. Let's get started implementing this feature.

We don't want to hard code mime types and file size upload limit into our code, so let's allow users to specify the settings in the .env file, and read that into the Celeritas configuration when the application starts.

Before we can try things out, we need to add a couple of handlers and some routes to our myapp project. Let's do that.

Let's make sure that our new upload function works as expected.

An overview of what we'll do in this section.

Let's get started adding functionality to support Pop/Fizz database migrations to our code base.

Let's write the function that will create the up and down database migrations using the pop package.

Let's write the function that will run the pop migrations for us.

Let's write the function that lets users reverse database changes by running the down migration files.

Let's implement the functionality to permit users to run all the down migrations, in reverse order, and then all the up migrations -- in other words, to reset the database completely. This is often incredibly useful during development.

Let's make the changes needed in the Celeritas CLI to create sql or fizz migrations.

Let's try things out with our new "celeritas make migration" command.

Let's put a bit of a sanity check into our CLI so that users cannot create migrations until they have set up their database configuration.

Let's modify our CLI code to support Pop migrations, including migrate up, migrate down, and migrate reset.

We should probably update the make auth command to use pop migrations. Let's take care of that.

Let's try out the new version of the "make auth" command to ensure that everything works the way that it should.

Social Authentication, or Single Sign On, is very popular. In this section, we'll implement it for GitHub and Google, and allow users to sign on to our web app using either of those services.

Let's update our login.jet view to add a couple of buttons for social authentication using Google and GitHub.

Before we can use social authentication, we have to set up our providers. Let's get started.

Let's write the handler that takes care of what happens when the user clicks on the "Login using GitHub" button.

Once a user attempts to log in using GitHub (or any social authentication provider), the provider will send a post request to a handler on our system. Let's take care of implementing that handler.

Let's connect our SocialLogin and SocialCallback handlers to routes.

We need to set up a GitHub OAuth application before we can try out our social login, so let's take care of that now.

Let's try our our GitHub login functionality, and see what we got wrong.

Let's try logging the user out of our application.

Using gothic.Logout(w, r) does not actually remove the authentication token on GitHub, so users are still logged in to our web application as far as GitHub is concerned. This is a fairly dangerous security concern. Let's fix that.

Let's make sure that when we log out this time, our application is also logged out of GitHub.

Let's get the key and secret for Google OAuth2, and then add the entries to our .env file.

Let's add the provider for Google to our social login code.

Let's try logging in with Google and see if it works as expected.

Let's be a bit paranoid and make absolutely certain that logging out a user who logged in using Google actually revokes the login token by calling Google's API manually.