0.2.108 • Published 11 months ago

casino777-frontend v0.2.108

Weekly downloads
-
License
-
Repository
-
Last release
11 months ago

Casino777.be

Welcome to the main repository for the casino777.be website. This repository contains the source code, documentation, and other resources related to the website.

Purpose of the project

The casino777.be website is an online casino platform that allows users to play a wide range of casino games, including slots, table games, and live casino games. The website is designed to be user-friendly, fast, responsive, and secure.

Status Badges

Coverage:lines: 44.88%Coverage:linesCoverage:lines44.88%44.88%

Coverage:branches: 36.91%Coverage:branchesCoverage:branches36.91%36.91%

Tech Stack

The website uses a combination of technologie, including : | Technology | Description | Documentation | | ----------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | TypeScript | Typescript, typed superset of JavaScript that adds static type checking and other features to the language. | Link to documentation | | React | (v18) React a popular front-end JavaScript library for building user interfaces. | Link to documentation | | Next JS | (v13) Next JS a framework for building server-side rendered React applications. | Link to documentation | | TailwindCSS | TailwindCSS - a utility-first CSS framework for quickly styling web applications. | Link to documentation | | Jest | Jest - a popular Javascript testing framework | Link to documentation | | Testing-Library | Testing Library - a set of utilities for testing React components and applications. | Link to documentation | | cypress | Cypress framework is a JavaScript-based end-to-end testing framework | Link to documentation | | Workbox | Workbox - a set of libraries and Node.js modules that make it easy to cache assets and take full advantage of features used to build Progressive Web Apps. | Link to documentation | | Storybook | Storybook - a development environment for UI components. | Link to documentation |

Development/Utility Tools

Apart from the above mentioned technologies, the project also utilizes several development tools to ensure high code quality and consistency throughout the project.

  • Husky: A pre-commit hook that ensures code quality by running automated tests and linting before any code is committed. This helps catch potential errors and maintain code consistency.
  • Commitizen: A tool used to standardize commit messages, ensuring they follow a consistent format. This makes it easier to generate automatic changelogs and follow semantic versioning.
  • Commitlint: A tool used to enforce commit message conventions. This ensures that all commits follow a specific format, making it easier to track changes and maintain code quality.
  • Standard-version: This is a utility for versioning using semver and for changelog generation. Standard-version automatically determines the next semantic version (patch, minor, major) based on the commit messages since the previous release. It also generates/update the CHANGELOG.md file based on these commits. The commit messages need to follow the Conventional Commits specification, which makes versioning and changelog generation predictable and easy to maintain. This aligns well with tools like Commitizen and Commitlint to ensure a smooth and standardized development process.
  • Storybook: Storybook is a powerful development environment for UI components that helps build, test, and document UI components in isolation from the main codebase. Its use will enable faster development iterations and easier collaboration between developers, designers, and product managers.
  • ESLint: A tool that analyzes code to identify and report patterns that are either incorrect or could lead to issues. We use ESLint with the Airbnb configuration as a base, which also includes the Next.js Core Web Vitals plugin, and Prettier for formatting code.
  • Plop: A utility that allows for the quick and consistent creation of files and components based on predefined templates, or "stubs". Plop is used to speed up the development process by reducing the time and effort required to create new files and components, while also maintaining consistency in the project's structure and organization.

Editor

We recommend using Visual Studio Code as the primary editor for this project. However, feel free to use whatever editor you're most comfortable with. If you choose to use Visual Studio Code, we've provided a list of recommended extensions that will enhance your development experience. These extensions will be automatically suggested for VSCode users upon opening the project.

Recommended extensions

  • dbaeumer.vscode-eslint: Integrates ESLint into VS Code for linting JavaScript and TypeScript code.
  • esbenp.prettier-vscode: Code formatter using Prettier, a popular code formatting tool.
  • mikestead.dotenv: Syntax highlighting for .env files.
  • csstools.postcss: Syntax highlighting for PostCSS.
  • bradlc.vscode-tailwindcss: IntelliSense and linting for Tailwind CSS.
  • Orta.vscode-jest: Provides code navigation and test running support for Jest.
  • dsznajder.es7-react-js-snippets: Adds useful code snippets for React development.
  • steoates.autoimport: Automatically finds and imports the modules you need.
  • wix.vscode-import-cost: Shows the size of each imported package in your code.
  • jawandarajbir.react-vscode-extension-pack: A collection of extensions to enhance your React - development experience.
  • bourhaouta.tailwindshades: Quickly generate Tailwind CSS color shades.
  • Gruntfuggly.todo-tree: A todo list manager that can be used to display and manage todo comments in your code.
  • eamodio.gitlens: Adds Git capabilities to VS Code.
  • shd101wyy.markdown-preview-enhanced: Enhances the VS Code built-in Markdown preview with features such as math typesetting, flowchart, and sequence diagrams.
  • unifiedjs.vscode-mdx: Adds syntax highlighting for MDX files.

