JavaScript® (often shortened to JS) is a lightweight, interpreted, object-oriented language with first-class functions, most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic, and supports object-oriented, imperative, and functional programming styles.

javascript

Front-end web architecture has made exciting advances in recent years. But before we get to that we need to have a discussion on what has led us to this point and the driving principles behind it.

Since JQuery, we've progressively been decoupling our logic from the DOM. After JQuery, frameworks like Angular were able to abstract that logic into controllers and services. Then Redux came along and brought a simplified that let us reorganize our logic into more cohesive units. 

We should be taking advantage of improved decoupling in the modern web. If you can write a function you can write an endpoint. And if you understand frontend architecture principles, then you already understand cloud architecture principles. 

In this course, you will learn how to decouple JavaScript functions from the environment they live in. By using the Serverless framework and AWS, you will see how straightforward it is to create an endpoint. 

So check out this course and start lifting your functions into the cloud today!

Shakuro Graphics

Front-end web architecture has made exciting advances in recent years. But before we get to that we need to have a discussion on what has led us to this point and the driving principles behind it. 

In this video, you will learn about coupling, and see how decoupling has driven developments in front-end architecture. And, you will gain an understanding of the parallels between front-end architecture and cloud architecture.

How Decoupling Has Driven Frontend Architecture

AWS makes setting up an endpoint straightforward.

In this lesson, you will learn how to create an AWS Lambda function that returns JSON data, and then use API Gateway to set up an endpoint with a public URL.

Create an Endpoint With AWS Lambda and API Gateway

You can create endpoints without drastically changing your function writing workflow by using the Serverless framework. 

With Serverless you can generate a new handler function from the command line. Then, you can change the configuration, write your function, and deploy it to AWS.

Deploy an AWS Lambda Function with the Serverless Framework

Mock APIs are useful for development when you can't use live data for whatever reason. 

Faker makes creating mock APIs a straightforward process. In this lesson you'll see how to user Faker to create a generator object for each of a User's properties. Then we'll write a function that goes through each property and run a generate function. 

Once we've created our mock API generator, we can use the Serverless framework to generate a Lambda Function and API Gateway so we can access our mock API from a live URL.

Create a Mock API Endpoint Using Faker and Serverless

Using serverless functions with webhooks is a commonly used modern frontend pattern. It makes integrating with services flexible and straightforward. 

In this lesson we will set up a webhook in Zapier that sends a `task` in the request body over to Google Sheets and creates a row in a spreadsheet. 

Then we will create a Lambda function that you can make a POST request to with a task in the body of the request. Once the request is made the task is parsed out of the body and posted to our Zapier URL, triggering the webhook.

Trigger a Custom Webhook with a Serverless Function

Even webpages can be scraped using serverless functions! 

We can create a function using the Serverless CLI and import Axios and Cheerio. Axios is used to get the HTML from a page and then we use Cheerio to parse the HTML for our desired data and create an array of pretty printed strings from it.

Scrape a Webpage with a Serverless Function

In this lesson you will learn how to configure your Serverless function to store a PDF on AWS S3. 

You will learn how to set up your serverless.yml config with an environment, and IAM role options you need to put objects into an S3 Bucket. 

And in addition to the AWS stuff, you will learn how to programmatically create PDFs using the `pdfkit` package and functional programming patterns.

Generate a PDF From a Lambda Function and Store It on AWS S3

Step functions are a chain of functions where each function consumes the output of the previous function as its input. 

If you understand functions, then you understand Lambda functions. If you understand Lambda functions, then you know how to create Lambda step functions. 

With this in mind, you will learn how to chain together your Lambda functions, without writing a single line of code, by designing the workflow visually within the AWS console.

Create Lambda Step Functions in the AWS Console

You already know enough. You just need a deeper understanding of what you already know You've had a mental model of a function ever since you understood cause and effect. Input and output. 

And now that you've formed the connections between local functions and Lambda functions, a new world of endless possibilities has been unlocked. 

With Serverless + AWS, what would once take weeks, now takes hours. 

Worse than tightly coupled code is when you are coupled to beliefs that limit what you see as possible for you to accomplish. Decouple your expectations from that perception and realize that you are free to build apps faster, cheaper, easier, and better than before.

**You can go further.**

Course Outro: Taking AWS Further

A boat tour on a river of knowledge, linearly guiding you through the core of AWS. 

Cloud Infrastructure Fundamentals with AWS

You will learn how to build and deploy a Serverless API with Cloudflare Workers. Enabling you to effectively manage a highly available backend for your projects. 

Build a Serverless API with Cloudflare Workers

The core of serverless architectures is auto-scaling systems. We walk through the basics of how to create a serverless API. We start off by creating a simple HTTP endpoint.

Develop a Serverless Backend using Node.js on AWS Lambda

Transform Local Functions Into Endpoints With Serverless

https://app.egghead.io/api/v1/lessons/javascript-how-decoupling-has-driven-frontend-architecture/subtitles

Instructor: [0:00] Hello, friends. We are going to talk about serverless in the context of moving from a plain JavaScript function to a fully deployed endpoint. This shift has some relatively profound implications in terms of what we can accomplish as front-end developers.

[0:15] One welcome discovery that we'll examine is the distance between a function and an endpoint, which, perhaps surprisingly, is not nearly as far as one might imagine. After 20 years of programming and cycling through my fair share of technologies, I believe a learning approach that's focused on first principles will produce the greatest return on time when investing in new skill acquisition.

[0:40] Before we get to the shiny stuff, I want to lead with a quote from Neal Ford. "Architecture is the tension between coupling and cohesion." I don't have hard data on this, but I suspect that 85 percent of the problematic code that I see in the wild is a result of improper coupling, a problem which could easily be solved through better abstractions.

[1:02] Coupling is such a deceptively simple principle that a lot of engineers, to their own detriment, have a superficial understanding of it. In my experience, there are a lot of senior engineers who understand the hottest framework of the month, to the point that they want to argue obscure philosophical nuances about it.

[1:20] The same senior engineers will turn around and violate the single responsibility principle with nested logic and hidden state and wonder why they can't test their code or why their code doesn't scale. This is why.

[1:32] If you're going to talk about state management, NgRx, Redux, observables, facades, etc., you absolutely must have more than a cursory understanding of coupling. By extension, we can't even evaluate a technology as a good solution for our organization without also considering the cost that coupling and cohesion will incur.

[1:54] Vendor lock-in is just another way of saying tightly coupled, which is usually just another way of saying hostage situation. Do you really want to couple the future of your career and your organization's livelihood to a single ecosystem?

[2:10] On the other hand, when your technology is architected on clear layers with clean abstractions, you can swap out one technology for another without toppling the entire thing. To drive this point home, how many Flash developers you know that are thrilled they bet their future on that platform?

[2:28] This is a perfect segue into a brief history of web apps, which also happens to be a great study on the evolution of decoupling. If you've ever had to build a "jQuery application," then you know how tightly coupled the DOM was to the logic that controlled it. The DOM was the single source of truth, and you had to parse it before executing any kind of business logic.

