Fix spelling and grammar errors across documentation (ECO-101) (#158)

* Initial plan

* Fix spelling and grammar issues in documentation

Co-authored-by: theduke <[email protected]>

* Fix more spelling and grammar issues (persistent, let's, article usage)

Co-authored-by: theduke <[email protected]>

* Fix e.g. formatting in FAQ

Co-authored-by: theduke <[email protected]>

* Fix remaining spelling issues (confusing, cannot)

Co-authored-by: theduke <[email protected]>

---------

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: theduke <[email protected]>

Author: Copilot

pages/edge/architecture.mdx

@@ -5,7 +5,7 @@ import ImageLoader from "@components/ImageLoader";
 ## Wasmer Edge - Built for the future
 
 Wasmer Edge has been built from the ground up to host pure WebAssembly packages
-fully natively - nothing else like this exists today and is only possibly through
+fully natively - nothing else like this exists today and is only possible through
 the close integration of the an Open Source runtime (in this case Wasmer), a WASM
 package manager and a distributed hosting infrastructure.
 
@@ -91,7 +91,7 @@ and long term low cost operations:
   https://en.wikipedia.org/wiki/Shared-nothing_architecture
 
 - Density of workloads running on edge nodes has been highly optimized for pure
-  WebAssembly hosting allowing for a high degree **scale-up** through optmizations of the runtime.
+  WebAssembly hosting allowing for a high degree **scale-up** through optimizations of the runtime.
 
 - The distributed monolith approach of Wasmer Edge means all nodes are identical
   and can be replicated with little need for scaling supporting infrastructure that
@@ -174,10 +174,10 @@ and handle versioning of your apps.
 One of the core parts of Wasmer Edge is the runtime itself. By utilizing the
 Wasmer Runtime as the core virtualization platform of Wasmer Edge and the
 recently announced WASIX, the platform is now able to run real useful WASM
-programs and services directly on the edge. As the runtime itself developes
+programs and services directly on the edge. As the runtime itself develops
 over time this will continuously create new and exciting features for Wasmer Edge.
 
-As an example it is now possible to code up a HTTP server or API totally
+As an example it is now possible to code up an HTTP server or API totally
 in WASM using standard libraries and deploy it on Wasmer Edge so that it
 can serve requests.
 
@@ -210,13 +210,13 @@ mesh network that allow for sockets and networking from workloads. Over time,
 we will continue to unlock more core networking functionality.
 
 Traffic is sent from browsers over websockets to enter the Wasmer Distributed
-Network while UDP encapsulated (and encrypted) packets are used to ship enternet
+Network while UDP encapsulated (and encrypted) packets are used to ship ethernet
 frames (OSI Layer 2) between participating nodes in a specific virtual network.
 
 The design of the subsystems and topology is for many (hundreds of thousands) of
 unique virtual networks while all nodes can actively participate in a virtual network.
 
-Browsers only need to establish a WebSocket connection to the closests Wasmer
+Browsers only need to establish a WebSocket connection to the closest Wasmer
 Edge Node in order to join a virtual network.
 
 Great care was taken to implement design constraints that removed the requirements
@@ -237,7 +237,7 @@ import CoreDnet from "@assets/deploy/architecture/core-dnet.svg";
 - Supports **ARP** and **DHCP** snooping for port MAC learning
 - Supports both **IPv4** and **IPv6**
 - All tenant traffic is encrypted with unique (derived) tenant keys thus segmenting and sandboxing it from each other
-- Fully support for concurrent **socket polling**
+- Full support for concurrent **socket polling**
 - **Multithread** safe
 - Supports promiscuous **raw sockets**
 - Built in **DHCP** server
@@ -247,7 +247,7 @@ import CoreDnet from "@assets/deploy/architecture/core-dnet.svg";
 
 #### 1. Fully stateless
 
-Control planes add complexity and create single pointers of failure thus if one is able to
+Control planes add complexity and create single points of failure thus if one is able to
 deliver the same functionality without a control plane then it is a better design.
 
 #### 2. Peer-to-Peer connection-less

pages/edge/configuration.mdx

@@ -349,7 +349,7 @@ Available values:
 * `single_concurrency`
 
   Special scaling mode for apps that only support **a single request at a time**.
-  You should enable this mode if your app can not handle multiple requests concurrently.
+  You should enable this mode if your app cannot handle multiple requests concurrently.
 
   Only a single request will be sent to each instance at a time.
   Edge will dynamically scale up additional instances of your app as required by the incoming request volume, and shut them down when they are no longer needed.

pages/edge/faq.mdx

@@ -11,18 +11,18 @@ There will soon be a way to restrict your apps to only run in specified regions,
 ## What is threshold for 'spill over' when nodes are overloaded? Are allocations to edge nodes based on vCPU or request volume ?
 
 The system will load balance dynamically based on server load - this is not something that you should assume any functional transparency about. Edge will dynamically determine how many instances of your app to start up in a given region/server.
-Note that we will add configuration for this, eg: you will be able to specify that you want at most X instances in a given region, or that each instance of your app should handle at most X concurrent requests, with new instances launched dynamically if that threshold is exceeded.
+Note that we will add configuration for this, e.g., you will be able to specify that you want at most X instances in a given region, or that each instance of your app should handle at most X concurrent requests, with new instances launched dynamically if that threshold is exceeded.
 
 ## How long is the 'short idle period' before server termination. If post-request server-side processing is required, how can we prevent a shutdown? Is this determined by CPU usage, a timeout post-last request, or perhaps an interceptor in the WASIX VM monitoring for specific IO syscalls, such as `accept4` ?
 
-Currently this is a fixed value of a few minutes, but this can not be assumed, it may change at any time, and workloads can get evicted under contention.
-What we will add a graceful termination flow like on Linux: instances will receive a SIGTERM , and will have some time to clean up and finish remaining work, with hard termination only happening after a well-known grace period.
+Currently this is a fixed value of a few minutes, but this cannot be assumed, it may change at any time, and workloads can get evicted under contention.
+What we will add a graceful termination flow like on Linux: instances will receive a SIGTERM, and will have some time to clean up and finish remaining work, with hard termination only happening after a well-known grace period.
 
 ## Do we need utilities like pgBouncer ?
 
 It would probably be advisable.
-It's possible for multiple versions of your app to run on multiple servers in the same region, and for a bunch of new instances to get spawned , so you might have quite bursty connection counts.
-If you need more control, one of the features that we hope to finish in this quarter (before end of year) is persistent instances, which will keep running , and won't be dynamically spawned or terminated.
+It's possible for multiple versions of your app to run on multiple servers in the same region, and for a bunch of new instances to get spawned, so you might have quite bursty connection counts.
+If you need more control, one of the features that we hope to finish in this quarter (before end of year) is persistent instances, which will keep running, and won't be dynamically spawned or terminated.
 
 A note about database locality:
 We will have configuration that allows you to restrict your app to certain regions, so if you want to keep your instances close to the location of your database, that will be possible.

pages/edge/guides/laravel.mdx

@@ -38,7 +38,7 @@ You should be able to visit http://localhost:8000 and see the home page.
 
 ### Setup a Wasmer Package
 
-Now, lets make your app run with Wasmer. For that, you'll need to create a `wasmer.toml` file.
+Now, let's make your app run with Wasmer. For that, you'll need to create a `wasmer.toml` file.
 You can simply use this configuration:
 
 ```toml filename="wasmer.toml" copy

pages/edge/guides/volumes.mdx

@@ -6,28 +6,28 @@ import ImageLoader from "@components/ImageLoader";
 import dashboard from "@assets/app-dashboard.jpeg";
 
 
-# Using peristent storage in Wasmer Edge Apps
+# Using persistent storage in Wasmer Edge Apps
 
-In this tutorial, you will learn how to setup peristent storage for your edge apps
+In this tutorial, you will learn how to setup persistent storage for your edge apps
 
-Lets start with creating an edge application
+Let's start with creating an edge application
 
 You can quickstart with an application from one of our templates
 ```bash copy
 wasmer app create --template static-website
 ```
 
-Now, lets edit `app.yaml` to setup persistent volume
+Now, let's edit `app.yaml` to setup persistent volume
 
 Add
 ```yaml copy
 volumes:
   - name: data
     mount: /public/things_i_want_to_persist
 ```
-to `app.yaml`. This will mount a peristent volume named `data` into `/public/persistent_volume` directory of your application
+to `app.yaml`. This will mount a persistent volume named `data` into `/public/persistent_volume` directory of your application
 
-Now, lets re-deploy the app
+Now, let's re-deploy the app
 
 ```bash
 wasmer deploy
@@ -49,9 +49,9 @@ You can use any s3 client to retrieve and upload data to your bucket
 />
 
 ## via s3 clients
-You can provide the credentials spesific to your app to any s3 client for accessing your volume. The credentials are available in your app's dashboard
+You can provide the credentials specific to your app to any s3 client for accessing your volume. The credentials are available in your app's dashboard
 
-Also, wasmer cli has a convinent way to configure rclone. `wasmer app volume configure` will print rclone configuration for connecting your apps volume
+Also, wasmer cli has a convenient way to configure rclone. `wasmer app volume configure` will print rclone configuration for connecting your apps volume
 
 ## via wasmer.io
 In the storage section of your app's dashboard, you can see links to browse your volumes. 
@@ -61,7 +61,7 @@ Note: You can only view, you can't upload files with the s3 frontend yet.
 
 # Proving persistency
 
-Now, lets upload "hello world" file to the volume. Get your volumes credentials and upload using an s3 client
+Now, let's upload "hello world" file to the volume. Get your volumes credentials and upload using an s3 client
 ```bash
 echo "Hello World!" > index.html
 rclone copy ./index.html edge-volume:/data
@@ -70,6 +70,6 @@ rclone copy ./index.html edge-volume:/data
 The template app we used will show the file you uploaded at https://your_app_url.wasmer.app/things_i_want_to_persist/index.html
 You can also use the s3 client or the s3 frontend that we host for you to view your uploaded file
 
-Now, lets force a container restart.
+Now, let's force a container restart.
 When updating your app with `wasmer deploy`, a new instance of your app will be created. So a new filesystem will be in use for your app and the volumes will be mounted
 After running `wasmer deploy`, you can see your `index.html` is still there. View from the app at url https://your_app_url.wasmer.app/things_i_want_to_persist/index.html, or from your s3 client, or from our hosted s3 frontend!

pages/edge/learn/deployment-modes.mdx

@@ -22,7 +22,7 @@ please [let us know on this issue](https://github.com/wasmerio/wasmer-edge-suppo
 
 WebServers are the most common type of applications.
 
-Wasmer Edge support two modes for webservers: Proxy and WCGI, and each comes with it's own advantages and tradeoffs.
+Wasmer Edge supports two modes for webservers: Proxy and WCGI, and each comes with its own advantages and tradeoffs.
 
 ### Proxy
 
@@ -51,7 +51,7 @@ To learn more about WASIX and how to build WASIX-enabled applications, see the
 
 ### WCGI
 
-WCGI, short for WebassmblyCommonGatewayInterface, uses the tried and true
+WCGI, short for WebAssembly Common Gateway Interface, uses the tried and true
 [CGI](https://en.wikipedia.org/wiki/Common_Gateway_Interface) protocol to process
 HTTP requests.
 

pages/edge/learn/volumes.mdx

@@ -64,7 +64,7 @@ The data will be purged, and your app will not have access to the volume anymore
 
 <Callout type="warning">
 If you rename or remove a volume from the `app.yaml` configuration,
-all data will be deleted when you deploy, and can not be recovered.
+all data will be deleted when you deploy, and cannot be recovered.
 
 Make sure this is what you want before deploying!
 </Callout>

pages/edge/vs/amazon-lambda.mdx

@@ -18,5 +18,5 @@ Wasmer Edge and Amazon Lambda differ in significant ways:
 - Wasmer Edge is built on **simpler and more scalable** technology than Lambda (which is built on top of Firecracker)
 - Wasmer Edge **doesn't require code changes in your application** to run, while you need to adapt your code to use the custom Lambda SDK to run.
 - Wasmer Edge **lets you reuse the same architecture to deploy your static assets and your dynamic websites**, while Amazon Lambda focuses only on the dynamic requests and recommends using S3 for your static assets.
-- Wasmer Edge can run UDP and other protocols while Amazon Lambda can not.
+- Wasmer Edge can run UDP and other protocols while Amazon Lambda cannot.
 - Amazon Lambda currently has more trigger options than Wasmer Edge

pages/graphql-api.mdx

@@ -27,7 +27,7 @@ Let's see now a few things that we can do with it!
 
 ### Get a Package Version
 
-We can do a POST to [https://registry.wasmer.io/graphql](https://registry.wasmer.io/graphql) with the the following as the `query` POST field:
+We can do a POST to [https://registry.wasmer.io/graphql](https://registry.wasmer.io/graphql) with the following as the `query` POST field:
 
 ```graphql
 {

pages/wasmer-pack/tutorial/02-strings-and-lists.md

@@ -77,7 +77,7 @@ impl strings_and_lists::StringsAndLists for StringsAndLists {
 ```
 
 The implementation of these functions is fairly straightforward, so we don't
-need to go into too much detain about it other than pointing out
+need to go into too much detail about it other than pointing out
 `greet_many()`'s use of [_Slice Patterns_][slice-patterns].
 
 ### A Note on Ownership