From f14da95bea03322885b699e223fe531a2f54b8f5 Mon Sep 17 00:00:00 2001 From: Robin Bourianes Date: Wed, 13 Mar 2024 08:08:35 +0000 Subject: [PATCH] Docs built from 155d5b46ad174718169e72555fdeca0fa22482b0 --- 404.html | 2 +- about/contact.html | 2 +- about/contributing.html | 2 +- about/introduction.html | 2 +- about/license.html | 2 +- guides/customizing/pwa.html | 2 +- guides/customizing/tour.html | 2 +- guides/introduction.html | 2 +- hashmap.json | 2 +- index.html | 2 +- reference/configuration.html | 2 +- 11 files changed, 11 insertions(+), 11 deletions(-) diff --git a/404.html b/404.html index 62c9cc60..ea521242 100644 --- a/404.html +++ b/404.html @@ -16,7 +16,7 @@
Skip to content

404

PAGE NOT FOUND

But if you don't change your direction, and if you keep looking, you may end up where you are heading.
- + \ No newline at end of file diff --git a/about/contact.html b/about/contact.html index b3312fad..91d590e9 100644 --- a/about/contact.html +++ b/about/contact.html @@ -19,7 +19,7 @@
Skip to content

Contact

Please feel free to join our slack channel using the invitation link.

- + \ No newline at end of file diff --git a/about/contributing.html b/about/contributing.html index e54e3d70..3effbced 100644 --- a/about/contributing.html +++ b/about/contributing.html @@ -19,7 +19,7 @@
Skip to content

Contributing

Submission guidelines

Report a bug

Before creating an issue please make sure you have checked out the docs, you might want to also try searching Github. It's pretty likely someone has already asked a similar question.

Issues can be reported in the issue tracker.

Pull Requests

We love pull requests and we're continually working to make it as easy as possible for people to contribute.

We prefer small pull requests with minimal code changes. The smaller they are the easier they are to review and merge. A core team member will pick up your PR and review it as soon as they can. They may ask for changes or reject your pull request. This is not a reflection of you as an engineer or a person. Please accept feedback graciously as we will also try to be sensitive when providing it.

Although we generally accept many PRs they can be rejected for many reasons. We will be as transparent as possible but it may simply be that you do not have the same context or information regarding the roadmap that the core team members have. We value the time you take to put together any contributions so we pledge to always be respectful of that time and will try to be as open as possible so that you don't waste it.

Commit message guidelines

We follow the Conventional commits specifications which provides a set of rules to make commit messages more readable when looking through the project history. But also, we use the git commit messages to generate the change log.

Commit message format

The commit message should be structured as follows:

<type>: <subject> [optional `breaking`]

Where type must be one of the following:

  • build: changes that affect the build system (external dependencies)
  • ci: changes to our CI configuration files and scripts
  • chore: changes that affect the project structure
  • docs: changes that affect the documentation only
  • feat: a new feature
  • fix: a bug fix
  • perf: a code change that improves performance
  • refactor: a code change that neither fixes a bug nor adds a feature
  • revert: revert changes
  • style: changes that do not affect the meaning of the code (lint issues)
  • test: adding missing tests or correcting existing tests

Use the optional [ breaking ] keyword to declare a BREAKING CHANGE.

Examples

  • Commit message with description and breaking change in body
feat: allow provided config object to extend other configs [ breaking ]
  • Commit message with no body
docs: correct spelling in the contributing.md file
  • Commit message for a fix using an issue number.