[2:55] Fortunately, there was a wave of first-generation modern web frameworks, like AngularJS, that separated the DOM from the logic and the state that defined it. You simply had to update the underlying data model, and the template would render. The controller was the single source of truth, until that fell apart.

[3:18] When you needed to share state between two controllers -- enter more decoupling from stage left -- common logic was abstracted to a service, which was fine until it wasn't because a typical stateful service was responsible for not only managing and storing state but also communicating with the remote server.

[3:40] It was like multiple businesses being run under the same roof. State-Stored Solutions LLC, Business Logic Experts Incorporated, and Expert Event Couriers were all splitting rent, and nobody liked it.

[3:54] Thankfully, this monopoly was broken up because the newly formed Redux and Co. allowed us to separate our business logic, async operations and state storage into separate and distinct places. Redux encouraged us and, if we're being honest, forced some of us to reorganize into functional, cohesive units that were responsible for a single function within our application.

[4:17] What was most interesting about this new way of organizing our applications was that it not only profoundly simplified things conceptually, but it also presented some incredible opportunities that were not immediately obvious.

[4:30] By completely separating your component layer from the rest of your application and then applying a command-and-query approach for communication, suddenly, we introduce time and space into our applications that did not exist before.

[4:45] In a traditional event-based application, an event handler is triggered, which immediately calls a function that responds to the event. This is a nearly instantaneous and synchronous execution.

[4:58] On the other hand, if an event is converted into an action object that is dispatched, the response to that event is not as obvious and not guaranteed to happen immediately. In fact, you could replicate the action object that represented a user event and sideload it into your application, essentially replaying the event.

[5:20] Imagine an entire user flow, which is nothing more than a series of events that are translated as a collection of corresponding objects.

[5:30] What if you could recreate the entire array of events and then side load them in one at a time. Not only have you created distance from the point of human intervention, but you can also play those events back in whatever frequency you like, which allows you to manipulate time.

[5:48] Taking this a step further, what if you could store a valid action in a remote data store, and then dynamically load and dispatch it? Or load an entire collection of objects from a remote data source and play them back sequentially.

[6:06] Notice how this is possible because we have decoupled the event producer from the event consumer. Let's take this yet another step further. What if the remote data source was real time?

[6:24] What would that mean if you had multiple connected clients that were consuming the same real-time distributed data source? By taking a moment to ponder first principles, specifically coupling, suddenly we are on a fairly short path to something really compelling.

[6:43] I don't think it gets any more enterprise than real-time distributed applications. I've planted a small seed, it's time for the big idea.

[6:54] It took me all of 20 years to come full circle and realize that all of the velocity that I was able to achieve as an engineer was because somehow, some way, I had developed a deep and intimate understanding of the most basic principles that I had learned in my first year of programming.

[7:13] That's when it hit me. If we want to learn new things, we should strive to understand what we already know. I'm going to assume that if you're here, you understand how to write functions.

[7:27] As a result, I believe that on some level, you know how to create API endpoints using the exact same skillset. Let me make the case. Here is a basic function. We give it an input and we get an output.

[7:40] Because we understand this, we know how NgRx effects and most middleware works. We have an effect that is called via a trigger event and emits a completion event. You may know where I'm going with this, a Serverless Function. Request in, response out, and let's keep going.

[8:02] Because we understand how one effect works, we know how to sequence them together by using a completion event from one effect to serve as the trigger event to another until you are all the way down the chain. Prepare yourself. You know how step functions work.

[8:20] Functions that are sequenced together where the output of one function becomes the input of another function. This brings me to my final point. Because we understand frontend architecture principles, we already know Cloud architecture principles.

[8:38] Just as we saw the evolution of imperative logic from being coupled to a component, then to a service, then to a layer. Ultimately, into a distributed layer. We can see a similar evolution with JavaScript functions as we reduce its coupling to the environment it lives in.

[8:58] A function in a vacuum is entirely dependent on the local development environment. The same could be said when you put it inside a framework like React or Angular. You decouple that function by putting it on a server.

[9:11] It's still dependent on your ability to manage the environment as it is probably unmanaged i.e. EC2. The Holy Grail is when you can just put your function into a fully managed environment.

[9:25] It's decoupled from all of the thorny design considerations that we had to think about up until the last couple of years. Ultimately, my goal in this course is to impress upon you a new way to think about what you are capable of accomplishing.

[9:40] I hope to help you realize just how decoupled you now are from the constraints that in the past have made it really hard for you to build great applications at scale. There's only one place for us to go, and that is forward.

https://app.egghead.io/api/v1/lessons/javascript-how-decoupling-has-driven-frontend-architecture/transcript

https://app.egghead.io/api/v1/lessons/javascript-create-an-endpoint-with-aws-lambda-and-api-gateway/subtitles

Instructor: [0:00] For this example, we are going to use data from College Football Data API. The idea is that we're going to pull in some football data, transform it, and then, ultimately, deploy it as an endpoint in AWS. The first thing we need to do is to authorize our call to this API.

[0:18] In the header, I'm going to add bearer and then paste in my key. Don't worry, I will kill this by the time you're watching this video. Next, we'll call git on the Games endpoint. I'll click Try It Out, add in the year 2021, and add in the team of my choice, "Go Buckeyes." Then I'll hit Execute. This will return an array of regular season games.

[0:47] What's interesting is that this also outputs a curl command that I can call to execute this same operation. I can take this, and I can hop into the terminal and add in a pipe symbol and pbcopy, which will then take the result of this remote call and put it on my clipboard.

[1:06] Now that it's on my clipboard, I can hop into StackBlitz and easily paste it in. This is a very convenient step. Let's go ahead and create a schedule property and paste in the JSON response from the curl command. We'll also take a moment to format this response.

[1:28] Now that we have a legible data structure, let's go ahead and create a method called prettyPrint() that's going to take in the schedule array of Game objects. Next, we'll map over that and do basic string interpolation on the Game object itself. Schedule.map, pass in the game, and from here, we'll pull out the game week, home team, away team, and venue.

[1:57] Now that we have prettyPrint() in place, let's go ahead and demonstrate its output. Let's delete this line and replace it with a pre tag so that the output is formatted. Then, using JSON.stringify(), call prettyPrint() and pass in the schedule. We'll tighten this up a little bit, and we have a data structure we can use for the rest of our demonstration.

[2:24] Next up, to deploy this function into the Cloud, we'll go to the AWS Management Console. I could click on the Lambda() method here, but I typically prefer to hit the search bar, type it in, and that takes me straight to the Lambda service. Now, I can click on the Functions Option on the left and then click Create Function.

[2:46] I usually prefer to author from scratch. We'll leave that as the default, and then we'll type in a function name, here egghead-hello-api. We'll leave this at the 14.x runtime and go ahead and click here to create the function.