Project Structure

Here's an overview of the projects' structure:

.
├── __mocks__                       # Mocks for testing
├── .github                         # GitHub/Gitlab folder - CI/CD Workflow yml files
├── .husky                          # Husky configuration
├── .vscode                         # VSCode configuration
├── artifacts                       # Miscellaneous artifacts
├── .next                           # Next JS build folder (auto-generated)
├── .swc                            # Next JS complier folder (auto-generated)
├── .storybook                      # Storybook configurations/files
├── coverage                        # Jest test coverage report for the project (auto-generated)
├── node_modules                    # The node_modules folder (3rd party packages) (auto-generated)
├── bin                             # Folder with our custom bash scripts
├── cli                             # Folder with our custom node/build scripts
├── storage                         # Folder with generated files (not committed to git)
├── storybook-static                # Storybook build folder (auto-generated)
├── cypress                         # Cypress e2e tests & configurations
├── stubs                           # HandleBars templating files, used by file generation commands
├── public                          # Public assets folder
├── scripts                         # Standalone scripts
├── src
│   ├── components                  # React Components (see structure for each component below)
        ├── [componentName]         # Folder with the components' name
            ├── Stories             # Folder containing the components' stories
              ├── [componentName].stories.ts # The components' storybook story file
            ├── __tests__           # Folder containing the components' unit tests
              ├── [componentName].tsx # The components' unit test
            ├── index.ts            # The barrel-export of the component
            ├── [componentName].tsx # The export default of the component
│   ├── features/sections           # Feats/Sections folder for specific not-reusable or a combination components - e.g Registration Form
|   ├── lib                         # If we ever use 3rd party libraries, it will be from this folder, so that our code does not depend directly on the libraries implementation but on our wrapper
│   ├── pages                       # Next JS Pages
│   ├── pages.test                  # Next JS Pages tests (this avoids tests to be treated as a Next.js pages)
│   ├── interfaces                  # Interfaces/Types
│   ├── configs                     # Configuration files
│   ├── styles                      # Styles folder
│   ├── stories                     # Storybook Page Stories
│   ├── middleware                  # Next JS Middleware
│   ├── utils                       # Utility functions
│   └── middleware.ts               # Next JS Middleware function
├── .gitignore                      # Specifies paths that are excluded from GIT
├── .eslintignore                   # Specifies paths that are excluded from ESlint checks
├── .eslintrc                       # ESLint  configuration
├── .env.example                    # Example of the environment variables that need to be filled
├── README.md                       # README file
├── CHANGELOG.md                    # Changelog from releases (Autogenerated)
├── commitlint.config.js            # CommitLint configuration
├── cypress.config.js               # Cypress configuration
├── lint-staged.config.js           # Lint Staged Configuration
├── next-sitemap.config.js          # Base config for next-sitemap generation
├── next-seo-config.ts              # Default config for next-seo
├── next-env.d.ts                   # Next Type Definitions
├── reset.d.ts                      # Reset Type Definitions
├── next.config.js                  # Next JS configuration
├── postcss.config.js               # Post CSS configuration
├── jest.config.js                  # Jest configuration
├── jest.setup.js                   # Common entry point for test, this is called after jest is initialized
├── package.json                    # Package JSON
├── package-lock.json               # Package JSON Lock File
├── plopfile.js                     # Plop configuration & action definition
├── tailwind.config.js              # Tailwind CSS configuration
└── tsconfig.json                   # TypeScript configuration

Useful Links

Environments

The below table refers to the environments used by the application when is run in different places

PlaceBack-EndURL
localdevhttp://localhost:3000/
developmentdevhttps://beta-dev.casino777.be/
pre-productionprodhttps://beta-pre-prod.casino777.be/
productionprodhttps://beta.casino777.be/

Prerequisites

DependencyVersion
Node>= 14 < 17v16.14.2
Git>= 2.22.34.1
NPM>= 88.5.0

Apart from the technical prerequisites, you will need also to be connected to the company's VPN, otherwise you will not be able to run the app.

You'll also need to configure your .npmrc file. For this you will need to have access to the company's internal npm registry. If you don't have access, please contact your team lead.

Getting Started

Simply clone the project repository, navigate to the projects' root and run the following commands :

npm install