fix: fix minor issue in code (#12)

Versioning guidelines

We rely on Semantic Versioning for versioning a release. Indeed, given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make a major evolution leading to breaking changes,
  • MINOR version when you add functionality in a backwards-compatible manner
  • PATCH version when you make backwards-compatible bug fixes.

The command yarn release:<type>, where <type> is either patch, minor or major, helps you to do the release.

It performs the following task for you:

  • increase the package version number in the package.json file
  • generate the change log
  • create a tag accordingly in the git repository and push it

Contributor Code of Conduct

As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.

We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, or religion.

Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed from the project team.

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.

This Code of Conduct is adapted from the Contributor Covenant, version 1.0.0, available at http://contributor-covenant.org/version/1/0/0/

- + \ No newline at end of file diff --git a/about/introduction.html b/about/introduction.html index d986f281..3110cee9 100644 --- a/about/introduction.html +++ b/about/introduction.html @@ -19,7 +19,7 @@
Skip to content

About

kApp is an demonstration application based on the Kalisio Development Kit (KDK) available now as a single package @kalisio/kdk.

TIP

For a deeper understanding of the overall structure, please refer to our application template.

kApp built with the KDK

It aims at providing a basic example to setup the application server, the client build, the continuous integration and testing, as well as running use cases of KDK components.

- + \ No newline at end of file diff --git a/about/license.html b/about/license.html index dcf0a0b8..212b3c04 100644 --- a/about/license.html +++ b/about/license.html @@ -19,7 +19,7 @@
Skip to content

License

MIT License

Copyright (c) 2017-20xx Kalisio

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

- + \ No newline at end of file diff --git a/guides/customizing/pwa.html b/guides/customizing/pwa.html index 5e6f09ae..1a19fd37 100644 --- a/guides/customizing/pwa.html +++ b/guides/customizing/pwa.html @@ -19,7 +19,7 @@
Skip to content

PWA

The kApp is a Progressive Web App (PWA), which means it functions as both a web page and a mobile app, offering a versatile experience on any device.

TIP

To build and run the kApp as a PWA, check out the main commands here

Configuration

Web app manifest

A web app manifest provides essential information about the application, such as its name, author, icon, and description, in a JSON text document. The purpose of the manifest is to allow the installation of applications on a device's home screen. You can find this manifest in the Quasar configuration.

Service Worker

Service workers, which operate as JavaScript events, are a core component of a PWA and act as a proxy. They enable fast loading, offline access, push notifications, and other capabilities.

TIP

When the application is ready to be installed or updated, a pop-up window will appear.

Push notfication

KApp provides an example of how to implement push notifications using the feathers-webpush module.

- + \ No newline at end of file diff --git a/guides/customizing/tour.html b/guides/customizing/tour.html index b1831fd1..ff5b789d 100644 --- a/guides/customizing/tour.html +++ b/guides/customizing/tour.html @@ -63,7 +63,7 @@ previousDelay: 500 } }] - + \ No newline at end of file diff --git a/guides/introduction.html b/guides/introduction.html index 04b2b522..8348c0fd 100644 --- a/guides/introduction.html +++ b/guides/introduction.html @@ -19,7 +19,7 @@
Skip to content

Introduction

The kApp is a demo application created from skeleton. it includes all the necessary boilerplate that you will need to get started building your application:

It also includes the minimum viable set of features to start:

Infrastructure

The setup of application infrastructures is typically powered by our kaabah project while application deployment is typically powered by our kargo project.

- + \ No newline at end of file diff --git a/hashmap.json b/hashmap.json index b2a69bac..be8ab5c5 100644 --- a/hashmap.json +++ b/hashmap.json @@ -1 +1 @@ -{"about_contributing.md":"M53Nl2ze","about_contact.md":"ZM3GdUio","guides_customizing_pwa.md":"aMLg9SMM","about_introduction.md":"JgxNPSpd","about_license.md":"FdOcsEh8","guides_introduction.md":"fBpcXOSf","index.md":"TgyLsGxT","reference_configuration.md":"LgYAtfyx","guides_customizing_tour.md":"B4El4g7z"} +{"about_introduction.md":"JgxNPSpd","index.md":"TgyLsGxT","guides_customizing_pwa.md":"aMLg9SMM","guides_introduction.md":"fBpcXOSf","about_contact.md":"ZM3GdUio","reference_configuration.md":"LgYAtfyx","about_license.md":"FdOcsEh8","guides_customizing_tour.md":"B4El4g7z","about_contributing.md":"M53Nl2ze"} diff --git a/index.html b/index.html index 91697dbf..c4017525 100644 --- a/index.html +++ b/index.html @@ -19,7 +19,7 @@
Skip to content

kApp

kApp - KDK demonstration application

kapp-logo
- + \ No newline at end of file diff --git a/reference/configuration.html b/reference/configuration.html index 5346efb9..225e5b39 100644 --- a/reference/configuration.html +++ b/reference/configuration.html @@ -19,7 +19,7 @@
Skip to content

Configuring a kApp

Backend side