[3:08] Once this has been created, we can jump down and see that we have a basic handler that accepts an event and outputs something into the body. We're going to create a test event that we'll call Test, and we'll click Create.

[3:27] Now that I have that event created, I'm going to click Test, and we will see that it echoed the object in the response handler. From here, let's go ahead and take the code that we created in our StackBlitz function and copy it all the way up to the schedule array property.

[3:47] When we finally have all our code selected and copied, we can head back to our Lambda and paste it in. Once our code is pasted in, we will go ahead and replace this JSON.stringify('Hello from Lambda!') with JSON.stringify(prettyPrint()) and update the parameter to use the schedule array. Let's go ahead and test this again.

[4:12] First, we'll go up to the top and we will hit Deploy. Then we can test it. Pro tip, make sure you deploy before you test. You'll now see that we have a long string with a JSON structure inside of it. There's a reason why we're doing that. For now, I'm going to go down to the bottom and replace the call to JSON.stringify() with a direct call to prettyPrint().

[4:36] Let's deploy it one more time and then click Test. You can see here that we are now getting a more standard-formatted JavaScript array, but we still need to expose this to the outside world. To do that, we'll need to create an API gateway, which requires a string instead of a raw JSON object.

[4:58] For now, we'll put JSON.stringify() back with a call to prettyPrint(), and we will deploy it. From here, we'll create an API gateway so we can hit this function from the outside world. We're going to scroll all the way up to the top and add a trigger.

[5:17] We'll click API Gateway, go to the dropdown below, and create a new API by selecting Create an API. We'll go with HTTP API because it's the simplest type. Let's leave security open for this example.

[5:33] Under Additional Settings, we'll name our API. In this case, AWS has tacked on a redundant API suffix, which I will remove. We'll want to click the checkbox to allow cross-origin resource sharing, and then we're clear to go to the bottom and click Add.

[5:51] Now that this has been deployed, we can go back and select Trigger and see that we now have an API endpoint. Let's click on this and see what happens. What do you know? This is the data structure we've been working with this entire time but fully accessible from a public URL. Now, let's go ahead and curl this endpoint from the command line, and we have lift-off.

[6:17] I hope this session has given you an idea of how easy it is to create a basic function, put it into AWS, and finally deploy it and call it from either the browser or the command line.

https://app.egghead.io/api/v1/lessons/javascript-create-an-endpoint-with-aws-lambda-and-api-gateway/transcript

https://app.egghead.io/api/v1/lessons/javascript-deploy-an-aws-lambda-function-with-the-serverless-framework/subtitles

Instructor: [0:00] Let's take a moment to talk about streamlining our development workflow in the Cloud using a framework like serverless. It's not my intention to turn this into a serverless framework course.

[0:12] I do believe that as developers, the closer we can get to our pre-existing workflows, the better off we will be. We won't be going in depth about installing the serverless framework, but there's a solid right up on their website about how to do that.

[0:28] Let's assume that you've already installed the serverless framework and integrated it with AWS. You can verify this using SLS, which is an alias for serverless-V. You can see in this case that I do, in fact, have the framework installed.

[0:47] With that verified, let's go ahead and create a project. We'll use SLS create-t for template. We'll use the AWS node template. Finally, -p for project, and we'll call this project Egghead Streamline API. That's going to generate a project for us. Now, we can step into this project we just created and open it in VS Code.

[1:15] Inside of my project, you can see that there are three files. The first file is your handler.js, and it's very similar to the previous example. It's a handler that takes an event and returns a response object. The next file is the serverless.yml file, which has quite a bit, what I would call, cruft in it. It's serverless trying to be helpful, but in this case, we don't need it.

[1:40] We'll delete everything in the comments. When we're done deleting all of that, we should have about 12 or 13 lines of YAML remaining. That's all we need to get started. This is going to define the infrastructure that we're going to use to deploy this Lambda into the Cloud.

[2:01] From the command line, let's use sls deploy. This will take everything, zip it up, put it into S3, and finally, deploy it into the Cloud on our behalf. The steps that we've done in the console up to this point are now being done behind the scenes. Now, we can move over to the AWS Console inside of our browser.

[2:25] If we Refresh this, we'll see that we now have our function inside of the service, which we can step into and check out. You can now see that the function that was in our code is now in the Lambda. There are a number of ways that we could go about testing this. In this case, let's do it from the command line.

[2:45] From the terminal, we use sls invoke -f hello. Hit Enter, and you will see the response object inside our terminal indicating that we have been successful. The next thing we want to do is to expose this as an API endpoint using the API Gateway.

[3:02] Fortunately, this is even easier using the serverless framework. Underneath the handle of property, let's add in an events property. Then like so, we'll define an HTTP API entry. From there, we're going to double tap over. This is really important.

[3:24] We're going to add in our route, which this case is going to have a root path of forward slash and use the getMethod. Let's go ahead and deploy this from the command line with sls deploy.

[3:40] Once this is fully deployed, you will see that we have an endpoint that we can click on and see in the browser. Not only do we have our messages, but we can also see the event itself with a bunch of interesting details.

[3:55] If we go back into our AWS console and refresh the page, you'll see that along with our Lambda, we also have a API Gateway that is attached to it with all the details, such as an API endpoint, it's security details, etc., etc.

[4:13] Let's go back to our Egghead Hello API function that we created previously. We are going to copy the event itself, the schedule, and the pretty print method. We'll go into our handler here and we'll paste this all in.

[4:37] Once this is pasted in, we'll take the response object and modify it, like so, to return the result of calling prettyPrint() with the schedule. From here, we can go back to the command line and deploy it with sls deploy.

[4:57] After this is deployed, we can click on the endpoint link that's generated, and we should see our weekly schedule. Back in our AWS Console, we can navigate to our streamlined API definition.

[5:17] When we look at the code inside of this Lambda, you'll notice that as expected, the code that we deployed from our editor is now inside of the console.

[5:30] I want to show you one other thing quick, and that is how to spin down a deployment. Using sls remove from the command line, everything that was defined within our YAML will be removed. If we head to the AWS Console and go back to our functions and Refresh, you'll see that our function is no longer there.

[5:57] This has been a quick tour of how to accelerate your development workflow using the Serverless Framework. What I appreciate about this approach is that, when I'm using the Serverless Framework, it's business as usual. I feel like I'm programming how I always do, but somehow, my code ends up in the Cloud. I think it does a great job of shortening the distance between function and endpoint.

https://app.egghead.io/api/v1/lessons/javascript-deploy-an-aws-lambda-function-with-the-serverless-framework/transcript

https://app.egghead.io/api/v1/lessons/javascript-create-a-mock-api-endpoint-using-faker-and-serverless/subtitles

Instructor: [0:00] To reinforce how easy it is to take a JavaScript function and deploy it to an endpoint, we are going to build out something that I personally find to be incredibly useful. Generating a mock API that represents or stands in place for a real API when it becomes available.

