This post is part of a challenge for the month of May where I learn something new about JavaScript each week and post a quick summary on the blog sharing what I learned.
Warning: This is NOT meant to be a JS tutorial. These are nothing more than field notes and observations. Some of this stuff may even be incorrect. This is a place for me to “think” things out as I learn. I’m just making it public because…that’s what I want to do. At this time. 🙂
I was supposed to post these JavaScript observations on Friday, but I had to go to bed early yesterday since we had our first dragon boat event of the year this morning. I wanted to be well-rested, so I went to bed and didn’t get around to posting. 🙂
So this week I didn’t dive much into JavaScript itself, but I did take the time to read up on a concept that I hear a lot but never quite understood. That is “endpoints“. As JavaScript becomes used more with APIs, AJAX, and fun stuff like that, endpoints are more important, maybe? I feel like understanding APIs and endpoints are important in general regardless of the language you’re working with.
I was looking for the official definition of an endpoint, but it’s hard to find. From what I understand, an endpoint is simply the end of a line of communication. In the context of JavaScript, endpoints are important when it comes to AJAX. Basically a script will request data from an AJAX endpoint, and receive something back. You can use endpoints in other languages that aren’t JS. For example if you’re trying to integrate WordPress with an external service that’s provided an API, then you’d communicate with that API via an endpoint.
I’m even working on a project right now for work that involves an endpoint, and that really helped me to understand better what they’re all about. In this project, we have a WordPress theme that includes a filtering function — users can filter a set of posts based on two different criteria. When users filter the posts, the posts meeting the criteria for that particular filter combination need to update on the screen in “real time”, without reloading the page. We need JS for the “real time” functionality, and for the posts we need data from the WordPress database.
The way we’ve set it up is (in the simplest of terms):
1. In WordPress, we use PHP to query a set of posts from the database and store it in an array.
2. The array of posts is then parsed into JSON, using a function called json_encode(). JSON is essentially a text file that stores data as a JavaScript object.
3. In our case, the post information becomes a JavaScript object that we can then use in our script. For example we can replace the existing posts on the screen with the “posts” in the JSON object when a certain event happens (like the user clicks on one of the filters).
4. The JavaScript needs a way to receive this JSON object. That’s where the endpoint comes into play. In our case, when a user clicks on one of the filter criteria, we send the name of the criteria that was clicked over to the endpoint, along with a specialized URL. The endpoint uses the criteria to query the database and do the steps outlined in #1 and #2 above. It then sends the data back to our script, where it can be used as described in #3.
What I have described is essentially a barebones outline of how AJAX works, I think? Maybe? Of course there are many more details and technicalities beyond what I described, but that is the gist, I think. I’m still a student so don’t quote me on any of this stuff, lol.
I did not write the endpoint in this case, my teammate did. I mostly worked on the JS script that uses the data from the endpoint and displays it on the front end, although my teammate helped a lot with that, too. 🙂 This week I made a point to study the endpoint closer, to see how it works, exactly. I feel like I’m a step closer to understanding them.
I mentioned earlier in this post that the concept of endpoints are important to understand since JS is being used for more than just adding fancy interactions to an HTML document. One example is using the WP REST API to receive all sorts of data from your WordPress site which you can display in your theme via JS. It’s similar in concept to what I described with the filter example above, but it takes it to the next level … you can create an entire theme using JS! Some of my colleagues are working on a prototype JS-powered theme called Picard, which is built using React (a framework for creating user interfaces with JS) and the WP REST API.
Before I read up on endpoints, I had difficulty understanding the REST API. Now I feel like I have built up enough basic knowledge to be able to study it further and understand what is, exactly, and what it’s doing. And also how it fits into themes like Picard. That’s a great feeling and I’m excited to keep learning. I’m also lucky to get to work with co-workers from whom I can learn.