kApp backend configuration is based on Feathers so the same guidelines are applicable, the default configuration can be found in the api/config folder. The main properties are the following:

  • apiPath: the API path prefix
  • port: the server port
  • domain: the web application domain name (eg https://app.kalisio.xyz)
  • apiLimiter: the API rate limiting configuration
  • authentication : object configuring Feathers authentication plus custom options
    • passwordPolicy: password policy configuration
      • minLength: minimum length
      • maxLength: maximum length
      • uppercase: boolean indicating if the password requires at least an uppercase letter
      • lowercase: boolean indicating if the password requires at least an uppercase letter
      • digits: boolean indicating if the password requires at least a digit
      • symbols: boolean indicating if the password requires at least a symbol
      • prohibited: array of prohibited common passwords
      • history: number of passwords to look for in history to avoid keeping a similar one when changing
    • defaultUsers: the array of default users to be created on launch (format { email, password })
      • note: will not be exposed on staging/production environments for security concerns
    • limiter: the authentication API rate limiting configuration
  • logs: object configuring the winston loggers to be used - each key is a transport name which value is associated configuration options
  • db: database configuration
    • adapter: the database adapter, for now the only supported one is mongodb
    • url: database URL to access the app database used by drivers such as mongodb
  • storage: storage service configuration used by core
    • accessKeyId: AWS S3 access key
    • secretAccessKey: AWS S3 secret access key
    • bucket: AWS S3 bucket to be used
  • mailer: e-mail service configuration, compliant with nodemailer options plus custom Kalisio options, e.g.
    • service: e-mail service to be used (like gmail)
    • auth: user login and password
    • templateDir: directory containing the e-mails templates to be used
  • push: feathers-webpush configuration
    • subject: VAPID server contact information
    • publicKey: VAPID public key.
    • privateKey: VAPID private key
  • proxyTable: a set of proxy rules typically used for scaling

Environment variables (will override defaults in config file):

  • PORT / HTTPS_PORT: backend port for HTTP and HTTPS modes
  • CLIENT_PORT / HTTPS_CLIENT_PORT: frontend port for HTTP and HTTPS modes (only used in development)
  • DB_URL: database URL to access the app database

Frontend side

kApp frontend configuration is based on the same underlying tool that powers Feathers so the same guidelines are applicable, the default configuration can be found in the config folder. The main properties are the following:

  • apiPath: the API path prefix
  • apiTimeout: the API timeout
  • apiJwt: name of the local storage key used to store the JWT used by the internal API
  • gatewayJwt: name of the local storage key used to store the JWT used by the API gateway
  • version: the web application version number
  • flavor: the web application flavor
  • domain: the web application domain name (eg https://kapp.dev.kalisio.xyz)
  • gateway: the API gateway domain name (eg https://api.dev.kalisio.xyz)
  • transport : the transport to be used between frontend and backend, could be http for standard REST or websocket for WebSockets
  • appName: the name of the app
  • appLogo: the image to be used as logo for the app
  • theme: the theme to be used
  • logs
  • screens: connection screens configuration
    • extraLinks: extra links displayed at the bottom of all screens,
    • banner: displayed application banner,
    • login: login screen configuration
      • providers: array of OAuth2 providers to be used (like ['google', 'github']),
      • links: links displayed at the bottom of the screen,
    • logout: logout screen configuration
      • links: links displayed at the bottom of the screen,
    • changeEndpoint: change endpoint screen configuration (only useful for mobile apps)
      • links: links displayed at the bottom of the screen,
  • layout: layout configuration, see Quasar docs for details
  • myActivity: configuration of the activity named my-activity in the application
    • topPane: application bar components configuration for this activity
      • content: list of components to be displayed according to current mode of the activity (if any),
      • filter: component filter using any expression supported by sift,
    • leftPane: left pane (i.e. main menu) components configuration for this activity
      • content: list of components to be displayed according to current mode of the activity (if any),
      • filter: component filter using any expression supported by sift,
    • bottomPane: bottom pane components configuration for this activity
      • content: list of components to be displayed according to current mode of the activity (if any),
      • filter: component filter using any expression supported by sift,
    • rightPane: right pane components configuration for this activity
      • content: list of components to be displayed according to current mode of the activity (if any),
      • filter: component filter using any expression supported by sift,
    • page: additional page components configuration for this activity
      • content: list of components to be displayed according to current mode of the activity (if any),
      • filter: component filter using any expression supported by sift,
    • window: window (i.e. widgets) configuration for this activity
      • widgets: list of widgets to be displayed,
      • filter: component filter using any expression supported by sift,
    • fab: floating action button (FAB) configuration for this activity
      • actions: list of actions to be displayed,
      • filter: action filter using any expression supported by sift

TIP

The main difference with the backend configuration is that the actual frontend configuration is generated by WebPack at build time from the config files, so you will need to rebuild the app to see your changes applied

WARNING

Althought we use JS objects en environment variables in the frontend configuration to ease writing it please note that the resulting configuration file will be a static JSON file so don't store complex JS objects like functions in the config as it will not work

Environment variables for the frontend development server (will override defaults):

  • PORT / HTTPS_PORT: backend port for HTTP and HTTPS modes (used to configure proxy)
  • CLIENT_PORT / HTTPS_CLIENT_PORT: frontend port for HTTP and HTTPS modes
- + \ No newline at end of file