Implement GET /opportunities (first draft)

[bickelj]

A first draft of an implementation of HTTP GET on /opportunities. It
includes SQL for the schema, removal of cruft, SQL for the query, types,
and the boilerplate/glue code needed to wire it to the express server.
What it still lacks is tests, passing lint, and probably node-ish-ness.

Issue #31 Implement GET /opportunities endpoint

[bickelj]

I know linting fails, but something in here is probably a simple misunderstanding due to my node/typescript noobness. Regardless, is this close to the shape of what you would expect for an implementation of this subset of the API?

[bickelj]

I see the integration tests taking more than two minutes to run as well, canceling those.

[slifty]

ALL RIGHT! Sorry it took so long to get you any feedback, I had a WIP branch that contains some of the patterns I wanted to propose which I wanted to get out there to be able to point to!

Some things I think are worth doing as part of our endpoint implementation are:

1. fixture-based tests
2. type checking of the database response (and 500 erroring with a useful error message if the type check fails)
3. Defining defaults and type guards along side types (and trusting that we can use utility types to define subsets of interfaces where needed, rather than defining a bunch of versions of the same type)

I think we probably want to avoid bigints for the reasons you recognized in another thread; it'd be one thing if it was free but I think the added complexity isn't worth it for the moment.

[slifty]

In TypeScript the way to signal this is to define Opportunity and specify optional fields where appropriate using ?.

e.g.

export interface Opportunity {
  id?: number;
  title: string;
  createdAt?: Date;
}

For situations where we only need a smaller piece of an opportunity there are a series of utility types that let us specify a contextual modifications of a given interface.

For instance if we had an API endpoint that ONLY needed a smaller subset of Opportunity fields we could use Pick<Opportunity, 'title' | 'id'> and that would require both title and id for that particular parameter.

[bickelj]

Thanks for the explanation here and in #55 (comment). It looks like I clicked the link you gave here but did not actually go through it and understand it until your other comment. I see the approach and it makes sense!

[bickelj]

Closing without merge because this was before a good pattern (and the dependent endpoint implementation) was established by @slifty in #55. Second draft was in #63 which bit off too much and assumed too much.