-- 🥓🍳🥞🌲🌲🛶 --
Search for popular Ron Swanson quotes and see what other users have searched for, too!
Try this app out on Heroku at https://swanson-leaderboard.herokuapp.com/.
🕵️ Check out our OpenAPI docs for interactive examples of the available API.
Here's a short summary of available endpoints:
GET /searches
-- Returns a list of saved searches & associated results.
May be `filter`ed by query or `sort`ed alternatively using querystring params.
Ex: /searches?filter=bacon&sort=desc
POST /searches
-- Creates a new search or returns an existing search based on the given `query` value.
Requires a body like `{"query": "your-query-string-here"}`.
GET /searches/:id
-- Returns a specific search & associated result by its numeric ID.
We recommend Postman for exploring the API.
This app is built on Ruby 2.7.2 & Rails 6.1.3.2 and stores data in Postgres 13.
It's a thin wrapper around the Ron Swanson Quotes API.
To set it up locally, you'll need PostgreSQL installed & running.
We've included a Docker file to help you get going fast, if needed!
Commands to kick things off:
# Only needed if using Docker for PostgreSQL
docker compose up -d
bundle install
rails db:setup
rails serverAutomated tests are built using Minitest, the Rails default. To run the entire suite:
rails test
🧶 Tight integration with Postgres
This app is built to use the ARRAY data type and includes the ILIKE SQL operator, both of
which have limited support outside of Postgres. It might be nice to replace these with an alternative implementation
that could make the API database-agnostic.
🔓 No auth*tion
That's right: this is an entirely open API at the moment. This poses a slew of problems, including the risk of serious abuse. At its simplest, a protective layer may involve a quick hash provisioned for users by email & required in the query params. Going further, a proper auth system likely involves OAuth + third party authentication, abuse & spam reporting, and maybe a tiered subscription plan for folks with heavy query needs? The sky's the limit!
🎈 Size concerns
We're not restricting query behavior here, which opens us up to attacks via massive payloads, high request rates, or both! This will quickly max out our database limitations and could put our source API at risk as well. Since this is a silly hobby project, we're relying on Heroku to shut down if overloaded. In a production environment with data that matters, we'd want to consider rate limiting, tighter database constraints, and more thorough validations on our controller endpoints.