[Catalog] API and boundaries

[heitorlessa]

Boundaries

Booking is currently mutating Catalog data store directly instead of an API. This was done as a quick prototype and not fixed it later - operations like Flight Reservation, Release Seat, etc.

GraphQL API calls Catalog data store directly due to GraphQL Transformers. We need to change it to HTTP Data source and integrate with Catalog API instead.

API

Catalog needs an API, along with functions, and optionally an optimized data modelling. This has to be built from the ground up, and data modelling changes will affect booking due to GraphQL Transformer direct relationship - should be a separate issue altogether to ease documenting Decision log.

Minimal changes:

• [ ] Define a Catalog API to fetch flights, and reserve flight seat
• [ ] Update GraphQL integration to use new Catalog API
• [ ] Update Booking State Machine to use Catalog API (could be done in a separate PR once API is functional)
• [ ] Automated tests
• [ ] Linting and security benchmark (copy from Loyalty)

Optional changes depending on who's tackling the tasks:

• [ ] Front-end: Create Flight Seat map
• [ ] Support seat reservation with different tiers (free, paid, premium legroom) in the API
• [ ] Front-end: Allow customers to reserve seats depending on their Loyalty status (Silver+) or pay for it