casino777-frontend v0.2.108
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, typed superset of JavaScript that adds static type checking and other features to the language. | Link to documentation |
|
| (v18) React a popular front-end JavaScript library for building user interfaces. | Link to documentation |
|
| (v13) Next JS a framework for building server-side rendered React applications. | Link to documentation |
|
| TailwindCSS - a utility-first CSS framework for quickly styling web applications. | Link to documentation |
|
| Jest - a popular Javascript testing framework | Link to documentation |
|
| Testing Library - a set of utilities for testing React components and applications. | Link to documentation |
|
| Cypress framework is a JavaScript-based end-to-end testing framework | Link to documentation |
|
| 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 - 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
- Jira Sprint Board
- Jira Kanban Board
- Jira Project Roadmap
- C777BE Confluence
- C777BE Architecture
- C777BE 3rd Party Integrations
- Internal NPM Repository
- Storybook
- Postman API Documentation
Environments
The below table refers to the environments used by the application when is run in different places
Place | Back-End | URL |
---|---|---|
local | dev | http://localhost:3000/ |
development | dev | https://beta-dev.casino777.be/ |
pre-production | prod | https://beta-pre-prod.casino777.be/ |
production | prod | https://beta.casino777.be/ |
Prerequisites
| Dependency | Version |
---|---|---|
Node | >= 14 < 17 | v16.14.2 |
Git | >= 2.2 | 2.34.1 |
NPM | >= 8 | 8.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
Command | Description |
---|---|
dev | Starts a development server using Next.js. |
build | Compiles the application for production. |
build:standalone | Compiles the application for production in standalone mode and copies the public and static folder s in the correct location |
start | Starts the application in production mode. |
analyze | Analyzes the application's bundle size using webpack-bundle-analyzer. |
export | Exports the application as static HTML files. |
clean | Removes the .next and out directories. |
lint | Runs the Next.js linter. |
format | Formats the code using Next.js linter and prettier. |
check:types | Checks TypeScript types in the project and in the cypress directory. |
test | Runs the test suite using Jest. |
test:ci | Runs the test suite using Jest when in CI (using different reporter). |
commit | Runs Commitizen, an interactive prompt for generating commit messages. |
commit:retry | Re-Runs the latest failed commitizen prompt. |
cypress | Opens the Cypress Test Runner. |
cypress:headless | Runs the Cypress tests in headless mode. |
cypress:ci | Runs the Cypress tests in headless ci (without Xvfb dependency) mode. |
e2e | Starts the development server, runs the Cypress tests, and shuts down the server. |
e2e:headless | Same as above, but runs the Cypress tests in headless mode. |
prepare | Installs Husky Git hooks. |
postbuild | Generates a sitemap after building the application. |
create:component | Generates a new React component using Plop. |
create:popup | Generates a new Popup component using Plop. |
create:middleware | Generates a new Middleware function using Plop. |
create:icon | Generates a new Icon component using Plop. |
create:api-route | Generates a new Api Route using Plop. |
test:coverage | Runs the test suite and generates a coverage report. |
test:badges | Runs the test suite and generates coverage badges using jest-coverage-badges. |
update:coverage:badges | Updates the coverage badges using a custom TypeScript script. |
check:environment | Checks the for missing .env & tries to create one (mainly for CI/CD) usage |
run:script | Runs a typescript file with node |
crons | Runs all crons, you can pass filter to run specific crons e.g npm run crons -- --filter=getGames which will only execute the getGames cron |
storybook | Runs Storybook in dev mode |
build:storybook | Builds Storybook in production mode (static) |
docker:start:dev | Starts the application in development mode using docker |
docker:start:prod | Starts the application in production mode using docker |
docker:stop:dev | Stops the application in development mode using docker |
docker:stop:prod | Stops the application in production mode using docker |
docker:build:dev | Builds the application in development mode using docker |
docker:build:dev:force | Builds the application in development mode using docker without using any cache |
docker:build:prod | Builds the application in production mode using docker |
docker:build:prod:force | Builds the application in production mode using docker without using any cache |
release | Invokes the standard-version cli |
release:minor | Invokes the standard-version cli and creates a minor release tag |
release:patch | Invokes the standard-version cli and creates a patch release tag |
release:major | Invokes 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 Variable | Description | Client Side Accessible |
---|---|---|
NEXT_PUBLIC_HOST_URL | Describes the base url of the website. e.g https://www.casino777.be | Yes |
NEXT_PUBLIC_ENV | Specifies the environment - "development" | "pre-production" | "production" | Yes |
NEXT_PUBLIC_CASHIER_URL | Describes the base url of cashier. e.g https://cashier.casino777.be | Yes |
SKIP_BUILD_STATIC_GENERATION | Determines whether to build pages or skip and do it request time | No |
PROJECT_ROOT_PATH | Defines 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 this | No |
SECRET_COOKIE_SALT_PASSWORD | Secret 32 characters long, used as salt when encrypting our user cookie. | No |
NEXT_PUBLIC_FULLSTORY_ORG_ID | FullStory Organisation ID. | Yes |
NEXT_PUBLIC_FULLSTORY_COOKIE_DOMAIN | FullStory Cookie Domain. | Yes |
NEXT_PUBLIC_WS_URL | The WS Base Url to our Node Js server & emitter | Yes |
NEXT_PUBLIC_WS_PORT | The WS Port for our Node Js server & emitter | Yes |
NEXT_PUBLIC_TRUSTPILOT_TEMPLATE_ID | Trust pilot Template ID. | Yes |
NEXT_PUBLIC_TRUSTPILOT_BUSINESS_UNIT_ID | Trust pilot business ID. | Yes |
NEXT_PUBLIC_GIFT_SHOP_URL | The url for the iframe of the pass online gift shop. | Yes |
NEXT_PUBLIC_RECAPTCHA_SITE_KEY | Google Recaptcha v3 site key | Yes |
NEXT_PUBLIC_GOOGLE_TAG_MANAGER_ID | The Google Tag Manager ID. | Yes |
ZENDESK_JWT_API_ID | The JWT ID aka "KID" from Zendesk messaging (web sdk only) | No |
ZENDESK_JWT_API_KEY | The JWT Secret from Zendesk messaging panel (web sdk only) | No |
NEXT_PUBLIC_ZENDESK_SCRIPT_KEY | The Zendesk asset key identifying the loading script | Yes |
PREFETCHER_TOKEN | Token passed to access the api prefetcher endpoint. | No |
REVALIDATE_TOKEN | Token passed to access the api revalidation functionality and cron execution | No |
TRANSLATION_TOKEN | Token passed to access the api translations json creator for native app | No |
MS_*_URL | Specifies the PHP microservice endpoint url | No |
MS_*_PUBLIC_KEY | Specifies the PHP microservice public key | No |
MS_*_PRIVATE_KEY | Specifies the PHP microservice private key | No |
ITSME_CLIENT_ID | The client id of ItsMe provider provider | No |
ITSME_SERVICE | The scope.service of ItsMe {LANG} should be replaced with the locale key | No |
ITSME_SERVICE_LOGIN | The scope.service of ItsMe {LANG} should be replaced with the locale key. This service is for login | No |
ITSME_DOMAIN | The domain of ItsMe provider key | No |
ITSME_PUBLIC_KEY | Our public key used for ItsMe key | No |
ITSME_PRIVATE_KEY | Our private key used for ItsMe key | No |
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 thecacheable
option set tofalse
. - 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 Dependencies | Run Data Crons | Verify Environment Vars |
---|---|---|
This phase runs npm ci to install all project dependencies and caches them so that the y are available for other jobs | The 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 Types | Check/Apply Format | ESLint Checks |
---|---|---|
This job runs our typescript checks and catches any TS issues as defined on our tsconfig | This uses our tsconfig, eslint and prettier config to format the code according to the projects code standards | This jobs ensures that all of our ESLint rules are met, there are no unused variables, imports etc. |
- test
Unit Tests | End-2-End Tests |
---|---|
We are running the projects test suite, to ensure no broken code gets shipped to production | This 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
- Build Application Production
- End-2-End Tests Production
- Unit Tests Production
- Run Data Crons Production
- Verify Environment Vars 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).
- 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
- 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.
- 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
- 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.
11 months ago