[0:19] We're going to do this using faker and moment. As a result of the fact that we have npm packages, we're going to deploy this using serverless to save us a bunch of time. Inside of StackBlitz, the first thing that we're going to do is import faker.

[0:39] We're also going to import moment.js so that we can generate some dates. For a thought exercise, let's start with an interface. In this case, a user interface. You can see here that we have a number of properties that essentially establish a contract that we have to meet.

[1:00] Based on this interface, we're going to generate an array of user prompts. That means we're going to take the properties of the interface and create an array of strings that references those properties. From here, we are going to create a few utility functions.

[1:21] The first one is a function to generate a random integer between two predefined numbers. We'll pass in a min and a max, and then, using faker.datatype.number(), we're going to get a random number.

[1:38] Then we'll also generate a function that's going to create a random date. To do this, we'll use moment().subtract(), which will take this moment right here in time and then will subtract some amount of days from this also using random int.

[1:56] Finally, we're going to format this using an MM-DD-YYYY format. With that out of the way, we are going to create a HashMap that we're going to call Generators. This is a key-value pair that maps the key for the properties to a function that will generate a value for that particular property on that object.

[2:20] The first property that we're going to generate is for the ID. We'll generate a UUID so that, when we go look for that ID, it calls this function. Same thing for first name, we're going to use the First Name property on faker, so faker.name.firstName(). For the last name, we will use faker.name.lastName(). Now we'll start to build this out.

[2:46] One thing that we will introduce for a number of these particular properties, is that we need to pass in an argument. This is a second property on the param object that we're passing in. We have a function and we also have args. We've done title, notes, and progress.

[3:01] Let's also do active, which is of type Boolean, so true or false. Then we can also do a start date, which is going to call getRandomDate. This is really powerful because we can now create a generate function that takes in the props, as well as the generator's object.

[3:26] Then generate a new object and return it by iterating over the props array. Then for every prop, it will look up the generate function on the generator's object, and then populate that key in value on the object that we're generating.

[3:45] In this case, object prop using array notation. Then we're calling generator.func, or function, and then we're passing in generator args if it exists. Notice that this is called generate because we could really use this to generate anything, not just users.

[4:06] With that said, let's create a generate users method here and then pick a random number of users. We'll start with many users and max users. Then create a length property that calls getRandomIt, which is going to give us any number between 3 and 12 in this case.

[4:28] Next, we'll do something a little clever using ES6, which you will see when we generate the users array. We're going to call array.apply. Then create an empty array by passing in this length value. We can map over this empty array.

[4:46] For every empty element or space in this array, we can now return a generated user in its place. Also, at the end here, we will return the users array. Let's go ahead and update this call to update inner HTML. Let's add in the pretext so we get a pre-formatted block of markup.

[5:11] Then we'll call json.stringify, pass in the result of calling generated users. We'll add in null and to, to format the result. As you'll see, we have generated a random array of random users, which I could easily regenerate again here. You can see, it's completely different. One more time.

[5:35] This is the JavaScript that is necessary to generate a random collection of objects that we're going to use in our mock API once we deploy it. To that end, we'll open up the terminal and use it to generate a new serverless application or project.

[5:55] From the command line, sls create, we're going to use the AWS Node.js template. We're going to call this project "Egghead Mock API." Once this is created, we're going to step into the folder and open it up in VS code.

[6:13] You can see that within our project, we have our standard three files. If we look at the Handler.js, this is pretty standard. Let's go ahead and delete these two lines. From here, let's copy all of this code down to the last little bit, which we will skip.

[6:37] Then we will paste this in and we're going to get rid of this Typescript interface, which doesn't belong here. We'll go ahead and delete that, and save it. What we can do is update the handler here.

[6:54] We'll call this users and we'll update this call to JSON.stringify so that it calls generateUsers. Then let's clean up the output of this by putting in null and to. From here, we should install the dependencies for this project, npm i faker and moment.

[7:18] Now that these are installed, you'll see in the project that we have our node modules, package.json and our package-lock.json. Next, let's hop into our YAML and clean this up by deleting all of these comments. After that, let's change our function to users as well as our handler.

[7:40] We'll also want to add in an API gateway, so events. We're going to use the HTTP API. We'll set up our route or path to be API users, and our method will be git. We can deploy our project, so sls deploy.

[8:09] What this is going to do is to create the stack, but it's also going to generate some CloudFormation files. Generate everything into a zip, put it into S3, and deploy it. We can take this endpoint here, and copy it. Then let's open up a new tab in our browser and paste this in.

[8:32] We're going to let this run and you'll see now that from our browser, we're generating a random API. We can Refresh this a few times and see a different set of users every time.

[8:46] If we look inside of our Lambda serverless here, we can see that we have a mock API function here that we can step into and see. It comes with a function and a trigger. You'll notice that in the code source, we can't actually do any inline editing.

[9:08] That's because the dependencies are too large inside of the zip file, but what we can do is test this from the console. Let's create a test event. We will click Test and we'll see that the response is the same as what we observed in the browser.

[9:28] If we scroll up, we can see that we have an API gateway that's attached to this function that we're using to call the function, which we defined in the serverless YAML. Let's look over this code briefly.

[9:41] You'll notice that we took an interface and generated a user props array that we're iterating over and referencing the generator's HashMap and matching the key to a function that will generate a random value and assign that value to a property on the generated object.

[9:59] That is intentionally generic. On top of this, we have a specific function, generateUsers, which generates a custom collection of Bonk objects per our definition. From here, we're calling generateUsers and putting that into JSON.stringify.

[10:19] What I think is pretty interesting here is that we're only looking at about six lines of code for the server portion of this feature. We converted general-purpose JavaScript into a serverless app in about six lines of JavaScript an a few lines of YAML. Not bad for a day's work or in this case, about a 12 minute video.

[10:41] One last thing that I want to show you before we ride off into the sunset, is how to tear down the stack that we created. From the command line, we'll use sls remove.

[10:55] This will tear down the application stack that was defined in the serverless YAML. It's as easy as that. In the last 12 minutes, we learned how to very quickly define and deploy a mock endpoint into the Cloud using JavaScript functions.

https://app.egghead.io/api/v1/lessons/javascript-create-a-mock-api-endpoint-using-faker-and-serverless/transcript

https://app.egghead.io/api/v1/lessons/javascript-trigger-a-custom-webhook-with-a-serverless-function/subtitles

Instructor: [0:01] I am really excited about this lesson. Not only because it is incredibly useful, but also because it's incredibly fun. We're going to learn about Serverless Functions in the context of webhooks and how we can use them to integrate with the real world.

[0:16] This is going to set the foundation for learning Internet of Things or Internet of awesome things. Our example is going to start in Zapier, where we're going to use a trigger webhook to kick off an action inside of a Google spreadsheet.

[0:31] Webhooks up until recently were a premium feature, but they've actually made that part of the free plan now, which is really handy. To kick this off, we are going to use a Catch Hook, which will generate a custom webhook URL, which we will use later.

