Exposing Trail Data with FastAPI

Having built out a data pipeline that processes hiking trail data from National Parks I’ve visited, I wanted to expose some of the results as an API.

I chose the FastAPI framework for its beginner-friendly reputation and OpenAPI specification. I’m also already using Pydantic to validate some of the data collection so it seemed like a natural choice.

I plan to develop the API further, but even going through the process to create two endpoints (with Claude’s help) was a valuable learning process.

I was able to implement different types of parameters (path parameters like {park_code} and query parameters like min_length) and validate them at the API boundary.
I defined the “contract” between the API and clients in models.py using Pydantic.
I learned how to separate concerns between the HTTP layer (main.py), the data layer (queries.py), the infrastructure layer (database.py), and the data validation (models.py).
I was able to keep settings centralized in the existing Config class.
Although I don’t work on API documentation, it was interesting to explore how the API documentation gets generated into Swagger or Redocly UI from an OpenAPI spec.
Claude did the heavy lifting on testing the API, writing many unit tests.
For the trails endpoint, I stuck with normalized database tables and CTEs for a hairy SQL query and dynamic filters compared to storing the data in the prepared format.

I look forward to refining this work and making more endpoints available as I add new features!