(AP)I built this: The story behind crafting an International Space Station tracker

When I was in systems administration and operations, I heard the term API (Application Programming Interface) thrown around a lot. I knew little about them beyond being a means to interact with the data on various applications and databases. While trying to understand how they worked through mild research and conversations with colleagues, I cobbled together a rudimentary understanding that an API was either one of two versions: Open or Closed. My oversimplified definition of “Open APIs” (not to be confused with “OpenAPI”) was that they allowed the user to not just consume but also interact with data, carefully selecting which information they wish to extract whenever they called the server.

I defined “Closed APIs,” on the other hand, as simply spitting out data on a schedule, leaving the customer to fall over themselves poring through that output, and then delivering it to their systems. Their only hope of determining what was actually happening with the data was to look for changes from one data-dump to the next.

These definitions satisfied my needs for understanding APIs in my various work roles. My relative ignorance was relative bliss.

Since I started my bootcamp six weeks ago, I’ve discovered that the situation is, of course, more nuanced than that. As I’ve dug into CRUD and learned about RESTful routing, it’s become clear that my definition of “Open API” has many different uses and actions, some of which even involve changing data on the server itself. These capabilities can be controlled at the server side, allowing the provider to limit the flow (and potential manipulation) of data.

I learned all of this in my course’s educational text and in labs, but it all came to a head when I started working on an International Space Station (ISS) tracker for my Phase 2 group project. My group decided to build a website devoted to information on space travel, and one of the ghee-whiz ideas we had was to create a page which would show the coordinates of the ISS’s location in orbit on a map of the Earth. We knew there was a way to simply do this by embedding an existing ISS tracker on the page — there are many such trackers out there. Here’s one from the European Space Agency:

The ESA’s ISS tracker at isstracker.spaceflight.esa.int/index_portal.php

This actually would have met our project’s requirements, as it would have required a FETCH call. But I really wanted to see if I could actually build a fully-realized component from scratch, make it look the way I wanted, and have it feel really integrated into the motif of our application.

The first thing I needed was the location data itself. The ISS coordinates are readily available from multiple APIs. The one we chose was https://api.wheretheiss.at/v1/satellites/25544, as it has a simple, one-layer output that includes the latitude and longitude at the top level.

Source: api.wheretheiss.at/v1/satellites/25544

So we’re off to the races! Next thing to do was fetch this data. I threw in a few error catches to create “better” experience for the user if they encountered problems at page load. But this is otherwise a pretty standard FETCH request.

Most of my FETCH requests up to this point haven’t bothered with “if/else” or “.catch” statements, but the goal here is a polished product.

My FETCH request parses the data into JSON, then it takes that data and assigns it to datapoints representing latitude and longitude coordinates. With those in hand, I had to figure out what to do with them. With the goal of visualizing this data on a map, an obvious solution seemed to be using Google Maps.

I knew Google Maps has their own API allowing one to relatively easily integrate maps in applications. You just need to create a project on the Google Cloud platform, and then request an API key. (The steps to do this can be found in Google’s robust documentation here.)

Once I’d received my API key, I knew I didn’t want to be throwing it around willy-nilly in my code, so I assigned it to a variable in the project’s secret.js file, and then noted that folder in our .gitignore file:

We also have a key for NASA’s API, but shhhhh they’re secrets!

Next up was importing GoogleMap, Marker, and LoadScript React functionality into my component:

And then incorporate those elements into my return:

I had to create a function for onLoad to use state to ensure my map appeared at page load

With all of this in place (and some other functions you see referenced in my code), I had a map appearing on the page. Hooray!

Yippee!

But there were a couple problems. First being: while the map showed at page load, any time I clicked away to another page and then clicked back, it had disappeared, and would only reappear when I’d use my browser’s reload button:

There’s that helpful “Loading…” message I left for users when there’s nothing to show yet

After some research, I discovered that in order to fix this, I needed to actually import and use LoadScriptNext instead of LoadScript from Google’s React API tools. I adjusted my import statement accordingly, and updated my JSX elements to use LoadScriptNext instead, and this solved the loading problem no matter how many times I clicked away:

My next problem was that while the map appeared (and updated) centering on the correct location, there was no marker identifying the ISS on the map:

Where is she?

After a considerable amount of, well, Googling, I discovered that for numerous reasons, recent React releases required one to use “MarkerF” instead of “Marker.” And so I obliged:

And the marker appeared!

There she is!

Mission accomplished! Well, nearly accomplished. Because remember, I wanted something that looked slick and fully integrated into our project, with a custom icon representing the ISS on the map. Fortunately, this was as simple as adding a .png image of an ISS icon to our project’s public folder and then referencing it in the element.

And, lo-and-behold, we have a little space station icon representing the ISS on the map:

TA-DAA!

There were a few other obstacles along the way… I needed to ensure that my page called the ISS location API at a long enough frequency so that I didn’t run into [429 Error]s for making too many calls. (I might have run into this at one point, forcing me to consider switching APIs). I fixed this through using effect to limit the call interval to every 20 seconds, well within the API’s once-per-second limit.

whoops

And I had to make sure that limit function was placed in the correct place outside of the FETCH request (and writing the code while I didn’t have the page constantly loading in the browser) to ensure I didn’t pretty much immediately start getting FETCH denials.

But all in all, I went from having relatively little idea of what to do, to having a finished product that I was pretty damn happy with in about four hours. And I had the basic functionality (that is the map appearing and centering) in less than three hours. If you read my previous blog post from three weeks ago, where I go on about my confusion while wrapping my head around the concept of seemingly-undeclared variables, I’m pretty astounded that I’m talking about this today.

And now, onto the next thing!