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.envfile 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_BRANCHis the branch you connected with Amplify:
aws ssm get-parameter --name /${AWS_BRANCH}/service/payment/stripe/publicKey --query 'Parameter.Value' --output textaws 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 pullcommand- 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.
