Migrate micro-frontends

Renames to frontend-development because not all our frontend dev is micro.

This is a clean import of LBHackney-IT/micro-frontends@faecb61 plus removing the slug frontmatter on index.md/README.md to allow the build to succeed.

Author: spikeheap

docs/frontend-development/README.md

@@ -0,0 +1,21 @@
+---
+id: index
+title: Introduction
+---
+
+## Purpose
+
+The purpose of the Micro Frontend Playbook is to support Hackney Council establish a set of repeatable guidelines for teams to follow, implement and contribute towards.
+
+Collectively, we touch on many of the processes and operations that support our tenants, leaseholders, house officers and contractors (to name a few of our users), and it is in all of our interest to ensure a consistent experience across the platform.
+
+Setting the frontend standards across Hackney Council is an aspirational goal all teams building interfaces can aspire to. We can leverage the work of our fellow collegues, consultants and contractors without having to rebuilding similar features across programmes and streams.
+
+To address some of the earlier known challenges within Hackney Council in the FE space, we are advocating the use of Micro Frontends for building modern web interfaces.
+
+Finally, in the spirit of enabling our end users and to share a common experience when engaging with the Hackney Council platform, we encourage everyone to participate, learn and share on this playbook.
+
+
+
+## Help us improve
+We are always looking at ways we can improve. If you have any ideas or suggestions please share your feedback on our Micro-Frontends [GitHub Repo](https://github.com/LBHackney-IT/micro-frontends).

docs/frontend-development/architecture.md

@@ -0,0 +1,22 @@
+---
+id: architecture
+title: Architecture
+---
+
+We use the `single-spa` framework for managing MFE's within Hackney. Single-SPA offers a wide variety of tools to build MFEs, of which we have mostly followed the recommended approach.
+
+1. React & Typescript
+2. Runtime composition via SystemJS (Import-maps)
+3. Global UMD shared dependencies
+4. Utility Module (common) for shared components / utilities
+5. Route based (Vertical) splitting
+6. Individual git repos and CICD pipelines
+
+## Root Config
+The Root Config is the main entry point for the app and is responsible for the orchestration of the MFEs. It contains the import-map, which informs the app of the locations of each MFE, and what namespace to mount them in.
+
+## Applications
+These are the individual React MFEs. Primarily hold the views and components required to generate full pages. An Application can contain it's own router and maintain sub-routes related to the MFE.
+
+## Utility Modules
+A utility module is very similar to an Application, except it does not have any specific views, and is intended to be available globally from the root config. Utility modules should provide access to shared code, such as utility methods and generic React components.

docs/frontend-development/aws_services.md

@@ -0,0 +1,4 @@
+---
+id: aws_services
+title: AWS Services
+---

docs/frontend-development/benefits.md

@@ -0,0 +1,19 @@
+---
+id: benefits
+title: Benefits of MFE and example usages
+---
+
+## Independent Teams
+Microfrontends allow teams to work independantly with their own codebases, pipelines and release strategies to contribute to the same application. This leads to faster development, less dependencies and less domain knowledge required to start contributing effectively.
+
+## Isolated Environments
+Each MFE can have their own supporting architecture completley isolated from other parts of the ecosystem. If one MFE fails to build/deploy the rest of the ecosystem is unaffected. You also only need the MFE's you are working on during development, reducing complex getting started guides.
+
+## Scalabale Focussed Teams
+Focussed teams can be built around a single MFE allowing the org to scale independantly with considerably reduced onboarding efforts. Allowing domain expert developers to work on features autonomously.
+
+## Maintainable
+MFE's are in general much smaller applications to their monolith counterparts. Allowing developers to understand the entirety of the app with less overhead. Resulting in better long term maintainence.
+
+## Example of usage
+![MFE](./docs-images/mfe5.png)

docs/frontend-development/boilerplate.md

@@ -0,0 +1,72 @@
+---
+id: boilerplate
+title: BoilerPlate
+slug: /boilerplate
+---
+
+## Base configuration repo
+A refresher on the benefits of microfrontends in the context of Hackney Council:
+- Each team has the power to deploy microfrontends independently
+- Teams can benefit from other teams and collectively contribute to wider Hackney standards
+
+We propose using a tried a tested microfrontend framework called single-spa for scaffolding MFE applications.
+
+The framework documentation can be found [here](https://single-spa.js.org/docs/getting-started-overview).
+
+On a high level, the key thing to keep in mind is that a root config is responsible for rendering HTML pages and the associated javascript. Each MFE application is visible to the root config, which is responsible for displaying the relevant pages to a user.
+
+The microfrontend's that are built will still be applications that developers are already used to.In another words if you would have built with a project with React JS, you can stay assured that you will be building with React JS.
+(this would apply to other frontend frameworks as well!)
+
+Setting up a MFE using single span is very easy, you can begin scaffolding an application with the CLI with the command below:
+
+```
+npx create-single-spa 
+```
+
+The CLI neatly allows you to scaffold the root config or the MFE applications.
+
+Start by selecting the option most relevant to you:
+- single-spa application / parcel
+- in-browser utility module (styleguide, api cache, etc)
+- single-spa root config
+
+Select the FE frameworks of choice:
+- react
+- vue
+- angular
+- svelte
+
+Select the preferred package manager:
+- yarn
+- npm
+- pnpm
+
+Enable typescipt:
+- Yes
+- No
+
+Organisation name:
+- e.g mtfh (modern tools for housing)
+
+
+Project name:
+- e.g tenure (for the tenure screen)
+
+
+After choosing your options, the CLI will scaffold the project as per your needs
+
+## Content
+If you already are aware of the endpoints you might use, feel free to update the README.md for others to see how they can run your project locally.
+
+```
+ACTIVITIES_API_URL=
+PERSON_API_URL=
+```
+
+[Click here](https://github.com/LBHackney-IT/mtfh-frontend-activity-history) for an example of a README.md you can take inspiration from.
+
+
+
+
+

docs/frontend-development/deployment_and_architecture.md

@@ -0,0 +1,4 @@
+---
+id: deployment_and_architecture
+title: Deployment and Architecture
+---