[0:50] You can also make some additional adjustments to the trigger. One of which is the ability to respond with an empty body. We'll leave this unchecked and move on to testing the trigger.

[1:01] I like this a little bit more than if'd, if this then that, because you can send a test request to this endpoint here and it will pick it up. Then you can use that for a template in the rest of your integration. In this case, we're using a spreadsheet in Google Sheets.

[1:18] We're going to create a spreadsheet row, use my Gmail account. Then we're going to determine the spreadsheet, and then the worksheet within that. Then it's going to have two columns, a timestamp, and a task column where we're going to use the task off of the payload.

[1:40] From here, you can go ahead and test the action which I've already done. Doing this is a good way to ensure that your integration is up and running. We are now ready to create and deploy our Serverless Function. From our command line, let's do sls create.

[1:56] We're going to use the AWS Node.js template. We're going to call this project, Egghead Zap Webhook. We'll hit Enter. Now that this is created, we'll go ahead and step into the project and open it with VS code. Let's start with the handler.

[2:17] The first thing to do is clean up these lines here and we'll clean up this call to JSON.stringify(). We'll need to install our dependencies. We will npm i axios, which is what we're going to use to call the webhook. Then from here, we are going to import our axios dependency. Let's close this left panel to open up some space and then import our dependency.

[2:46] Next, we can create an asynchronous function called Zap, which accepts a task parameter. We are going to make a post request to our endpoint. We'll deconstruct the data property off of that response.

[3:02] Inside of this call, we'll take the task parameter and assign that to the payload object that we're sending over the wire. This first parameter, which I've intentionally left blank, is here so we can take a moment and talk about a specific technique that I like using with serverless.

[3:18] We typically do not want to allow sensitive information like keys or URLs to leak into our source code. To avoid this, we can embed these inside of the Lambda, and then access them via environment variables. In this case, process.env.zapURL, which we will set up a bit later.

[3:43] We will return this response and then parse out this event object. To do that, we'll turn it into JSON using json.parse, and then pull the task off of the object. If it doesn't exist yet, we'll just use pending for now.

[3:59] Next, we'll call Zap, take this result, pass it into this JSON.stringify() call, and format it using null and to. We will also change the name of this handler to Log. We are ready to define the serverless portion of this project. Let's open up the serverless YAML.

[4:23] As usual, get rid of all of the craft. That means we'll delete this here and we'll go ahead and delete this here as well. I feel like there should be a minimal template we can use to build our projects from because this definitely becomes a little tedious.

[4:41] Let's go ahead and change the name of the function to Log, as well as the handler reference to Log. Next, we'll add in our gateway, so events HTTP API. We'll set up our route and our method. Great. We are ready to deploy this project.

[5:01] We'll go sls deploy from the command line. We'll let the serverless framework do it's magic. It's going to generate a bunch of Cloud formation items, zip them up, put them into S3, then create the stack and validate it. Once this is complete, we are ready to test it out.

[5:20] Let's go back to the AWS Console and verify that our Lambda was created. To do that, we will Refresh the page. With a little bit of luck, we will see that our Zap hook Lambda function is in fact, in place.

[5:38] We can see here that we also have our API gateway along with our Lambda function. This is the code that we wrote in our local environment, but you'll notice here we still have this process.env.zapURL, which we still need to set up.

[5:58] Let's scroll up a bit and click on Configuration, click Edit, and click Add. Then type in the key and paste in the URL as the value. Once we click Save, we should see that we have our environment variable in place, so that when we call the Zap function, everything is in order.

[6:21] We can test this from the command line using Curl. Curl-X post, and then we'll add in a header of content type application JSON. Then on the next line, we're going to add in the data that we're going to pass in.

[6:43] This is the JSON object that we want to pass in, which will include the task and some value. In this case, we'll go with hello from the command line. Then last but not least, we'll go ahead and paste in the URL for our endpoint.

[7:04] Make sure that we have the full route and hit Enter. Hopefully, we have a successful event. Indeed we do. If we jump into our spreadsheet, we should see this event properly logged. That's awesome. We can do better.

[7:23] You probably noticed how tedious it was to write that entire Curl command from the command line. That's not something I really want to do every single time. Instead of doing that, let's wrap this in a convenience function within our terminal such as Bash, or dun, dun, da, da, Z shell.

[7:44] What we're going to do is open up our shell config file and create a function called C log for Cloud Log to reconstruct this Curl command. Most of this is the same.

[7:57] The main difference is that we have that $1 inside of our data structure, which is capturing the first argument from our command line when we call the function, so it gets passed in as the task. Let's go ahead and source our configuration file.

[8:16] Once it has been reloaded, we'll call C log and go, "Hello Demo." It looks like we have a successful event, which is very promising. Let's check inside of our Google Sheet where we can see that this event has indeed been logged.

[8:38] I think you'll find this to be a pretty convenient integration. Let's do a quick review. We are calling a webhook that we defined using axios, putting that URL inside of an environment variable that we store inside of our Lambda, and then simply parsing in our event.

[8:59] Once we get the return from Zap, we're, stringifying it, and sending it back as a response. All in all, this is a fairly quick integration. The ability to log results from a command line, and then have it go out to a Lambda, then to Zapier, then into a Google spreadsheet is pretty awesome.

[9:22] If I must say so myself, that is all there is to it.

https://app.egghead.io/api/v1/lessons/javascript-trigger-a-custom-webhook-with-a-serverless-function/transcript

https://app.egghead.io/api/v1/lessons/javascript-scrape-a-webpage-with-a-serverless-function/subtitles

Instructor: [0:00] In our quest to do wildly useful and wildly profitable things, our next example is going to be a screen scraper. The idea here is as follows. First, we'll pick a site. In this case, the college football ranking site from ncaa.com.

[0:18] Next, using a Serverless Function, we'll go in and parse the website with axios and Cheerio. Finally, we'll convert this particular table into a JSON structure and prettyPrint it so we can display it in the browser in a meaningful way.

[0:35] To get started, we are going to create a new serverless project. From the command line, we will use sls create. We're going to continue to use the AWS node template. We'll call this particular project, "Egghead NCAA Rankings." We'll go ahead and create this. Next, we'll step into the folder, and from here, we'll install the axios and Cheerio packages. Once these are installed, we can hop into our code and start to build things out.

[1:18] Let's jump into the Handler.js() function, where we'll clean up these two lines, close the left panel for extra working space, and then import axios and Cheerio. Axios is for our HTTP request. Cheerio is for parsing the DOM. It's like jQuery for Node. Next, we'll create a property to store our URL.

[1:46] Then let's create a convenience object called Props that maps the index of the column to the property that it's referencing. The first column is Rank. The second column is School. The third column is Points. The fourth is Previous, and the fifth is Record. Then we will provide a convenience method that allows you to pass in an index in get the property value off of the object.

[2:12] Let's create a method to fetch the HTML. This is an asynchronous method that takes in a URL, and this is where axios earns its lunch money. We're going to create a try-catch block, and within the try block, we're going to make a GET request.