If this is the first time you're running the project, run the following command to initialize the git hooks.

npm run prepare

Last step is to create a .env.local file and populate all the variables specified in the .env.example.

To run the application in dev mode - run :

npm run dev

If you'd like to run a production version of the application - run :

npm run build & npm run start

The application should be accessible at http://localhost:3000

Commands

CommandDescription
devStarts a development server using Next.js.
buildCompiles the application for production.
build:standaloneCompiles the application for production in standalone mode and copies the public and static folder s in the correct location
startStarts the application in production mode.
analyzeAnalyzes the application's bundle size using webpack-bundle-analyzer.
exportExports the application as static HTML files.
cleanRemoves the .next and out directories.
lintRuns the Next.js linter.
formatFormats the code using Next.js linter and prettier.
check:typesChecks TypeScript types in the project and in the cypress directory.
testRuns the test suite using Jest.
test:ciRuns the test suite using Jest when in CI (using different reporter).
commitRuns Commitizen, an interactive prompt for generating commit messages.
commit:retryRe-Runs the latest failed commitizen prompt.
cypressOpens the Cypress Test Runner.
cypress:headlessRuns the Cypress tests in headless mode.
cypress:ciRuns the Cypress tests in headless ci (without Xvfb dependency) mode.
e2eStarts the development server, runs the Cypress tests, and shuts down the server.
e2e:headlessSame as above, but runs the Cypress tests in headless mode.
prepareInstalls Husky Git hooks.
postbuildGenerates a sitemap after building the application.
create:componentGenerates a new React component using Plop.
create:popupGenerates a new Popup component using Plop.
create:middlewareGenerates a new Middleware function using Plop.
create:iconGenerates a new Icon component using Plop.
create:api-routeGenerates a new Api Route using Plop.
test:coverageRuns the test suite and generates a coverage report.
test:badgesRuns the test suite and generates coverage badges using jest-coverage-badges.
update:coverage:badgesUpdates the coverage badges using a custom TypeScript script.
check:environmentChecks the for missing .env & tries to create one (mainly for CI/CD) usage
run:scriptRuns a typescript file with node
cronsRuns all crons, you can pass filter to run specific crons e.g npm run crons -- --filter=getGames which will only execute the getGames cron
storybookRuns Storybook in dev mode
build:storybookBuilds Storybook in production mode (static)
docker:start:devStarts the application in development mode using docker
docker:start:prodStarts the application in production mode using docker
docker:stop:devStops the application in development mode using docker
docker:stop:prodStops the application in production mode using docker
docker:build:devBuilds the application in development mode using docker
docker:build:dev:forceBuilds the application in development mode using docker without using any cache
docker:build:prodBuilds the application in production mode using docker
docker:build:prod:forceBuilds the application in production mode using docker without using any cache
releaseInvokes the standard-version cli
release:minorInvokes the standard-version cli and creates a minor release tag
release:patchInvokes the standard-version cli and creates a patch release tag
release:majorInvokes the standard-version cli and creates a major release tag

Environment Variables

Note : Environment variables that are prefixed with NEXT_PUBLIC_ are exposed to the client-side.

