Skip to content

Latest commit

 

History

History
41 lines (24 loc) · 2.69 KB

README.md

File metadata and controls

41 lines (24 loc) · 2.69 KB
Raw

Build Status codecov js-standard-style

Oregon Humane Society API

A GraphQL API for data about animals sheltered at the Oregon Humane Society.

Running

For now it's impossible to run this project locally (you would need the Firebase credentials to access any data). I am currently transitioning to Neo4j (a native graph database management solution), at which point it will be much easier to provision access/provide test scripts without needing a Firebase account.

Roadmap

See issues for an idea of current progress and features.

FAQ

  1. Where do you get the data?

I scrape the Oregon Human Society's website using this thing I wrote.

  1. Won't they be mad?

Nah, they'll be fine. For now my scrape has a very low impact on their page hits. I currently only scrape occasionally for test data.

  1. Cool tests broh!

This project has convinced me that for API development a small number of representative integration tests are more informative, more maintainable, and generally more helpful than a huge pile of discrete unit tests. Happy to hear the other side.

  1. Why Babel?

There are three proposed features I want access to:

  1. The async/await keywords
  2. SystemJS modules (the import/export keywords)
  3. The object spread syntax (or "object splat"). With GraphQL in particular the splat is super useful.

I could do without the first two but not the last. As long as I have to compile for object splat anyway, the other two are fun and handy.

  1. Why GraphQL?

REST API's suffer whenever you need access to arbitrary pieces of data that bear arbitrary relationships. My experience has been that this is hugely common in web development. I don't want to make a request for users, see what comes back, and then make a different request to a different endpoint for each user's blog posts.

That's very frustrating. It's also very expensive and slow. GraphQL makes it possible to define the relationships between entitities (like users and blog posts) at the API layer. This allows clients to only ask for what they need without requiring they understand the inner workings of the API. This is easier to understand and write, in many cases more performant, and by far more maintainable thanks to better separation of concerns.