[2:31] Then, using object destructuring, we're going to pull the data off the response and, if that is successful, return the data. If something goes wrong, we'll do a console log and let the world know.

[2:45] With that done, we are now going to create another method called scrape. This is where the real magic happens. Let's step through this slowly and see how this works. The first thing we're going to do is call fetch HTML and get the raw data from that page. In this case, the raw HTML.

[3:05] Next, we'll need to convert this into something we can parse. We're going to load it into Cheerio. Side note, the convention here is to use a dollar sign, like jQuery.

[3:19] Now that we have the ability to crawl this DOM and start to do things with it, let's step into the page and take a look at how this works. This is just old-fashioned parse the DOM and look for ways to find the pieces that you need in the page that you're looking at.

[3:36] On this page, I'm going to right click, and then I'm going to click Inspect. We are looking for something in the DOM that we can use to start our query. I see that there is a div with an ID of block the spin content. This is a good starting point.

[4:01] If I scroll down, I can look for something that actually holds the table portion of the page. Here we have it. Notice that when I select the part of the page that I actually care about, it is highlighted.

[4:18] If I step into this, you'll see that it's full of a bunch of table rows, which is exactly what I want. Then if we open this up, you'll see that we have five cells in here, which is what we're going to parse over and what our convenience function and data structure are pointing to.

[4:39] Rank, school, points, previous, and record are the columns that were going to use to convert into JavaScript objects and then prettyPrint them. Let's hop back into our code and let's start to build out the parsing logic within this.

[4:59] I'm going to say, give me the results and then I'm going to start with a query to the block the spin content. Then from here, I'm going to do an additional query that says, go find the T body and return all of the table rows.

[5:14] This returns a weird JavaScript object that I found to be hard to parse, but I was able to solve this by simply converting this into an array. Before we go any further, I want to tie this function off for a moment and work on two other functions that we will build out and then add into our scraping logic in just a moment. The first function that I want to build out is the logic around parsing the DOM itself.

[5:47] To that end, we are going to create a function called parse result that takes in our Cheerio object and the element that we want to convert into a JavaScript structure. We'll start by creating an empty object, and then we will return it.

[6:08] We need to do something magical in the middle. We want to take this element, and using Cheerio, take the table row and say, within this table row, give me the table data element or TD. Then we're going to iterate over this particular array of table data elements.

[6:30] For each, we're going to loop over and assign a property on the result object using getProp. Then we'll get the value using Cheerio. This property is going to equal the element, or more specifically, the text inside of it.

[6:49] We are essentially parsing over the element and turning this into a JavaScript object. Let's create one more method called prettyPrint(). This is a little bit more simple. It just takes the result object itself.

[7:08] We're going to create a single prettyPrint string that just says, results school with a result record. We are ready to come back up and finish our scrape method. We're going to map over our array, parse the results, map over that array, and then prettyPrint the results.

[7:34] This is functional programming for the win. We'll format this document just a bit. Then we'll be ready to update our handler. The first thing we'll do is call scrape and then save the results of that call to a JSON property, which we will use to update our call to JSON.stringify.

[7:55] We are also going to update our handler name to Rankings. Just to review. Let's start at the top and work our way down through what we've done up to this point. We've imported axios and Cheerio and created a reference to the URL we want to scrape.

[8:13] We've created this props convenience method here, to map that to the table that we're parsing. We have our fetch HTML function that goes and gets the page. Then we have our scrape method, which converts our page into a Cheerio structure.

[8:32] We've run queries on that structure and using functional programming, we have parsed the result. Then we use prettyPrint. After all of this, I think it's pretty amazing the serverless portion here is only about seven or eight lines of code. Moving on.

[8:49] Our next step is to deploy this is a Serverless Function. Let's hop into our serverless YAML file. I've taken the liberty of cleaning this up and deleting the extraneous comments. You're welcome. We can jump right in and change the method here to rankings, along with the handler.

[9:12] Let's add in our API Gateway using events HTTP API. Then set the route as path, which in this case is going to be 4/API, 4/rankings. Then finally, we're going to set the method to git. With that saved, we'll jump into our terminal and we will sls deploy this project.

[9:37] Once this is deployed, ideally, we'll be able to pull up the browser and see everything rendering. I have to be honest. I'm a little bit nervous here. I stand on the precipice of possibility, and I really hope this works. The moment of truth.

[10:01] We'll copy this input URL here, hop into the browser, open a new tab, paste it in, and lo and behold, it worked. If I click on this tab, we have some HTML that we have successfully scraped into this array right here.

[10:23] We were able to do this with just a little bit of JavaScript in a very tiny amount of serverless, which I think is amazing. I hope you find this to be incredibly useful and profitable.

https://app.egghead.io/api/v1/lessons/javascript-scrape-a-webpage-with-a-serverless-function/transcript

https://app.egghead.io/api/v1/lessons/javascript-generate-a-pdf-from-a-lambda-function-and-store-it-on-aws-s3/subtitles

Instructor: [0:00] In this lesson, we are going to do something a little more advanced. We'll create a Serverless Function that generates a PDF and then saves it to S3. In doing so, we will learn some new techniques along the way.

[0:16] With the most important one being, how to integrate with additional AWS services from a Lambda function. To get started, let's create a project using our typical node.js template, and call it "Egghead PDF Generator."

[0:31] We'll generate the project and then step right into the generated directory and open this up in VS code. We're going to start with the serverless YAML file first, and work through that. Let's close the left-hand side and get started.

[0:51] In the serverless YAML file, we'll change the function name from Hello to Generate. Then also change the handler. Next, we'll define our API gateway. We'll create an events property here.

[1:06] Set it up as a basic HTTP API gateway with a route of API PDF and then use a method of post. We're going to introduce something we haven't talked about before. We're going to define two environment variables that we want to use inside of our function.

[1:28] To do that, we simply add an environment property into our YAML. The first property that we're going to add is the bucket that we want to upload our PDF into. We'll define this as bucket. You'll see that we're referencing custom bucket, which we'll define in just a moment.

[1:48] We'll also define the region. We can find this out using AWS region, which pulls that from our local configuration when we set up serverless. From here, let's jump up to the top and add in our custom variable.

[2:05] We'll add in a custom property, and then underneath that, we're going to add in bucket. Finally, we'll give this the value of NCAA football stats. This is looking pretty good so far, but we'll need to do one additional thing.

[2:23] When creating interoperability between multiple AWS services, we need to make sure that everything has the right permissions to communicate with each other. Inside of our provider declaration here, we need to define some IAM role permissions,

[2:41] To do this within IAM role statements, we're going to create and allow effect, and define it for two specific actions, S3 put object and S3 put object ACL, which is saying that we now have the ability to use the underlying ACL object to determine if we have access.

[3:01] We also want to define the resource that we are providing these permissions for. Let's create a resource entry. Using the custom property that we set up, we're able to locate that via NARN. Let's take a moment here to do a quick review of what we've done up to this point.