ENV VariableDescriptionClient Side Accessible
NEXT_PUBLIC_HOST_URLDescribes the base url of the website. e.g https://www.casino777.beYes
NEXT_PUBLIC_ENVSpecifies the environment - "development" | "pre-production" | "production"Yes
NEXT_PUBLIC_CASHIER_URLDescribes the base url of cashier. e.g https://cashier.casino777.beYes
SKIP_BUILD_STATIC_GENERATIONDetermines whether to build pages or skip and do it request timeNo
PROJECT_ROOT_PATHDefines the project root - full path required, this is because we need to avoid webpack issue when compiling it with import.meta.url. If none is provided it will work with import.meta.url, so during dev its not required to specify thisNo
SECRET_COOKIE_SALT_PASSWORDSecret 32 characters long, used as salt when encrypting our user cookie.No
NEXT_PUBLIC_FULLSTORY_ORG_IDFullStory Organisation ID.Yes
NEXT_PUBLIC_FULLSTORY_COOKIE_DOMAINFullStory Cookie Domain.Yes
NEXT_PUBLIC_WS_URLThe WS Base Url to our Node Js server & emitterYes
NEXT_PUBLIC_WS_PORTThe WS Port for our Node Js server & emitterYes
NEXT_PUBLIC_TRUSTPILOT_TEMPLATE_IDTrust pilot Template ID.Yes
NEXT_PUBLIC_TRUSTPILOT_BUSINESS_UNIT_IDTrust pilot business ID.Yes
NEXT_PUBLIC_GIFT_SHOP_URLThe url for the iframe of the pass online gift shop.Yes
NEXT_PUBLIC_RECAPTCHA_SITE_KEYGoogle Recaptcha v3 site keyYes
NEXT_PUBLIC_GOOGLE_TAG_MANAGER_IDThe Google Tag Manager ID.Yes
ZENDESK_JWT_API_IDThe JWT ID aka "KID" from Zendesk messaging (web sdk only)No
ZENDESK_JWT_API_KEYThe JWT Secret from Zendesk messaging panel (web sdk only)No
NEXT_PUBLIC_ZENDESK_SCRIPT_KEYThe Zendesk asset key identifying the loading scriptYes
PREFETCHER_TOKENToken passed to access the api prefetcher endpoint.No
REVALIDATE_TOKENToken passed to access the api revalidation functionality and cron executionNo
TRANSLATION_TOKENToken passed to access the api translations json creator for native appNo
MS_*_URLSpecifies the PHP microservice endpoint urlNo
MS_*_PUBLIC_KEYSpecifies the PHP microservice public keyNo
MS_*_PRIVATE_KEYSpecifies the PHP microservice private keyNo
ITSME_CLIENT_IDThe client id of ItsMe provider providerNo
ITSME_SERVICEThe scope.service of ItsMe {LANG} should be replaced with the locale keyNo
ITSME_SERVICE_LOGINThe scope.service of ItsMe {LANG} should be replaced with the locale key. This service is for loginNo
ITSME_DOMAINThe domain of ItsMe provider keyNo
ITSME_PUBLIC_KEYOur public key used for ItsMe keyNo
ITSME_PRIVATE_KEYOur private key used for ItsMe keyNo

Workbox Caching Strategies

Using Google's Workbox, our application leverages various caching strategies to optimize performance and user experience. Here's a breakdown of the strategies employed:

1. Cache First (CacheFirst)

A strategy where the request is always served from the cache if available, and only fetched from the network if not. Useful for assets that don't change often.

  • Assets: Google Fonts, Audio files (like mp3, wav, ogg), Specific video assets from /assets/videos/loyalty/, and other mp4 videos.

2. Stale While Revalidate (StaleWhileRevalidate)

This strategy serves the asset from the cache, if available, and then fetches a fresh copy from the network in the background to update the cache. It's suitable for resources that update frequently.

  • Assets: Google Font Stylesheets, Font files (like eot, ttf, woff, etc.), Images (like jpg, png, svg), NextJS Image components, JavaScript files, CSS/LESS files, Next.js data JSONs.

3. Network First (NetworkFirst)

The asset is fetched from the network first. If the network request fails, then the asset is served from the cache. It's apt for assets that update often and need fresh data.

  • Assets: JSON, XML, CSV files, Certain API routes, Other routes excluding specific API routes, and cross-origin requests.

Note:

  • Some of these Network First routes have a fallback mechanism that uses cache if the network doesn't respond within a specified time (like 10 seconds for APIs).
  • We're excluding caching for routes starting with /api/auth/ to ensure seamless OAuth workflows, especially in Safari.
  • Certain routes check for the x-non-cacheable-response header and skip caching if found. This is automatically managed when using our in-house fetcher with the cacheable option set to false.
  • For audio and video assets, rangeRequests is enabled to ensure they can be served efficiently from a cache.

For a deeper dive into how these caching strategies work and when to use each one, please refer to the official Workbox documentation.

Workflows / Pipelines

