Merge pull request #1 from FedericoEsparza/typo_fixes

Typo fixes

README.md

@@ -4,15 +4,15 @@
 
 > This Prototype tries to resolve the biggest hurdle of connecting our services together. This is not possible in a sane way using our current approach.
 >
-> With this Prototype we can explore using the combination of GraphQL and the Neo4j Graph Database for achieving the connected nature of a social graph with better development experience as we do not need to connect data by our own any more through weird table structures etc.
+> With this Prototype we can explore using the combination of GraphQL and the Neo4j Graph Database for achieving the connected nature of a social graph with better development experience, as we do not need to connect data on our own any more through weird table structures etc.
 >
 > **Advantages:**
 
-> * easer data structure
+> * easier data structure
 > * better connected data
 > * easy to achieve "recommendations" based on actions \(relations\)
 > * more performant and better to understand API
 > * better API client that uses caching
 >
-> We still need to evaluate the drawbacks and estimate the development cost of such an approach
+> We still need to evaluate the drawbacks and estimate the development cost of such an approach.
 

SUMMARY.md

@@ -26,7 +26,7 @@
   * [Integration Testing](workflow/testing/integration-testing.md)
   * [Component Testing](workflow/testing/component-testing.md)
   * [Unit Testing](workflow/testing/unit-testing.md)
-* [Contribut](workflow/pull-requests.md)
+* [Contribute](workflow/pull-requests.md)
 * [Deployment](workflow/deployment.md)
 
 ## Recources

backend/installation/README.md

@@ -1,7 +1,7 @@
 # Backend Installation
 
 {% hint style="warning" %}
-This documentation should be split into a **local** and a **docker** installation variant. Also my be there should be a main docker installation guide for the while system at once!?
+This documentation should be split into a **local** and a **docker** installation variant. Also maybe there should be a main docker installation guide for the whole system at once!?
 {% endhint %}
 
 ### Clone Repository
@@ -43,23 +43,6 @@ npm install
 {% tab title="Yarn" %}
 #### Development
 
-```bash
-npm run dev
-```
-
-#### Production
-
-```bash
-# you will need to build the app first (done while building the docker image)
-npm run build
-# run after build (dist folder must exist)
-npm run start
-```
-{% endtab %}
-
-{% tab title="NPM" %}
-#### Development
-
 ```bash
 yarn run dev
 ```
@@ -73,6 +56,23 @@ yarn run build
 yarn run start
 ```
 {% endtab %}
+
+{% tab title="NPM" %}
+#### Development
+
+```bash
+npm run dev
+```
+
+#### Production
+
+```bash
+# you will need to build the app first (done while building the docker image)
+npm run build
+# run after build (dist folder must exist)
+npm run start
+```
+{% endtab %}
 {% endtabs %}
 
 This will start the GraphQL service \(by default on [http://localhost:4000](http://localhost:4000)\) where you can issue GraphQL requests or access GraphQL Playground in the browser

backend/middleware.md

@@ -10,5 +10,5 @@ A well-organized codebase is key for the ability to maintain and easily introduc
 
 A common problem in GraphQL servers is that resolvers often get cluttered with business logic, making the entire resolver system harder to understand and maintain.
 
-GraphQL Middleware uses the [_middleware pattern_](https://dzone.com/articles/understanding-middleware-pattern-in-expressjs) \(well-known from Express.js\) to pull out repetitive code from resolvers and execute it before or after one your resolvers is invoked. This improves code modularity and keeps your resolvers clean and simple.
+GraphQL Middleware uses the [_middleware pattern_](https://dzone.com/articles/understanding-middleware-pattern-in-expressjs) \(well-known from Express.js\) to pull out repetitive code from resolvers and execute it before or after one of your resolvers is invoked. This improves code modularity and keeps your resolvers clean and simple.
 

web-frontend/installation.md

@@ -1,7 +1,7 @@
 # Web Installation
 
 {% hint style="warning" %}
-This documentation should be split into a **local** and a **docker** installation variant. Also my be there should be a main docker installation guide for the while system at once!?
+This documentation should be split into a **local** and a **docker** installation variant. Also maybe there should be a main docker installation guide for the whole system at once!?
 {% endhint %}
 
 ### Clone Repository
@@ -16,7 +16,7 @@ git@github.com:Human-Connection/Nitro-Web.git
 ### Install Dependencies
 
 {% hint style="danger" %}
-Current you have to use the `--ignore-engines` parameter on install as the izitoast wrapper package claims to not work on node >= 9 which is not true. If the Author does not responde we might fork the package or make our own component out of it. So its an temporary issue.
+Current you have to use the `--ignore-engines` parameter on install, as the izitoast wrapper package claims to not work on node >= 9 which is not true. If the Author does not responde we might fork the package or make our own component out of it. So it's a temporary issue.
 {% endhint %}
 
 {% tabs %}

web-frontend/todos.md

@@ -1,5 +1,5 @@
 ---
-description: 'Want to help? Here you finde the recources for the Web part:'
+description: 'Want to help? Here you find the recources for the Web part:'
 ---
 
 # Todo's

workflow/pull-requests.md

@@ -1,4 +1,4 @@
-# Contribut
+# Contribute
 
 {% hint style="info" %}
 TODO: How to Contribute...

workflow/testing/README.md

@@ -2,19 +2,19 @@
 
 ## [Integration Testing](integration-testing.md)
 
-To test the all peaces together from the user perspective, we use integration tests. They also show if the the backend and the frontend are working as expected in conjunction and also if the browser likes our app. 
+To test all the pieces together, from the user perspective, we use integration tests. They also show if the the backend and the frontend are working as expected in conjunction and also if the browser likes our app. 
 
 [more...](integration-testing.md)
 
 ## [Component Testing](component-testing.md)
 
-Individual Vue Components should also be documented and testet properly. This guaranties they they are reusable and the api gets more solid in that process.
+Individual Vue Components should also be documented and tested properly. This guarantees that they are reusable and the api gets more solid in the process.
 
 [more...](component-testing.md)
 
 ## [Unit Testing](unit-testing.md)
 
-Expecially the Backend relies on Unit Tests as there are no Vue Components. 
+Expecially the Backend relies on Unit Tests, as there are no Vue Components. 
 
 [more...](unit-testing.md)