[3:22] We've created a custom property. We've defined our custom IAM role statements. We've generated a pretty standard handler with an API gateway that has some custom environment variables.

[3:35] Now that we've reviewed, let's jump into the console so we can take a closer look at the S3 bucket we're working with. What I've done in this case, and you won't want to do this for something in production or that has any security interest.

[3:49] I've opened this up so that it has full public access. I've also created a custom bucket policy, which essentially says that for anything we've put into this bucket, we can get that object and anybody is allowed to do that.

[4:04] We want to do this so that once we've uploaded a PDF and gotten that URI back, we're able to click on it and see the PDF. With all of that infrastructure out of the way, let's move on to the JavaScript portion of this lesson.

[4:21] We're going to hop back into the command line and install two dependencies, PDF kit and AWS SDK. Once these are installed, we can get back into our code and start to build out this handler. Let's clean up this entire handler and delete everything in there.

[4:44] Bear with me, because what I like to do next is approach this from a little bit of a different angle because I know where we're going and I think this will create a better narrative arc.

[4:55] We're going to define the workflow inside of the handler and then build out the underlying functions that we're calling. Next, let's change the handler name and pull the body property off of the event parameter.

[5:11] We'll want to continue on by parsing the body, and if it doesn't exist, turn it into a pending string. After that, we'll define the first step in our workflow, which is going to be generating the PDF. We'll take this text, send it into the generatePDF() method. This will return a PDF, which we will then save to S3 via save PDF.

[5:41] Then finally, generate a URI to return within the response body that we can use to view the PDF in the browser. Generate a PDF, save a PDF, and then generate a URI. With that defined, let's go to the top and build this out.

[6:04] We'll go ahead and add in our dependencies, PDF kit and AWS SDK. Then we will create an instance of S3 off of the SDK. Then we will create a key property, which is simply going to dynamically generate a unique name for a PDF.

[6:27] From here, we'll build out our generatePDF function. This is an asynchronous function that takes in whatever text we're going to send it. Then inside of the function, we are going to return a new promise that we will resolve in just a moment.

[6:49] Then inside of this function, we are going to create a new instance of PDF kit. We will define a buffers array, where our content will be stuffed until it gets converted into a PDF. We're also going to call doc.list, and send in that text which will create a numbered list of content.

[7:11] Next, we'll add in an event handler on the document itself using doc.onData, push any content that comes into the buffers array, and then define an end event handler. At this point, we're going to concatenate all of the buffers and that's going to become the PDF.

[7:37] Next, we'll call resolvePDF, which completes the promise. Then we'll call doc.end. We're taking in the text, pushing it into the buffer, and then resolving that promise, which then gets put in to savePDF.

[7:56] This is another asynchronous method that takes in the key we defined at the top, as well as the PDF we generated in the generatePDF() method. We need to put this into S3, so S3 put object. Then we're going to define a parameter object.

[8:14] This is going to take a number of properties, starting with bucket. We're going to pull that off of the environment variable of bucket. We're going to set the key and the body, which is the PDF itself. Then we'll set the content type as application PDF.

[8:32] We can put in some additional things here, such as ACL. In this case, if we wanted, we can set it to public read. Then we will define our event handler function for this operation. If it's an error, we're going to log it out. If it is successful, then we're going to log that out as well.

[8:55] We also want to use this as an opportunity to resolve the promise. With this being resolved, this leads us into our final method in the workflow, which is generateURI(). This does basic string interpolation. We're going to generate a URI by filling in these three values.

[9:16] The first one will be key value. The next one will be the region that we're in. The last one will be the bucket that we're targeting. Let's take another quick minute to review this workflow. We're taking the body property of the event object and parsing it.

[9:34] Then using some functional style programming, we're generating the PDF, saving the PDF, and then returning the URI to the PDF in the response object. To move forward, let's hop into our terminal and deploy this application.

[9:53] While this is deploying, I would like to point out that the zip file that we are generating is 21 megabytes in size. This is because of the dependencies inside of the project. We'll talk more about this in a moment. First, let's step into the AWS console and take a look at our application.

[10:15] If we click on Configuration, we can confirm that we were able to generate two environment variables, the bucket and the region. Remember what I said about the zip file being quite large. You'll notice here in the code window, we are not able to do inline editing.

[10:35] This is one of the reasons why we use something like the serverless framework. Let's go ahead and test our function. We are going to update this test value here to have a body property, and then a string of an array of strings. We'll save this event and click Test.

[10:56] Then inside of our results, we can see that we have a URI in the body of the response. I want to click into the S3 bucket really quick and refresh the page so that we can see that. Lo and behold, we have a PDF inside of our S3.

[11:17] If we copy this URI here, we can paste this into the browser and confirm that a PDF was generated from our test event. One more quick review before this lesson is over. We defined a pretty standard Lambda function with an API gateway.

[11:39] We also added in some environment variables, a custom property, and some permission statements using IAM role statements to give us the ability to upload a PDF into an S3. Then within our JavaScript, we built out our trifecta workflow of generate, save PDF, generate URI.

[12:02] Then we used PDF kit in the SDK to both generate a PDF and save the PDF to S3. What I love about this is that with a very short amount of code and a little bit of markup, we were able to create an effective non-trivial workflow.

https://app.egghead.io/api/v1/lessons/javascript-generate-a-pdf-from-a-lambda-function-and-store-it-on-aws-s3/transcript

https://app.egghead.io/api/v1/lessons/javascript-create-lambda-step-functions-in-the-aws-console/subtitles

Instructor: [0:00] In this lesson, I'm going to show you something incredibly powerful and deceptively simple. As a matter of fact, we are not going to write any code at all, because we have all the tooling required within the AWS console to accomplish what we need.

[0:18] In this lesson, I'm going to show you how to create a step function. The premise here is that we can string any number of Lambda functions together where the output of one function becomes the input of another.

[0:31] To demonstrate this, we'll take the JSON output from this NCAA rankings Lambda, and feed it into this PDF generator Lambda, which will then save those rankings into a PDF. Let's take a look at the step function service and see what it will take to create a state machine.

[0:52] We're going to design our workflow visually and we're going to use this first option. We will go with an Express state machine because we need to call our state machine synchronously, which we will do in just a moment. Inside our visual designer, we are going to define our first state, which is going to be a Lambda invocation.

[1:17] Let's go ahead and give this a state name and then choose the function name that we want this to call. We're going to choose the NCAA latest. Go ahead and select that. Our next state is going to be a new state, not an end state. We'll drag another Lambda in.

[1:47] Give this a name of print stats. We will go down and choose our second Lambda that we want to call, which is PDF generator latest. Then we will choose, "Go to End." Finally, click Next. What this does is generate a JavaScript, or JSON structure that defines our state machine.

[2:15] This is really nice because you can then check this into version control and do some really interesting things with it. Let's go ahead and click Next and we will name our state machine. In this case, College State Machine. We'll allow this to create a new role, default log level.

