Permalink
Browse files

build(lint): add some linting meta files (#163)

* build(lint): add some linting meta files

* docs: fix remark lint warnings

* refactor(equipment): better readability + single monitor spec

* feat(auto-assign): use pro-bot auto assign feature to automate assigning reviewers (#164)

* docs(api): Updated README.md to include a link to live documentation. (#133)

* Expanded on the redux concept (#101)

* expanded more on the redux concept

* feat(docs): more Redux details

* fix(markdown): linting markdown content

* fix(markdown): lint markdown content

* fix(remove node_modules):

* feat(automation): add automation linting for markdown and editorconfig

* fix(markdown): apply markdown lint rules

* build(travis): setup build config
  • Loading branch information...
ahmadnassri authored and ruxandrafed committed Aug 29, 2018
1 parent 770987c commit bd23f1073b6cf9136418c39a03b668463e4bc4d0
Showing with 4,113 additions and 929 deletions.
  1. +12 −0 .editorconfig
  2. +1 −1 .github/CODEOWNERS
  3. +10 −10 .github/auto_assign.yml
  4. +1 −2 .gitignore
  5. +5 −0 .remarkrc
  6. +11 −0 .travis.yml
  7. +4 −5 README.md
  8. +4 −4 analytics/README.md
  9. +12 −13 analytics/{adobe_analytics_functions.md → adobe-analytics-functions.md}
  10. +7 −7 api/authorization-proxy.md
  11. +11 −8 api/circuit-breakers.md
  12. +10 −11 api/creating-an-api.md
  13. +1 −1 api/problem-details.md
  14. +5 −5 api/sdf-vendor-onboarding.md
  15. +164 −140 api/service-api-structure-guidelines.md
  16. +20 −20 content/content-migration.md
  17. +1 −1 delivery/README.md
  18. +12 −9 delivery/docker.md
  19. +19 −19 delivery/inbound-proxies.md
  20. +1 −1 delivery/kubernetes.md
  21. +17 −10 delivery/openshift.md
  22. +1 −1 delivery/secrets.md
  23. +1 −1 delivery/shippy.md
  24. +2 −1 delivery/tls-routes.md
  25. +1 −1 development/README.md
  26. +14 −14 development/accessibility.md
  27. +7 −8 development/application-configuration.md
  28. +2 −7 development/bff.md
  29. +9 −9 development/caching.md
  30. +1 −1 development/code-formatting.md
  31. +9 −12 development/css.md
  32. +12 −7 development/dependencies.md
  33. +1 −1 development/eslint.md
  34. +45 −45 development/express.md
  35. +5 −5 development/git.md
  36. +11 −6 development/gitignore.md
  37. +1 −1 development/isomorphic.md
  38. +1 −1 development/javascript.md
  39. +1 −1 development/jest.md
  40. +13 −14 development/libraries.md
  41. +4 −4 development/logging.md
  42. +1 −1 development/newrelic.md
  43. +0 −1 development/node.md
  44. +12 −15 development/npm.md
  45. +14 −18 development/redux.md
  46. +1 −1 development/starter-kits.md
  47. +7 −8 development/{supportedBrowsers.md → supported-browsers.md}
  48. +1 −1 development/transpiling.md
  49. +19 −16 development/uri-structure.md
  50. +2 −4 development/versioning.md
  51. +1 −1 development/webpack.md
  52. +5 −3 development/yaml.md
  53. +2 −3 equipment/README.md
  54. +3,128 −0 package-lock.json
  55. +30 −0 package.json
  56. +1 −1 performance/README.md
  57. +1 −2 performance/api-performance-standards.md
  58. +1 −1 performance/css-optimization.md
  59. +2 −3 performance/page-speed-insights.md
  60. +2 −2 performance/server-side-rendering.md
  61. +2 −2 process/README.md
  62. +10 −11 process/architecture.md
  63. +1 −1 process/continuous-delivery.md
  64. +1 −1 process/continuous-integration.md
  65. +5 −5 process/contribution-model.md
  66. +28 −25 process/project-template.md
  67. +15 −17 process/small-stories-are-faster.md
  68. +17 −18 process/user-stories.md
  69. +5 −0 renovate.json
  70. +4 −6 security/README.md
  71. +21 −15 security/checklist.md
  72. +21 −21 security/domain-management.md
  73. +0 −2 security/password-policy.md
  74. +1 −1 security/pi.md
  75. +3 −2 security/privacy-policy.md
  76. +4 −5 security/project-inception-and-security-process.md
  77. +2 −2 security/web-configuration.md
  78. +52 −53 testing/README.md
  79. +7 −4 testing/functional/{consumer_driven_contracts.md → consumer-driven-contracts.md}
  80. +8 −10 testing/functional/unit.md
  81. +1 −1 testing/functional/visual-regression.md
  82. +5 −1 testing/nonfunctional/analytics.md
  83. +0 −2 testing/nonfunctional/load.md
  84. +1 −1 testing/nonfunctional/performance.md
  85. +1 −1 testing/nonfunctional/security.md
  86. +35 −45 testing/nonfunctional/seo.md
  87. +14 −11 testing/standards/defect.md
  88. +17 −11 testing/tools_platforms/{devicefarm_security.md → devicefarm-security.md}
  89. +65 −72 testing/tools_platforms/devicefarm.md
  90. +34 −53 testing/tools_platforms/devicefarmfaq.md
  91. +17 −24 testing/tools_platforms/devicefarming.md
  92. +16 −16 testing/tools_platforms/devicelist.json
  93. +1 −2 testing/tools_platforms/saucelabs.md
@@ -0,0 +1,12 @@
root = true
[*]
charset = utf-8
end_of_line = lf
indent_size = 2
indent_style = space
insert_final_newline = true
trim_trailing_whitespace = true
[*.md]
trim_trailing_whitespace = false
@@ -1 +1 @@
* @telus/digital-architecture
* @telus/digital-architecture
@@ -1,10 +1,10 @@
addReviewers: true
addAssignees: true
reviewers:
- ruxandrafed
- kspaans
- ahmadnassri
numberOfReviewers: 2
addReviewers: true
addAssignees: true
reviewers:
- ruxandrafed
- kspaans
- ahmadnassri
numberOfReviewers: 2
@@ -1,2 +1 @@
.idea
.DS_Store
/node_modules
@@ -0,0 +1,5 @@
{
"plugins": [
"@telus/remark-preset-lint-markdown"
]
}
@@ -0,0 +1,11 @@
if: tag IS blank
language: node_js
services: docker
node_js: 10
cache:
directories:
- node_modules
@@ -1,5 +1,5 @@
![Reference Architecture Wiki Logo](logo.png "Reference Architecture Wiki")
---
# ![Reference Architecture Wiki Logo](logo.png "Reference Architecture Wiki")
> This is a collaborative effort to document our digital standards, tooling and process, you are welcome to contribute and suggest changes, please follow the [contribution guidelines](.github/CONTRIBUTING.md)
## Why
@@ -20,10 +20,9 @@ For new and existing team members & partners, a single place where all the techn
- [Analytics](analytics/README.md)
- [Hardware & Tooling](equipment/README.md)
## How
A *thin* and simple format documentation for technical resources, tools, platforms and decisions. Members can quickly and easily get context on "Why, What & How" for every part of our platform
A _thin_ and simple format documentation for technical resources, tools, platforms and decisions. Members can quickly and easily get context on "Why, What & How" for every part of our platform
A Public Github repository, with Markdown articles as content, (using the repository itself, rather than the "Github Wikis" Feature, this ensures:
@@ -35,4 +34,4 @@ The format should follow [this template](.template.md)
### Conformance
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) [[RFC2119](https://tools.ietf.org/html/rfc2119)] [[RFC8174](https://tools.ietf.org/html/rfc8174)] when, and only when, they appear in all capitals, as shown here.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) \[[RFC2119](https://tools.ietf.org/html/rfc2119)] \[[RFC8174](https://tools.ietf.org/html/rfc8174)] when, and only when, they appear in all capitals, as shown here.
@@ -1,10 +1,11 @@
# Analytics
## Why
To measure KPIs we leverage Adobe Analytics for web and mobile app data collection across TELUS.
To measure KPIs we leverage Adobe Analytics for web and mobile app data collection across TELUS.
## What
Adobe Analytics provides the space to store, query and visualize data.
Adobe DTM or Adobe Launch is a separate space, which specifies what and when data is sent to Adobe Analytics.
(Adobe Launch is the tag manager we are migrating towards)
@@ -13,11 +14,10 @@ Adobe DTM or Adobe Launch is a separate space, which specifies what and when dat
In addition to the Adobe tools above, every page needs a `dataLayer` object, which represents what data is available for sending to Adobe Analytics. As a tag manager like Adobe DTM or Adobe Launch is loaded on page, code will run to check for `dataLayer` and send a pageview as result. Nowadays, especially with SPA behavior, `dataLayer` needs to be updated as user interacts with page and cause DOM pages.
- [Process](https://telusdigital.atlassian.net/wiki/spaces/AI/pages/98467940/Analytics+Process)
- [List of Functions Exposed](adobe_analytics_functions.md)
- [List of Functions Exposed](adobe-analytics-functions.md)
## Reference
- [Global Tracking](https://telusdigital.atlassian.net/wiki/spaces/AI/pages/90308659/Global+Tracking#GlobalTracking-Introduction)
- [Testing if Data is Sent](https://telusdigital.atlassian.net/wiki/spaces/AI/pages/415793177/Testing+Adobe+Analytics)
- [Variable Mapping](https://telusdigital.atlassian.net/wiki/spaces/AI/pages/213320384/Solution+Design+Reference)
@@ -5,8 +5,8 @@ Existing analytics tagging depends on an out-of-box Adobe functionality to detec
This detection is a black-box and does not meet our requirements as users can trigger many changes quickly.
To avoid delaying when we set `datalayer`, we are exposing few methods to call to trigger hits directly.
## Caveat
This section will be updated as we extend more functionality.
- Check page is loading **Adobe DTM**, and not Adobe Launch. This is verified by looking for scripts src containing `adobedtm` and not `launch`.
@@ -26,22 +26,21 @@ E.g.,
6. a function such as `add_to_cart` from list below is called
7. an event hit is sent
## Functions
- Add to Cart
```javascript
var s = _satellite.getToolsByType('sc')[0].getS();
s.events="scAdd"
s.track('add_to_cart');
```
```js
var s = _satellite.getToolsByType('sc')[0].getS();
s.events="scAdd"
s.track('add_to_cart');
```
- Remove from Cart
```javascript
var s = _satellite.getToolsByType('sc')[0].getS();
s.events="scRemove"
s.track('remove_from_cart');
```
```js
var s = _satellite.getToolsByType('sc')[0].getS();
s.events="scRemove"
s.track('remove_from_cart');
```
## Notes
- Naming conventions for values inside `s.events` are all out-of-box and can't be changed.
@@ -12,13 +12,13 @@ With centralized session, we can also implement authenticated components on any
The Authorization Proxy handles:
* managing of OAuth2 login & logout redirections
* exchanging of OAuth2 code for Access and Refresh token
* refreshing of Access token based on Access token TTL
* manaing client id & certificate to SDF
* creating of authenticated and unauthenticated session
* aliging session id across applications
* provinding an easy way to register and deployment of APIs
- managing of OAuth2 login & logout redirections
- exchanging of OAuth2 code for Access and Refresh token
- refreshing of Access token based on Access token TTL
- manaing client id & certificate to SDF
- creating of authenticated and unauthenticated session
- aliging session id across applications
- provinding an easy way to register and deployment of APIs
## How
@@ -4,9 +4,9 @@
Circuit Breakers proxy consumption of a downstream system. They allow our services to "fail fast" in a predictable manner when downstream systems time out or return unhealthy responses. They will help to:
* avoid adding more load on a struggling server
* prevent passing on timeouts to the client, and hence provide end users a better user experience
* prevent cascading failures across distributed services
- avoid adding more load on a struggling server
- prevent passing on timeouts to the client, and hence provide end users a better user experience
- prevent cascading failures across distributed services
Circuit breakers are especially relevant for TELUS Digital APIs because many of them rely on downstream services like BTO while supporting customer-facing UIs. Currently, Appointment API is experimenting with using them.
@@ -16,17 +16,20 @@ Circuit breakers are especially relevant for TELUS Digital APIs because many of
-From [Martin Fowler on Circuit Breakers](https://www.martinfowler.com/bliki/CircuitBreaker.html)
## How
#### Implementation
### Implementation
You can write your own circuit breaker, or use an [existing npm library](https://www.npmjs.com/search?q=circuit%20breaker&page=1&ranking=optimal); many of them are based on Netflix's [Hystrix](https://github.com/Netflix/Hystrix) library and adapted for JavaScript.
Each downstream call can be wrapped in a circuit breaker, with configurable options that make sense for that specific call. Example options include:
* the threshold at which the circuit trips, for e.g. if 50% of calls result in errors
* how long a circuit is allowed to stay open before testing for downstream system health again, for e.g. 30 seconds
- the threshold at which the circuit trips, for e.g. if 50% of calls result in errors
- how long a circuit is allowed to stay open before testing for downstream system health again, for e.g. 30 seconds
#### Custom fallback method
### Custom fallback method
This is the custom method that is called when the circuit breaker has tripped, i.e. is open. You could return a useful error message here, or implement workarounds using, say, a cache. In addition, you can also do some logging or record metrics - circuit breakers are a valuable place for monitoring.
#### Don't use Auth Proxy (or in general, API gateways) for circuit breaking
### Don't use Auth Proxy for circuit breaking
Different services may have different needs for behaviour in the case that a circuit breaker is tripped, and as such control of this logic should be left to the service.
## References
@@ -6,23 +6,22 @@ To create an API that's part of the TELUS Digital API platform, there are a numb
## What
* APIs should be created using the [API starter kit](https://github.com/telus/api-starter-kit)
* If your API requires the use of SDF, it must be deployed to the `o-api-platform` project in OpenShift. To get it deployed there, follow instructions using the [shippy-cli](https://github.com/telus/shippy-cli). Otherwise, the API may be hosted in a different OpenShift project.
- APIs should be created using the [API starter kit](https://github.com/telus/api-starter-kit)
- If your API requires the use of SDF, it must be deployed to the `o-api-platform` project in OpenShift. To get it deployed there, follow instructions using the [shippy-cli](https://github.com/telus/shippy-cli). Otherwise, the API may be hosted in a different OpenShift project.
APIs that need to call services behind SDF or other digital APIs needs to be behind [Auth Proxy](authorization-proxy.md). To use Auth Proxy you'll need to:
* Configure your API as a [new target](https://github.com/telus/authorization-proxy/tree/master/src/config/application-wide) in all required environments.
* If your API is outside the `o-api-platform`, use the openshift URL of your service as the target.
* If your API requires to be authenticated, you must add your API name to the default.js file under the proper domain (Telus, koodo, etc) [here](https://github.com/telus/authorization-proxy/blob/master/src/config/request-context)
* Ensure that you have updated documentation in your API's GitHub repository under /swagger.
- Configure your API as a [new target](https://github.com/telus/authorization-proxy/tree/master/src/config/application-wide) in all required environments.
- If your API is outside the `o-api-platform`, use the openshift URL of your service as the target.
- If your API requires to be authenticated, you must add your API name to the default.js file under the proper domain (Telus, koodo, etc) [here](https://github.com/telus/authorization-proxy/blob/master/src/config/request-context)
- Ensure that you have updated documentation in your API's GitHub repository under /swagger.
You will need to link your documentation from the [main hub](https://github.com/telus/api-platform-docs/tree/master/src/config) under the appropriate environment.
## How
There are a number of TELUS libraries that make building digital APIs easier:
* [node-utility-middlewares](https://github.com/telus/node-utility-middlewares)
* [express-error-handlers](https://github.com/telus/express-error-handlers)
* [api-platform-utils](https://github.com/telus/api-platform-utils)
* [api-platform-middleware](https://github.com/telus/api-platform-middleware)
- [node-utility-middlewares](https://github.com/telus/node-utility-middlewares)
- [express-error-handlers](https://github.com/telus/express-error-handlers)
- [api-platform-utils](https://github.com/telus/api-platform-utils)
- [api-platform-middleware](https://github.com/telus/api-platform-middleware)
## References
@@ -22,4 +22,4 @@ As an API implementor, use a module like [node-error][node-error] to decorate yo
- [node-error: Ahmad's implementation of RFC7807](node-error)
[rfc7807]: https://tools.ietf.org/html/rfc7807
[node-error]: https://github.com/ahmadnassri/node-error
[node-error]: https://github.com/ahmadnassri/node-error
@@ -20,10 +20,10 @@ Keeping this pattern in mind, TELUS can architect software ahead of time in orde
This integration pattern only applies to:
* vendors external to TELUS, that
* provide capabilities to TELUS, that
* are accessed in a logically synchronous manner, and that
* are useful to more than one TELUS business unit (i.e. outside of just Digital, e.g. to Digital and to BTO).
- vendors external to TELUS, that
- provide capabilities to TELUS, that
- are accessed in a logically synchronous manner, and that
- are useful to more than one TELUS business unit (i.e. outside of just Digital, e.g. to Digital and to BTO).
### Logical Integration Architecture
@@ -51,4 +51,4 @@ Ideally, the selected vendor for a given capability natively implements a releva
#### SDF Onboarding
* See [the SDF API Governance documentation](http://habitat.tmi.telus.com/collaborate/display/sdf/API+Governance).
- See [the SDF API Governance documentation](http://habitat.tmi.telus.com/collaborate/display/sdf/API+Governance).
Oops, something went wrong.

0 comments on commit bd23f10

Please sign in to comment.