Permalink
Browse files

docs: remove references to BFF (#185)

For more context, see telus/technology-forum#227.
  • Loading branch information...
ruxandrafed authored and kspaans committed Oct 26, 2018
1 parent 4cb2151 commit 257c4bd510e1786240e3b1569203c6e4929bcc21
@@ -5,7 +5,6 @@
- [Starter Kits](starter-kits.md)
- [Versioning](versioning.md)
- [Colophon](colophon.md)
- [BFF](bff.md) _(Backend-for-frontend)_
- [URI Templates & Structure](uri-structure.md)
- [Application Configuration](application-configuration.md)
- [Dependency Management](dependencies.md)

This file was deleted.

Oops, something went wrong.
@@ -18,7 +18,7 @@ Not only can React code be used on the server and client side, there's also [Rea

The [TELUS Isomorphic Starter Kit](https://github.com/telusdigital/telus-isomorphic-starter-kit) is a standard boilerplate for building a Node.js isomorphic React application. It uses [webpack](webpack.md), and [babel](babel.md) to transpile the React JSX & ES2015 code into browser-native ES5. Using isomorphism, it pre-renders the React components on a page before sending the content to the browser client. After the browser receives the rendered application, it is able to render all further React components on the client side, using AJAX requests to populate it with data.

Generally speaking you do not want to put business logic in your React View. If you need business logic, you should use a [BFF](bff.md) ("Backend for Frontend") to handle all of the downstream data sources, and expose an API with data that matches the React component state. Our starter kit also ships with a BFF container by default, for this reason.
Generally speaking, you do not want to put business logic in your React View. If you need business logic, you should put your logic and handle all of the downstream data sources in the backend of your application, and expose data that matches the React component state.

## Who

@@ -10,7 +10,7 @@ Starter kits are a reference implementation of our reference architecture. A liv

## How

Our starter kits are autonomous GitHub repositories, with all of the functional implementation for a full [Continuous Integration](../process/continuous-integration.md) and [Continuous Delivery](../process/continuous-delivery.md) build pipeline. They implement our best practices for [Node.js](node.md), [React](react.md), [Redux](redux.md), [Express](express.md), [Jenkins](../delivery/jenkins.md), [Docker](../delivery/docker.md), [Kubernetes](../delivery/kubernetes.md), [OpenShift](../delivery/openshift.md), [Secrets](../delivery/secrets.md), [Logging](logging.md), [New Relic](newrelic.md), [Code Formatting](code-formatting.md), [BFFs](bff.md), and much, much more.
Our starter kits are autonomous GitHub repositories, with all of the functional implementation for a full [Continuous Integration](../process/continuous-integration.md) and [Continuous Delivery](../process/continuous-delivery.md) build pipeline. They implement our best practices for [Node.js](node.md), [React](react.md), [Redux](redux.md), [Express](express.md), [Jenkins](../delivery/jenkins.md), [Docker](../delivery/docker.md), [Kubernetes](../delivery/kubernetes.md), [OpenShift](../delivery/openshift.md), [Secrets](../delivery/secrets.md), [Logging](logging.md), [New Relic](newrelic.md), [Code Formatting](code-formatting.md), and much, much more.

They have been developed in a collaborative partnership with the following teams:
- Delivery
@@ -21,10 +21,7 @@ Use semantic versioning with the standard [npm publishing](npm.md) interface.

### API versioning

It may or may not be important to version our APIs. Typically we would avoid using versions, if at all possible. If versions are necessary, rather than keeping the old versions running, it is recommended to have _all supported versions_ implemented in your current API.

- Our BFFs should have a single client: The UI. The UI and BFF are coupled through one delivery pipeline, and released together. In this case their domain models and versioning are coupled, and the UI should always simply be accessing the latest version of its BFF.
- For our API platform services, we most likely need to version them, as they will be shared by teams, and we don't want to break other projects.
It may or may not be important to version our APIs. Typically we would avoid using versions, if at all possible. If versions are necessary, rather than keeping the old versions running, it is recommended to have _all supported versions_ implemented in your current API. For our API platform services, we most likely need to version them, as they will be shared by teams, and we don't want to break other projects.

There are multiple ways we _could_ pass our version to an API:

@@ -1,6 +1,6 @@
# Consumer-Driven Contract Tests

Modern web architecture is moving away from monoliths, patterns such as BFFs and micro services. In these modern patterns we have APIs being exposed, and as such it is very important to adopt a pattern of “Consumer-Driven Contract Tests”.
Modern web architecture is moving away from monoliths, patterns such as BFF (Backend For Front-end) and micro services. In these modern patterns we have APIs being exposed, and as such it is very important to adopt a pattern of “Consumer-Driven Contract Tests”.

## Illustrating the problem
Let’s say you have applications: A phone catalogue page (the Client) and a Product API (the Provider).

0 comments on commit 257c4bd

Please sign in to comment.