The front-end is built atop Vue.js, and uses Vuex modules to integrate with its back-ends - See Stack details for completeness
These are the Vuex modules that manipulate the state, and integrate with each back-end hosted at AWS:
Component | Functionality | Description |
---|---|---|
Catalog | Flight search | Searches for flights given a destination and departure date. |
Booking | Bookings | Creates and lists bookings for customers. |
Loyalty | Loyalty | Fetches Loyalty points for customers including tiers, and calculates how far they are from the next tier. |
Profile | Customer profile | Provides authenticated user information to other components such as JWT tokens (user attributes, etc.). It may be extended to create an actual profile service on the back-end. |
We use component
and view
terminologies to separate what's a reusable Vue component, and what's a page that need to manipulate state within Vuex.
- FlightCard - Component to render a flight card when searching or reviewing flight results
- FlightLoader - Custom content loader used when searching for flights
- FlightToolbar - Component to filter and sort flight results
- BookingCard - Component to render modal that provides more details about a booking
- BookingFlight - Component to filter and sort flight results
Pages
map to pages customers interact with, and integrate with their respective modules to fetch and manipulate data from back-ends - See more details for each view component
We use Navigation Guards to enforce authentication for routes that contain requiresAuth
metadata.
Route | Page | Query strings |
---|---|---|
/auth | Authentication | None |
/, /search | Search | None |
/search/results | FlightResults | date, departure, arrival |
/search/results/review | FlightSelection | flightId |
/profile | Profile | None |
/profile/bookings | Bookings | None |
We use the following conventions to ease maintenance as we grow the number of modules and services:
- Actions - All interactions with back-ends regardless of its communication channel happen within each module's actions.js
- Mutation - State isn't mutated directly but through mutations functions (e.g.
SET_BOOKINGS
) and are always uppercase - GraphQL - Custom GraphQL operations have a dedicated file close to its module (e.g.
catalog/graphql.js
) - Shared Models - Data permutation such as formatting flight departure dates differently are done at a class property level e.g. (e.g.
FlightClass
) - Code documentation - We document following JSDoc convention
You can run the front-end locally while targeting the back-end and auth deployed in your AWS account.
If you followed the deployment instructions, you should have src/frontend/aws-exports.js
file.
Once you're all set, install front-end dependencies, create/update .dev.env
, and run a local copy:
npm install
- Create or update
src/frontend/.dev.env
file with Payment Charge URL and Stripe public key, for example:- PaymentChargeUrl="https://ct21smx12c.execute-api.eu-west-1.amazonaws.com/prod/charge"
- StripePublicKey="pk_test_BpxANYCOZO7waMV3TrPQHjXa"
- LOG_LEVEL="DEBUG"
npm run serve
NOTE: If you haven't browsed around the deployment stacks yet for Payment and Stripe values up there, you can get them from System Manager Parameter Store, where
AWS_BRANCH
is the branch you connected with Amplify:
aws ssm get-parameter --name /${AWS_BRANCH}/service/payment/stripe/publicKey --query 'Parameter.Value' --output text
aws ssm get-parameter --name /${AWS_BRANCH}/service/payment/api/charge/url --query 'Parameter.Value' --output text
- Open up your deployed App in Amplify Console by running
amplify console
- At the bottom of the page under Edit your backend, copy and run the
amplify pull
command- e.g.
amplify pull --appId d34s789vnlqyw4 --envName twitch
- e.g.
NOTE: Aws-exports is a configuration file for AWS Amplify library containing Cognito User Pools, AppSync API, and what authentication mechanism it should use along with its region.