⚠️ This lesson is retired and might contain outdated information.

Serverless Function 4

Tom Chant
InstructorTom Chant
Share this video with your friends

Social Share Links

Send Tweet
Published 2 years ago
Updated 2 months ago

In this final section, you are tasked with updating some code to successfully retrieve completion data from the response object. We modify the code to access the completion data from the "data" object instead of the "response" object. With the code updated, we push the changes to GitHub and test the functionality.

The key advantage is that our API key remains hidden, making it safe to share our projects without compromising the key. Additionally, we learn that the endpoint only accepts fetch requests from its own domain, ensuring that it cannot be accessed by other domains. We also briefly touch upon the concept of Cross-Origin Resource Sharing (CORS) and its importance when working with APIs and endpoints.

[00:00] Okay, so the last thing that we need to do is deal with these two lines of code. So let's go straight into a challenge. I want you to update the two commented lines of code to get this working. Once you've done that, you can push to GitHub to redeploy and then test. Now, when this was purely a front-end project,

[00:18] we were taking our completion from the response. Now we've got the response stored in data. So it's just a question of working out where you get the completion from within the data object. Okay, pause now, get it sorted, and we'll have a look together in just a moment. Okay, hopefully you got that working just fine.

[00:40] Now, these lines of code are almost correct. But now we have this data object, and what we want is stored in the reply. So I'm going to delete response. And let's go for data.reply.choices, and everything else can stay the same. Okay, let's copy that over to VS Code.

[01:02] And I'll just update these two lines right here. Then we'll push to GitHub to trigger a redeploy. And I'll ask the chatbot a question. We get back a completion. It's looking good. It's working. And best of all, when we open up the network tab, there is absolutely no sign of our API key. So there we are.

[01:22] We have successfully deployed our OpenAI project to the live internet with the API key hidden. And now you can safely share your projects and use them in your portfolio without fear of your API key being compromised. Now, you might be thinking, wait there, anyone can just access my serverless function.

[01:41] They can write their own fetch request to the URL, which of course is available on the front end. And then from there, they'll be able to use and abuse my OpenAI API key. Well, they can't. This endpoint is only going to accept fetch requests from its own domain. Now, we can prove that right here in Scrimba,

[02:01] because if we want to make a fetch request to this endpoint right here from inside a scrim, that should not be possible. Because scrims are hosted on scrimba.com, and this endpoint is using my custom Netlify URL. Okay, let's hit save. And I'm going to open up the console.

[02:20] And I'll just say, hey, and there we are, we get an error. We are not able to make a fetch request to that URL from within scrimba.com. And you can repeat that test from your own domain. Check out the dev tools and look in detail at the error you get.

[02:37] Now, of course, if for some reason we wanted other domains to be able to access our endpoint, we would be able to do that with the cause policy. Cause is the cross-origin resource sharing. And it is quite a big topic. But if it's completely unfamiliar to you, I do recommend you read up on it at some point,

[02:54] because it is really important when you start working with APIs and endpoints. Okay, we are done with this project. Let's just take one more scrim to recap what we've studied and talk about where you go next.

egghead
egghead
~ 15 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today