frontend-ij--web-app v1.660.2

InfoJobs Web App Monorepo

This project is a monorepo including the React Web App for Infojobs.net and Infojobs.it, plus some shared dependencies.

• Server Logs
• Client Errors Logs

Table of contents

• InfoJobs Web App Monorepo
  • Table of contents
  • Getting started
    • Install global and local dependencies
    • Login to internal NPM registry
    • Enter the project
    • Install dependencies
      • In depth package-lock
  • Packages
    • Components
      • Create a new component
      • Launch component playground
      • Run component tests
    • Domain
      • Create use cases
      • Run domain tests
    • Literals
    • Web App
      • Launch the development environment
      • Choose portal (net/it)
      • Enable Ads for developement
      • Run e2e tests
      • Mock endpoint response
  • Deploy
    • Release links
    • Automatic installation
    • Manual installation directly to PROD
    • Hotfix installation
    • Installation in Sandbox (SBX) environment
    • Installation in Manual PRE Installation
      • Deploy a Pre/Pro image to Manual Environment
      • Deploy a specific PR to a manual environment
      • Set up proxy for manual env
    • Dashboards
  • Troubleshooting
  • Performance
    • Web Vitals and Core Web Vitals
    • How are metrics measured?
      • PageSpeed Insights
        • PageSpeed Insights Website
        • PageSpeed Insights Datadog Integration
        • How it works?
    • Search Console's Core Web Vitals report

Getting started

A few things you have to take into consideration before running the project and work on a package.

After cloning the repo you'll have to:

Install global and local dependencies

Verify to use the minimum required versions of Node and NPM or download them from the following link:

• Node version >= v18

❕ Node v18 automatically installs the current minor version of NPM 9

❕ You can verify your current default version by typing in your terminal the following commands:

node -v
/* 18.17.0 */

npm -v
/* 9.6.7 */

Login to internal NPM registry

In order to install the internal dependencies we develop at Adevinta, ask your referent to provide you with the NPM registry credentials, then open a terminal tab and login to our internal registry:

npm login
/* Username: */
/* Password: */
/* Email: (this IS public): */

Enter the project

Enter the root folder of the project in a new terminal window and install the npm dependencies:

cd frontend-ij--web-app

Install dependencies

Before all, be sure has activated generate package.lock on install:

npm config set package-lock true

Once you have this prepared, it is time to install the project dependencies:

npm run deps:install

Also, there are several scripts that you can run to manage dependencies:

• npm run deps:install: Just install the dependencies. It could update patches versions of packages.
• npm run deps:updatelock: It will update package-lock.json with latest versions of package.json dependencies, it does not install dependencies.
• npm run deps:fixlock: It will fix package-lock.json problems, useful after merges. It does not install dependencies.
• npm run deps:ci: It will install package-lock.json dependencies

In depth package-lock

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

This file is intended to be committed into source repositories, and serves various purposes:

• Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.

• Provide a facility for users to "time-travel" to previous states of node_modules without having to commit the directory itself.

• Facilitate greater visibility of tree changes through readable source control diffs.

• Optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.

• As of npm v7, lockfiles include enough information to gain a complete picture of the package tree, reducing the need to read package.json files, and allowing for significant performance improvements.

package-lock must be committed and treated as a first-class citizens. This includes: committing it, solving merge conflicts and handling it with caution.

Packages

The project includes different packages, all of them are representing a dependency that could work in isolation and is deployed on the internal npm registry.

Components

This package works using the SUI Studio playground. It allows us to create new components for the IJ studio namespace and publish them automatically on our internal registry. For more information about how the SUI Studio works, here you can find the documentation.

Create a new component

To create a new component, use the studio:generate NPM script, it will generate a component following the same process you can find in the previously attached documentation.

npm run studio:generate <componentFolder> <componentName>

/*
* e.g
* npm run studio:generate layout candidate
*/

Launch component playground

To start working on a component and see how it changes on the playground, use the studio:dev NPM script specifying the component you want to work on, it'll automatically run the playground and you'll be able to access it on http://localhost:3000

npm run studio:dev <componentFolder>/<componentName>

/*
* e.g
* npm run studio:dev layout/candidate
*/

Run component tests

While working on the playground you will already see the test suite for the component. In case you want to check if all the components tests are still passing, you can run them all with the test:studio NPM script. It will immediately run all the tests on the terminal.

npm run test:studio

❕ In case you want to watch for file changes while running the tests, use the test:studio:watch NPM script:

npm run test:studio:watch

Domain

This package contains the Web App and Widgets business logic, organized following the clean architecture principles adapted for our frontend needs.

You can read more about it on the Adevinta Spain - Frontend Convergence document, in the Domain section (you need to access with the Okta credentials to see this page).

Create use cases

After reading how we apply clean architecture client-side at Adevinta on the Frontend Convergence document, you should now be able to create your first use case.

Since there is a lot of boilerplate, inside the domain package folder you can use a generate script that will automatically generate most of the files you'll need, check the script file inside the domain/scripts/generate.js file if you're curious about how it works.