[2:36] Then we will create the state machine. Once this is created, we will test the execution of the state function.

[2:47] Before we do that, let's hop into S3 and clear out all of the PDFs that have been generated up to this point. This will make it easier for us to test whether or not we have created PDFs and also make it easier for us to find them.

[3:03] Now that we have cleaned out this S3 bucket, let's hop back into our step functions and we will start an execution. Once this is complete, we will see that in the output, we have a URI to a PDF. We'll paste this into the browser and view it. Well, it looks like something has been created.

[3:29] Let's take a look in S3 and refresh. Baboom! Here we go. We'll go ahead and delete this one more time and then we'll take a look at how we can call this from the command line. It's important to know that you can execute a state machine in a bunch of different ways.

[3:49] In fact, it wasn't really designed to be called directly from a user, but rather to be triggered to kick off some long-running asynchronous task based on some other external event. That said, we are going to approach this using the CLI.

[4:06] We are going to go AWS step functions, list state machines, and we're going to copy the ARN of the state machine that we just created. From here, we are going to call AWS step functions. We're going to synchronously make a call via start sync execution.

[4:27] We will pass in the ARN that we copied into the state machine ARN argument. What you'll see here is the output of this call. In this output, we can copy this URI and easily see if it's real by hopping into the browser and verifying that yes, indeed, we do have a PDF. Yes!

[4:53] If we go back into our S3 bucket and refresh it, we can see that our PDF is indeed here. To recap the concept that I'm introducing here. By using step functions, we can create a state machine that allows us to string multiple Lambdas together and create some pretty interesting workflows.

[5:16] In this case, we were able to successfully attach the screen scraper Lambda to the PDF printer Lambda in a matter of a few minutes. We can execute a workflow where it goes and grabs the stats off of the NCAA website, converts it into a JSON structure, that gets passed into the PDF generator. The PDF generator interprets that data structure using PDF kit and then creates a new PDF and saves it off into S3.

[5:48] This demonstrates a very powerful, and I would say on some level, a very easy way to string Lambda functions together to create complex workflows. If you understand functions, you understand Lambda functions.

[6:06] If you understand Lambda functions, you understand how to string them together into step functions and build out really powerful workflows.

https://app.egghead.io/api/v1/lessons/javascript-create-lambda-step-functions-in-the-aws-console/transcript

https://app.egghead.io/api/v1/lessons/aws-course-outro-taking-aws-further/subtitles

Instructor: [0:01] As we conclude our journey from function to endpoint, we stand at the crossroads between endpoint and infinity. From this new vantage point, we can see that there are near-infinite and novel applications for a skill set that you already possess.

[0:17] As cool and entertaining as I hope these examples have been, the real value, I hope, has been imparted in the expansion of how you see the world. By this, I mean the realization that you already know enough. You just need to have a deeper understanding of the things you know.

[0:35] The idea of a basic function has been reduced to pure muscle memory. We provide an input, and we receive an output. This is something you've understood from the very first time you put a quarter into one of those sketchy vending machines in the lobby of some department store as a small child. You put in a quarter, and in return, you got a worthless trinket, valued at perhaps a few cents, but output nonetheless.

[1:10] We can reframe this concept to describe asynchronous processing events, like an NgRx effect. We receive input in the form of a trigger event, and we produce output wrapped in a completion event. Asynchronous processing event, this sounds a lot like a serverless function. We receive a request, zero to n things happen, and then we reply with a response.

[1:40] In code, this looks like a super basic function. Local functions are so basic. I hate to break it to you, remote endpoint function, you're not that extra yourself. In fact, all we have to do is wrap you in a request-response method.

[1:58] When it comes to deploying the function, the serverless framework is like economy extra. We can deploy this function as an endpoint in approximately 13 lines of code. If we really want to get deluxe, then, with another 12ish lines of code, we can integrate with an S3 bucket using a custom variable in a predefined IAM role permission set.

[2:25] Just like a series of functions that are chained together by passing the output of one input into another, we can implement an asynchronous middleware, like NGINX or Saga, that chains together functions via an event-based system. In fact, this is exactly what is happening with step functions inside of AWS. This is where things start to get interesting, in my opinion.

[2:54] As we saw the evolution of imperative logic move from the DOM -- thanks, jQuery -- to a component, then to a service into an architecture layer and ultimately distributed, we can see a similar evolution of a function moving from a local invocation into a framework, then to a server and ultimately into a managed endpoint. How far can we take this?

[3:23] Anything that can be reached via a webhook or endpoint is fair game. I recommend checking out Zapier or IFTTT. It's worth mentioning that most smart-hardware vendors, like Philips Hue, have developer APIs that you can integrate with. A few more practical examples that I pulled directly from the AWS site are as follows.

[3:49] We can build a web application using AWS Lambda and the API Gateway. We can build out the business logic to allow users to create, read, update and delete items that get persisted inside of a DynamoDB database, with the static content hosted via the AWS Amplify Console. Not long ago, this would have taken weeks and not hours to accomplish.

[4:16] We can also do sophisticated data processing. Imagine we have notes from an interview and Markdown that we're storing in an S3 bucket. We can use S3 events to trigger multiple processing flows, one to convert the Markdown to HTML and another to perform sentiment analysis.

[4:37] We can also do some interesting things with batch processing, like scheduling workflows on a recurring basis, using an Amazon EventBridge rule. In this example, we are pulling in a number of files at a predetermined time, and using step functions to process the files, we can then aggregate the results and ultimately communicate them using AWS SNS.

[5:08] For something super fancy, we can pull from a document pool that contains a variety of different document types. Depending on the document type, we can use Amazon machine learning services, like Amazon Comprehend or Amazon Rekognition, to look for patterns and insights within these documents.

[5:32] This has incredible implications when it comes to e-commerce applications, social networks and analyzing consumer, I mean user, behavior. Between these four examples alone, there is enough for an enterprising individual to make a fortune implementing variations of these ideas.

[5:53] On top of that, there's not a lot that is happening here that falls outside the boundaries of what a competent developer has already done a million times. As much as I hate coupling in code, I think it's even worse when we're coupled to beliefs that limit what we see as being possible for us to accomplish.

[6:16] The moment we decouple our expectations from that perception, we reach the incredibly exciting realization that we are free to build applications faster, easier, cheaper and better than ever before. I say this to you with absolute conviction and total desire for your success. You can go further.

https://app.egghead.io/api/v1/lessons/aws-course-outro-taking-aws-further/transcript

Transform Local Functions Into Endpoints With Serverless

Lukas Ruebbelke

What you'll learn:

You might also like these resources:

Cloud Infrastructure Fundamentals with AWS

Build a Serverless API with Cloudflare Workers

Develop a Serverless Backend using Node.js on AWS Lambda

Credits

Course Content

You might also like these resources:

Cloud Infrastructure Fundamentals with AWS

Build a Serverless API with Cloudflare Workers

Develop a Serverless Backend using Node.js on AWS Lambda