Flicktionary Angular frontend - A dictionary for flicks.

The course brief defined Flicktionary as a client for an existing REST API: a movie database with endpoints for films, genres, directors and users. The client had to support:

• registration and login,
• viewing a catalog of movies,
• showing details about a movie, its genre and its director,
• managing a list of favorite movies, and
• updating or deleting a user account.

On top of that, I treated the project as a chance to practice:

• structuring an Angular app into modules and components,
• using services and RxJS to consume a REST API,
• adding server-side rendering (SSR) for performance and SEO,
• and setting up unit tests and documentation for long-term maintainability.

I considered the project successful if:

• users could log in, browse movies and manage favorites without encountering errors,
• the UI remained responsive and usable on both desktop and mobile,
• the Angular code stayed modular and easy to reason about,
• and I had an automated test baseline and documentation that could support future changes.

• Angular modules & routing:
  The app is split into feature areas (welcome/auth, movies, profile). Angular routing handles navigation between the welcome screen, movie list and user profile, with guards to protect authenticated routes.

• Data access via services:
  A central fetch-api-data service wraps HttpClient calls to the Flicktionary REST API. Methods like getAllMovies, getUser, addFavorite or deleteUser return RxJS Observables, which components subscribe to in a structured way.

• State in components:
  Movie lists, favorites and user data are held in component state, updated in response to service calls. Angular Material components (cards, dialogs, toolbar, buttons) provide the visual shell.

• SSR with Angular Universal:
  The project supports server-side rendering so initial loads are fast and pages can be indexed more easily. An Express-based server renders the Angular app on the server and proxies API calls to the backend.

• Testing & documentation:
  Unit tests are written with Jasmine & Karma, and TypeDoc is configured to generate documentation from the TypeScript source. Both are integrated into the project’s npm scripts.

Phase 1 – Understanding the API and outlining features

I started by reviewing the Flicktionary API: available endpoints for movies, genres, directors and users, required auth headers, and typical response shapes. From there, I mapped the required user flows into screens and components: welcome/auth, movie list, dialogs for details, and user profile.

Key learning: Starting from the API contract helps shape both the routing structure and the data service design.

Phase 2 – Setting up modules, routing and layout

Next, I scaffolded the Angular app with a basic module and routing setup, and introduced Angular Material for layout, cards and dialogs. I built a simple navbar, a welcome page, and a placeholder movie list to validate navigation and styling patterns early.

Key learning: Getting navigation and basic layout in place early makes it easier to plug in real data later without redesigning the UI.

Phase 3 – Implementing the data service and movie browsing

I then created a dedicated API service using HttpClient to connect to the Flicktionary backend. This service exposes methods like getAllMovies, getMovie, getUser, addFavorite and removeFavorite, returning Observables that components subscribe to.

With the service in place, I wired the movie list to real data, handling loading and error states in the UI.

Key learning: Centralizing API calls in a service keeps components lean and makes it easier to handle cross-cutting concerns like auth headers and error handling.

Phase 4 – Favorites, dialogs and profile management

After basic browsing worked, I focused on interactivity:

• a heart icon on movie cards to add/remove favorites,
• dialogs for movie, genre and director details, and
• a profile view where users can update their info or delete their account.

I paid attention to feedback: showing snackbars or clear state changes when a favorite is added/removed or when profile updates succeed.

Key learning: Small feedback mechanisms (like snackbars or visual state changes) do a lot of UX work in making an app feel responsive and trustworthy.

Phase 5 – SSR, testing and documentation

In the last phase, I set up Angular Universal for server-side rendering and ensured the app could run in SSR mode with an Express server. I also added unit tests for critical components and the API service, and configured TypeDoc to generate documentation from the TypeScript code.

Key learning: Adding SSR, tests and documentation at the end of a project is a good reminder that “done” for a front-end app is more than “it runs on my machine”.

• Automated tests:

  • Component-level tests check that core views (welcome, movie list, profile) render correctly and react to inputs as expected.
  • Service tests verify that the API service calls the correct endpoints and returns data in the expected shape.
  • Tests are run with ng test, using Karma as the test runner and Jasmine as the assertion library.

• Manual testing:
  I manually tested the main flows end-to-end in the browser:

  • registering a user, logging in and logging out,
  • browsing the movie list and opening dialogs,
  • adding and removing favorites,
  • editing the user profile, and
  • deleting the user account and confirming the behavior.

If I revisit the project, I would expand the test coverage around error handling (e.g. network failures, expired tokens) and add more focused tests for route guards and SSR-specific behavior.