KamiQuasi/web-application-reference

WIP repo to hold Red Hat/IBM web application reference

Web Application Reference

Overview

The goal of the Web Application Reference is to present the teams 'opinion' on what components our customers and internal teams should use when building Web applications and guidance for how to be successful in production with those components.

The components in this architecture are what we recommend to help internal and external customers get started based on our experience. Other components may be equally good, but these are the ones we know best and have the most experience with.

• Where possible the opinion is based on what we've used internally and in our customer engagements.
• The components specified will be our first priority for our contributions to open source projects in the JavaScript ecosystem.
• Due to the above these are the components the team is best positioned when working with internal and external customers. However, we do not include formal support for these components in any of our support offerings unless specifically identified in those offerings.
• The recommended components may change over time as technologies and approaches change.

The team

The team consists of engineers from across groups within IBM and Red Hat who:

• are actively engaged in the JavaScript/Node.js community
• have large Web applciation deployments
• provide consulting advice and/or development related to building Web applications for customers
• develop/deliver JavaScript components

Key tenets

• Whenever possible components should have been validated at scale within the team's JavaScript/Node.js deployments or in engagements with our customers.
• We need to consider licensing and other due diligence when mentioning components.
• The Web Application Reference focusses on the front-end, the existing Node.js Reference Architecture is the corresponding reference with a focus on the back-end.

Components

The reference architecture covers the following components (currently a work in progress with only a subset of sections having recommendations):

• Functional Components
  • Common
  • Back End
    • Web Framework
    • Template Engines
    • Message Queuing
    • Internationalization
    • GraphQL
    • Databases
    • Authentication and Authorization
    • Data Caching
    • REST API Development
    • Load Balancing, Scaling and Multi-threading
    • Consuming Services
    • Node versions/images
    • Transactions_handling
  • Front End
    • Front End Frameworks
    • Web Components
    • Offline
    • Local Storage
    • Authentication/Authorization
    • Cross Platform
    • Polyfills
    • State management
    • Graphics, Visualization, Charts
    • 3D modeling
    • Caching
    • Routing
• Development
  • Common Elements
    • Choosing and vetting dependencies
    • Static Assets
    • Protecting Code
    • Code Quality
      • Code Consistency
      • Testing
      • Code Coverage
      • TypeScript
    • Cross Origin Communication
    • CI/CD
    • Npm
      • Npm Proxy / Internal Registries
      • Npm Publishing
      • Package Development
    • Secure Development Process
  • Backend Development
    • Typical Development Workflows
    • Kubernetes-based Development Environment
    • Building good containers
    • Accessibility
    • Serverless
  • Front-end Development
    • Typical Development Workflows
    • Build tools
    • Back end communication
    • Styles
    • Accessibility
    • Project layout
    • Rendering
    • Performance
    • Security
• Operations
  • Common
  • Back-end
    • Monitoring
      • Logging
      • Metrics Collection
      • Health Checks
      • Distributed Tracing
    • Problem Determination
    • Failure Handling
  • Front-end
    • Monitoring
      • Logging
      • Metrics Collection
      • Health Checks
      • Distributed Tracing
    • Problem Determination
    • Failure Handling
    • Deployment
    • Externalizing Environment variables

Contributing

To Contribute to this project, please see the Contributing Guide.

Contributors