Tonight, I thought it'd be fun to detail out a choice I made while building lily dex that I had very little confidence in, but has been serving me well thus far.

The Problem

Early iterations of lily dex included the full list of Pokémon in the app code, therefore requiring an app update every single time a new Pokémon was added to Pokémon Go. I'd have to open Xcode, update the app, push the update, wait for Apple's approval... and then players would have to manually update or wait for the automatic update to get the change.

Every. Single. Time.

This was the first thing that had to change once I decided lily dex was destined for The App Store.

At this point, I was about three months into a SwiftUI course and had very limited experience with fetching and working with data in Swift. The API I wanted to use (PoGo API) would require a ton of this - it returned data as large objects and I wanted arrays.

// PoGo API:
{
    "1": {
        "id": "1",
        "name": "Bulbasaur"
    },
    "2": {
        "id": "2",
        "name": "Ivysaur"
    },
}

// What I wanted:
[
    {
        "id": "1",
        "name": "Bulbasaur"
    },
    {
        "id": "2",
        "name": "Ivysaur"
    },
]

            

I also wanted to add additional details for each Pokémon from other PoGo API endpoints. This would require a lot of data transformation and coercion - far beyond what I'd learned during my Swift course at that point.

The Solution: An API Route

So, on one side, I had an API with a bunch of endpoints returning data I wanted to transform and merge. On the other, I had an app that needed to receive nicely-formatted data.

Could I create a passthrough endpoint that consumed the PoGo API and returned the data in the structure I wanted?

The framework my personal site is built on offers a feature called API routes, which lets you create API endpoints as a Node.js serverless functions. This seemed like a good candidate for what I was trying to accomplish - I created a new API route called released-pokemon.ts where I started making calls to the PoGo API. I then transformed nearly all the responses and returned them as an array containing all the details I wanted in my app.

As things currently stand, lily dex calls this endpoint, which calls the PoGo API. I'm not sure sending all the data through my personal site makes sense... I could set up a lambda anywhere and accomplish the same thing. I could do all this data wrangling in the app. I feel insecure about these things.

But this architecture works. I was able to set it up fast, and it gives me the flexibility to make API changes without having to muck with Xcode or App Store Connect. This has come in handy more than once!

How would you handle this? Were my concerns that led me to building this Rube Goldbergian architecture overblown? Let me know!

Published over 3 years ago