cd ./domain
npm run generate language -N -E Language

Run domain tests

Inside the domain folder you'll be able to use all the scripts defined in the package.json file.

To run the test suites, use the test script to launch the test runner in your terminal:

cd ./domain
npm test

Literals

The literals package folder contains the Web App translations.

You can add new translations creating a new KEY (the newly defined key should be completely upper-case) and associating the text you'll later use inside the app.

In order to correctly deploy the literals with a new release, it needs to pass some tests, so be always sure to respect the following constraints when adding/editing a literal:

• It should be inserted alphabetically, don't add the key to the bottom of the file but search for its right spot between the other literals.

• Should be present in both es and it files. In case you don't dispose of a translation, just add it as an empty string.

Web App

The Web App represent the website used by job candidates.

Most of the app source code is inside the src folder.

Launch the development environment

In order to work with the app in different environments, into the package.json there are some NPM scripts useful to start the development environment in different ways:

• dev: Run the app in development and client-side only mode. It allows using the mock server and test functionalities quickly since it uses HMR to refresh the content as soon as the code is saved.

• ssr:dev: Run the app in development and server-side mode. It is useful to verify that the app works correctly while doing SSR and rendering sensible details for SEO purposes, etc..., but since it gets built the development cycle is slower because is necessary to restart the script every time a change is applied.

• ssr:local: Run the app as the ssr:dev script does but in a local (local) environment. This is the right script to use when working on a feature on the Monolith Web App that needs to interact with this project.

• ssr:sbx: Run the app as the ssr:dev script does, but in sandbox (sbx) enviroment.

• ssr:pre: Run the app as the ssr:dev script does, but in pre-production (pre) enviroment.

• ssr:pro: Run the app as the ssr:dev script does, but in production (pro) enviroment.

Choose portal (net/it)

While working in development mode (dev, ssr:dev) it is possible to specify if the Web App should be launched in the Spanish or Italian version of the platform.

By default, the Web App starts with the Spanish version, to switch it to the Italian portal use the previously explained scripts setting the PORTALenv variable:

PORTAL=it npm run dev

Enable Ads for developement

The easiest way to enable the Ads on a page and correctly render content inside the Roadblock banners is adding the ast_test=true query parameter.

Adding this query parameter to the url of the page under developement, you be able to load content inside the placed banners (TopBanner, SideBanner, etc...) and verify their rendered following the respective sizes.

Render a page WITHOUT ads content
http://localhost:3000/candidate/cv/view/index.xhtml

Render a page WITH ads content
http://localhost:3000/candidate/cv/view/index.xhtml?ast_test=true

Run e2e tests

In order to locally run the e2e tests created using Cypress, it is just simple as using the NPM script test:e2e:dev:

npm run test:e2e:dev

This will immediately download the necessary Cypress dependencies (if missing) and initialize the Cypress playground.

There is a similar NPM script defined (test:e2e:ci) that is used during the CI process to assert the same tests.

Mock endpoint response

Deploy

Here you can find some useful instructions on how to deploy the Web App

Release links

https://artifactory.mpi-internal.com/artifactory/webapp/#/artifacts/browse/tree/General/docker-local/scmspain/frontend-ij--web-app

Automatic installation

When a PR is merged from a branch to master then a jenkins job will run automatically.

This job executes acceptance tests and if they finish successfully then you should launch manually the deploy in prod. This step is in the same jenkins job and its named "Promote to prod" (you need to be logged in):

https://jenkins.dev.infojobs.net/view/AWS%20PROD/view/REACT/job/frontend-ij--web-app-pipeline/view/tags/

Manual installation directly to PROD

When travis finish successfully then you have to launch this jobs with default values and Environment option point to "Production". This option skips acceptance tests and deploy directly in PROD.

https://jenkins.dev.infojobs.net/view/AWS%20PROD/view/REACT/job/frontend-ij--web-app/

Hotfix installation

In case you want to restore an old webapp AMI then you must launch the job for manual installations and fill in the param REACT_AMI_NAME as indicated in the job.

Installation in Sandbox (SBX) environment

Web App can be installed in SBX environment with the following Jenkins job:

https://jenkins.dev.infojobs.net/view/AWS%20PROD2/job/InstAWS_Sbx_WebApp/

This job needs two parameters:

• WEBAPP_AMI_NAME: By default, this parameter has the value ACTIVE_IN_PROD, it means that the pipeline will get the current version is running in Production environment. If you want to deploy an another version, you should write the preproduction AMI version, for instance: IJReact-201911180851-preproduction If you want to deploy a specific version of a Pull Request, you need to uncomment from .travis.yml these two stages:

- stage: build preproduction container
- stage: build AMI PR

Then a new AMI version will be created with the PR number and the commit id (for instance: IJReact-pr-744-0d97ba8). You should write this AMI version.

• VPC_LABEL: This parameter shouldn't be modified. It is related with the AWS VPC network where the Web App will be installed.

For each new installation of EMPLEO in Sandbox environment, automatically will install the ACTIVE_IN_PROD version of Web App.

Installation in Manual PRE Installation

