The way the Swagger project is set up, we are going to write the code for our endpoints in this controllers folder. I'm going to create a different file for each endpoint, just to keep everything nice and separated.
For example, if you remember back when we created our route end point, and for all of the others actually, I defined an ex-Swagger router controller and I defined an operation ID.
Just like we set this up, whenever we turned on, when we built out the custom function for mock mode, we are going to use that same format for defining API endpoints in our controllers folders.
I'm going to have a file named get all to-dos, which is where the router controller is going to look, and that's going to expose a function called get all to-dos that's going to fulfill the endpoint request.
I'm going to create a new file here. Were going to call it just like we discussed, get all to-dos, and then, we are going to expose that function, and now, we will create that function. Let's do a little bit of housekeeping first.
For my back end database, I'm going to use Elasticsearch. To do that, I need the Elasticsearch module installed in my project. I could do that with npm install, dash dash save, Elasticsearch. This just provides a little client that makes reading and writing to Elasticsearch a little bit easier.
Back over in my code in my helpers folder, I'm going to create a new file called ES.JS. This is just going to contain the boilerplate stuff for our Elasticsearch. I'm going to declare an Elasticsearch and then require it, and then create a client using the Elasticsearch module.
Inside of here, I'll define my host and it's running locally for me, it's going to be local host port 9200. I want my log level set to error.
Now in my get all to-dos, I can declare my client using that helper that we created. In my function, for get all to-dos, I just want to grab all of the to-dos, right? I'm going to do that with client.search, which comes from the Elasticsearch client.
Specify the index, and I'm storing everything in an index called to-do. And type is also going to be to-do. Elasticsearch, if you're not familiar with it, you can have different types within an index. I just named them both the same, again, is easier for me to remember.
The query string that we want to pass is a star for everything. Elasticsearch is going to return a lot of data along with that that is related to the searching and indexing that I don't care about, I'm going to use a source include and specify that I want the to-do ID, the to-do completed tags, author, completed date and due date.
That's going to have a callback that takes an error and a response object, and so here, it will have, if there is an error, we're going to send the error back to the client. Otherwise, we've got our results that are going to be coming back to us.
Let's take a look and see what that looks like. If I open up a browser, I can search my local Elasticsearch instance and searching the to-do index, and you see all this information we get.
Some information about the response itself, the number of shards, and primarily, what we're interested in is this hits object, which, inside the hits object is a hits array and then the items within that array are the individual responses from the Elasticsearch index.
Each one of those has the index and type information and then the underscore source is really the information that we're looking to return to the client.
We've got our data back from Elasticsearch and it's going to be in this format. We need to format it so it matches the schema definition that we promise to the client in our Swagger definition.
To do that, I'm going to create a results array and then the results array is going to be equal to that response, the response we get back from the client. Then the hits object, and then the hits object inside the hits object, which was the array.
We're going to do a map, and then, we'll map that with a function to hit that returns that underscore source object that we saw in the browser. Last thing I'll do is set the header so the client knows were passing application JSON and then we will send that results array back to the client.
We coded up the get endpoint and we've got this really cool Swagger editor with this amazing "try this" operation button so you got to try it out, right?
We'll scroll down here and we'll hit send request, because there's no parameters we get a response of success, and then in the rendered output here you can actually see the to-do items themselves as they are formatted from the API endpoint.
You can also use the pretty output and look at the raw, at the pretty printed JSON or raw, which is just the straight beautiful text.