The main workflow script and logic are described within the .gitlab/workflows/*-ci.yml files. The main .gitlab-ci.yml extends the different stages and add environment specific values and scripts.

The .gitlab folder also contains merge request templates and other stubs that we may add in the future.

Scripts

We are using custom bash scripts which are stored in the bin folder. They are vital and meant to be used in CI/CD jobs. An example of such script is the setup-env.sh, which will read the exported CI/CD variable and create the correct .env file that is needed by the project.

Before Script *

The before script is a special job that executes before every job. In our case we're making sure that important .gitignored files like the .env are created and present before the jobs proceeds. We are using cache for node modules to keep them accessible in the context of different jobs and artifacts to pass down important dependencies like generated files in storage from crons in subsequent jobs.

Stages

Current we are defining the following stages when a pipeline is triggered. Please note that in order for the pipeline to proceed the previous job and its dependencies must be met. E.g if we fail on first stage we will not proceed to the next one.

  • bootstrap
Install DependenciesRun Data CronsVerify Environment Vars
This phase runs npm ci to install all project dependencies and caches them so that the y are available for other jobsThe data cron jobs runs important scripts for the website, that are stored within the storage folder. (aliases, games, etc.)The verify environment script is making sure that all variables specified in the .env.example files are defined and present within the CI/CD context from the CI/CD variables section in Gitlab settings.
  • lint
Check TypesCheck/Apply FormatESLint Checks
This job runs our typescript checks and catches any TS issues as defined on our tsconfigThis uses our tsconfig, eslint and prettier config to format the code according to the projects code standardsThis jobs ensures that all of our ESLint rules are met, there are no unused variables, imports etc.
  • test
Unit TestsEnd-2-End Tests
We are running the projects test suite, to ensure no broken code gets shipped to productionThis job will run our e2e tests using cypress headless browsers that simulates the user and verifies common scenarios that the website functions properly
  • build
Build Application
At this stage all of our checks have passed and we are running a production built on next js and create the compiled deployment artifact that will be deployed
  • bundle-analysis
Bundle Analysis
This stage is only applicable when creating a new pull request to main. It will compare mains baseline bundle size with the bundle including the purposed changes and post a comment with the differences in client side bundle size.
  • deploy
Deploy
This stage uses the compiled ready-to-go version created by the build step and will rsync it to the server. For all environments (pre-production and development) this stage is automatic, while on production it requires a manual trigger (press of a button) to deploy it
  • release
Release
This is optional job and runs when new git tags are created. The git tags push will also include a generated Changelog.md file with the release changes thanks to the use of our conventional commit messages. The job itself will create a new release with the latest git tag, which will also update our badges. This is an easy way to keep track of the current version of code that is running on production.

Pipeline Dependencies

Here is the order and dependencies of the jobs in the pipeline

  • Install Dependencies Production
    • Verify Environment Vars Production
      • Run Data Crons Production
        • Check Types Production
        • Check/Apply Format Production
        • ESLint Checks Production
          • Unit Tests Production
            • End-2-End Tests Production
              • Build Application Production
                • Deploy in AWS Production
                • Deploy in WALDC Production

Triggers

Current triggers are on push for each of the environments. Pushing to each main, pre-production or development branch will trigger a full pipeline and deploy. Exception is the default main branch as mentioned above, which requires a manual click to start the last deployment phase.

Additionally, we have a trigger for new git tags, which trigger the release workflow and create a new release on gitlab.

Finally, we have a trigger on pull/merge request to the main branch, which will run all the checks using development .env variables but will omit the deployment phase. In the future we'd like to use gitlabs' review apps feature, to deploy on dynamic environment that will use our dev back end. E.g- Feature A branch opens a PR to main, after pipeline succeeds, the changes will be live on a feature-a-branch.casino777.be

Changelogs

We're using standard-version and conventional commit messages, to help us automatically generate changelogs on each git tag. The changelog only includes added features and bug fixes, but we can expand the types of commits that we include by modifying the .versionrc file. The changelog will also point out any breaking changes mentioned when commiting via our npm run commit command. The generated changelog will also include the JIRA # with a link to the issue, the commit message with link to the changes and the commit description.

Releases

Gitlab releases are based on our latest git tags. They are an easy way to keep track of state of code that is running on production at any given point.

Integrations

We have the following integrations enabled.

  • Google Chat
    • Everytime there is a failed deploy, new merge request or updated merge request to main, we will receive a notification from our chat bot on the CI/CD Alerts space on google chat. (The whole team has access to this channel, including QA. If you do not please ask to be added).
  • JIRA
    • We can see linked pull requests, commits and branches directly in JIRA and any mention of a JIRA ticket in a commit message, pull request or changelog is automacially linked with the correct JIRA link. Pull requests will also automacially insert Mentions JIRA# with the link.
  • Email integration (Beta)
    • On every new git tag & release, we can specify a list of recipients that will receive the changelog information of the latest release.

Rules and Caveats

  • To ensure consistent commit messages, please use npm run commit to commit files. This will prompt you to follow a structured commit message format using Commitizen.
  • Please use npm run create:component to create a new React component using Plop.
  • When formatting code using npm run format, note that the formatting may not always be perfect. Please double-check the formatted code and manually adjust if necessary.
  • If you encounter an error while running any of the npm scripts, please try deleting the node_modules directory and running npm install again.
  • When running the tests using npm run test, note that the test coverage may not always be 100%. Please double-check the test coverage report and add additional tests if necessary.
  • When using the lint script, please note that some linting errors may not be fixable automatically. Please double-check and manually fix any linting errors that cannot be fixed automatically.
  • Functions, classes, commands, etc. that are prefixed with an underscore (_) are considered private and should not be used outside of the file in which they are defined.