Implementing the Recorder

Now that we have functions that can access the table, let’s implement them in our controllers.

Start by requiring the recorder you built.

Your server is going to need your username and password to the database. Luckily, we already put them in the Parameter Store: Build Oracle DB/Tables

First, let’s replace params with paramsToFetch:

This is going to mean that you are going to have to refactor your code a bit by declaring all of the params variable separately, but it’s better coding to do it this way.

The problem we run into is that as we add more Parameters, there is no promise that they will come in the order that we want, so we will have to do things a little differently. Let’s use a for loop to match the parameters to their variables.

Let’s create and initialize some params we can pass to our recorder functions called DBparams.

Add a use of the addToTable function after it is put to the database (line 70 for me).

As you can see, it does a lot with out adding a lot complexity to your code.

Do the same for deletePerson and modifyPerson.

Run node index and use Postman to make a few requests to your server. Then check the table to see if it recorder recorded what you sent.

If they didn’t, debug and get help. If they did, great!!

This is looking good, but there is a problem we could face where if we get a ton of requests at once, we will open up a connection for each request until we are out of memory. To fix this, let’s set up a pool that we can hold a bunch of connections from and then use as needed so we don’t open too many.

We are going to need a way to get our username and Database from the favoritecolor controller. In your favoritecolor.js file, make a function called getDBParams that simply returns your DBparams.

Let’s return to our index.js file in the recorder directory and use the require function to import it.

Then let’s write a function to create the pool and if it is already created, then to pass the pool of connections to whatever function needs it.

You’ll notice that we are going to export it. I’ll explain why in a bit.

Let’s update our recorder to use the pool. It shouldn’t take much.

Notice how much it simplifies your code. Do the same for the rest of them.

You no longer need the default params (testing won’t work the same way anymore because if you run this file first, the getDBParams function won’t be ready to hand it the username and password when the pool is getting made). Let go remove those from our functions in the controller-

And the others-

Now, here’s the question, when do we want to create the pool? Don’t we want to create it when the first person makes a request? Hmm. That kind of punishes the first person, because they have to wait long. We can’t run it right away, because if we try and run it before the password and such has been removed from the data base we will have a problem. Let’s run it after we get the Parameters from the parameter store.

This will just get things set-up.

While we are here, it would be nice to set things up so that there isn’t problems if someone calls the database before we have our parameters from the parameter store.

Let’s wrap our listening function in our main index.js file.

Then call it after everything is ready to receive requests.

Get it up and running and then test everything to make sure it works!