Journey Through Django–APIs, Sessions, and Keys (OH MY!)

After the wrong turns I took last week, I dove into using a form to integrate with Positionstack’s API. Thanks to their documentation, it was pretty simple to write-up a python script that enabled me to learn how I need to grab the necessary data. Giving credit where it’s due, I wouldn’t have made the progress I did this week without Vitor Freitas’ article on using API’s in Django. If you want a deeper dive into this subject, I highly recommend it.

So after digging through the weeds of which kinds of tests to use at what point in the process, getting acquainted with an API’s data structure, and utilizing that in Django, I thought it important to go back to a bird’s eye view. The overall point of this step in the application is for the user to see one of two messages. Either a “success” message & a link sending them to another page where they enter their power usage, or an “error” message for an invalid zip/postal code.

It’s All About Context

In Django, context is how you pass data to be rendered on screen. A good example of a use-case for this is a user’s account page on a blog site, where you only want to display information pertaining to that user. That information could be from a database within the app itself, or a remote API. Setting-up a conditional inside the html file itself to display different content based on the context being passed shouldn’t be a difficult proposition (I know, famous last words).

Working With Sessions

I’m sure that I’m just one YouTube video or blog post away from getting started in this topic, and I have to be careful to only dip my toe in as far as I need to. I have the tendency to get in that curiosity spiral where I suddenly find myself researching kernel module latency that may/may not come into play in my current situation. THere’s always a way to make data storage/retrieval more efficient, but it’s more about just getting overall functionality at this point. The idea is save the latitude & longitude to the session, and use that for the NREL’s API on the next page.

Securing API Keys

At this point, I’ve been hard-coding my key to Positionstack in the payload, as I tested it within Django. I know this isn’t good behavior long-term, and none of my commits actually have the key saved in the file (so no, you won’t find it in the repo). I have an idea on how this could work, based on my experience in handling API keys in Ruby on Rails, but I’m putting those aside before I do actual research. I definitely want to lock this part down before moving to the next stage.

Leave a Reply