Web App can be installed in PRE Manual environment with the following Jenkins job:

https://jenkins.dev.infojobs.net/view/Development/view/Installations%20-%20AWS%20Manual/job/EmpleoPREenvironmentInstall/

Deploy a Pre/Pro image to Manual Environment

This job has been adapted in order to deploy Webapp version using the parameter WEBAPP_VERSION, this parameter by default has the value LAST_VERSION. LAST_VERSION value means that Jenkins will deploy the WEBAPP PREPRODUCTION version of the version installed in PRODUCTION. If you want to install another version, you should fill the parameter as following example: IJReact-201912121635-preproduction

Deploy a specific PR to a manual environment

In the travis.yml there are two commented septs(L42 to L58). In order to be able to deploy a particular PR in a manual environment the PR has to have this code uncommented at least once to deploy the docker image to the artifactory. Steps to follow: Code on a branch Uncomment the steps on the travis.yml file Push and create a PR Wait until travis is done Go to the Jenkins Job and start the build process with the right parameters (WEBAPP-VERSION IJReact-PR-xxx-xxxx) Comments those steps and push again (have in mind that once you comment thos spets there will be no new image published on artifactory for those commits).

Set up proxy for manual env

You need to have one extension on your browser that allows you to set a proxy. What we are gonna do its to map the request to the manual env DNS Steps: Go to the console output of the jenkins job for the manual deploy Search for "Squid DNS" and you will find the DNS for the manual env and the port (3128) *Set up your proxy to map "www.infojobsqaaws.net" to the DNS and port

Dashboards

• Client and Server JS errors:
  • PRO Kibana
  • PRE/DEV Kibana dev deactivated by default, in order to activate it, devMode must be set to true here

Services accessible from Candidate´s webapp

In the following image, we can see the accessible services/endpoints of the candidates' web application:

• Monolith endpoints with cookie-based authentication, starting with infojobs.net/webapp/*
• KrakenD for candidates, which allows access to all defined microservices.

Troubleshooting

Sometimes is possible that the Web App won't correcly run, maybe due to a cached dependencies or a failure looking for another one.

In these cases, try to follow this process to restart with a fresh version of the codebase:

1. Checkout the master branch and pull the latest code:

   git checkout master
   git pull

2. Clean and re-install all the existing dependencies modules and dependencies tree:

   npm run deps:install

   This script takes care of removing the node_modules folder and package-lock.json file, then install the dependencies again from scratch.

In case this approach is not working, contact one the app maintainers to get support.

Performance

Objective: Measure the performance of a web page.

Web Vitals and Core Web Vitals

Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.

Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.

Each of the Core Web Vitals represents a distinct facet of the user experience, is measurable in the field, and reflects the real-world experience of a critical user-centric outcome.

The metrics that make up Core Web Vitals will evolve over time. The current set for 2020 focuses on three aspects of the user experience—loading, interactivity, and visual stability—and includes the following metrics (and their respective thresholds):

• Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.
• First Input Delay (FID): measures interactivity. To provide a good user experience, pages should have a FID of 100 milliseconds or less.
• Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, pages should maintain a CLS of 0.1. or less.

How are metrics measured?

Performance metrics are generally measured in one of two ways:

• In the lab: using tools to simulate a page load in a consistent, controlled environment
• In the field: on real users actually loading and interacting with the page

There is plenty of ways to do this, but we are currently using two main ways: PageSpeed Insights API and Search Console's Core Web Vitals report. Both are metrics based on real users, so they are in the field category.

Read more: User-centric performance metrics

PageSpeed Insights

English version: https://developers.google.com/speed/docs/insights/v5/about#differences

• In the field or in the lab, depending on Google page data.

Real-user experience data in PSI is powered by the Chrome User Experience Report (CrUX) dataset. PSI reports real users' First Contentful Paint (FCP), First Input Delay (FID), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS) experiences over the previous 28-day collection period. PSI also reports experiences for experimental metrics Interaction to Next Paint (INP) and Time to First Byte (TTFB).

In order to show user experience data for a given page, there must be sufficient data for it to be included in the CrUX dataset. A page might not have sufficient data if it has been recently published or has too few samples from real users. When this happens, PSI will fall back to origin-level granularity, which encompasses all user experiences on all pages of the website. Sometimes the origin may also have insufficient data, in which case PSI will be unable to show any real-user experience data.

PageSpeed Insights Website

• Get the results directly from the PageSpeed website

• For example: https://pagespeed.web.dev/report?url=https%3A%2F%2Fwww.infojobs.net%2Fjobsearch%2Fsearch-results%2Flist.xhtml&form_factor=desktop

PageSpeed Insights Datadog Integration

How it works?

• There is one repository that defined the pages and the strategy (mobile or desktop) that we want to measure.
  • It uses PageSpeed Insights API to get data.
  • It sends the data to Datadog.
• Datadog Dashboards with Synthetic Lighthouse Metrics in mobile:
  • Home Score
  • Listing Score
  • Detail Score

Search Console's Core Web Vitals report

• It is available inside Search Console