distributeaid / shipment-tracker

A web app and API to coordinate aid shipments around the world
https://distributeaid.org
GNU Affero General Public License v3.0
8 stars 10 forks source link

Improve API error handling #82

Closed andyjac closed 2 years ago

andyjac commented 3 years ago

1. Dig into graphql errors types and what they mean/best practices around using them

2. Deduplicate error logic

At the moment we have string literals floating around in various places for error messages. We should:

  1. Codify and unify the language we use for error messages (is is Shipment not found or Shipment does not exist?)
  2. Encapsulate these error strings in some sort of structure/class that can be reused
coderbyheart commented 3 years ago

See https://github.com/distributeaid/shipment-tracker/blob/84ea3d61a049c243eb26c027c4afdba0bdff8c90/src/resolvers/input-validation/errorsToProblemDetails.ts#L6-L40 for a way to express API errors.

IMO ApolloError schould not be used for internal error, instead EntityNotFound which then is wrapped into problem details.

In the end it depends on how the frontend would like to present errors.

coderbyheart commented 3 years ago

This has been added to the REST API: 93a304ae13807cc980ccd4c8c1eb052a51d0692e