chore: update README

Author: siddharthlatest

README.md

@@ -1,7 +1,6 @@
 # Arc
 
-Arc is a simple, modular API Gateway that sits between a client and an [ElasticSearch](https://elastic.co) cluster. It acts as a reverse proxy, routing requests from clients to services. Arc is extended through plugins, which provide extra functionality and services beyond the ElasticSearch's RESTful API. It can perform various cross-cutting tasks such as basic authentication, logging, rate-limiting, source/referers whitelisting, analytics etc. These functionalities can clearly be extended by adding a plugin encapsulating a desired  functionality. It also provides some useful abstractions that helps in managing and controlling the access
-to ElasticSearch's RESTful API.
+Arc is an API Gateway that sits between a client and an [ElasticSearch](https://elastic.co) cluster. It acts as a reverse proxy, routing requests from clients to services. Arc is extended through plugins, which provide extra functionality and services beyond the ElasticSearch's RESTful API. It can perform various cross-cutting tasks such as basic authentication, Role Based Access Control (using JWTs), logging, rate-limiting, source/referers whitelisting, analytics etc. These functionalities can clearly be extended by adding a plugin encapsulating a desired  functionality. It also provides some useful abstractions that helps in managing and controlling the access to ElasticSearch's RESTful API.
 
 ## Table of contents
 - [Overview](#overview)
@@ -15,10 +14,7 @@ to ElasticSearch's RESTful API.
 ## Overview
 
 When Arc is deployed, every client request being made to the Elasticsearch
-will hit Arc first and then be proxied to the Elasticsearch cluster. In between requests and responses, Arc
-may execute the installed plugins, essentially extending the Elasticsearch API feature set. Arc effectively
-becomes an entry point for every API request made to Elasticsearch. Arc can be used and deployed against any
-Elasticsearch cluster (locally and hosted as provided by [Appbase.io](https://appbase.io)).
+will hit Arc first and then be proxied to the Elasticsearch cluster. In between requests and responses, Arc may execute the installed plugins, essentially extending the Elasticsearch API feature set. Arc effectively becomes an entry point for every API request made to Elasticsearch. Arc can be used and deployed against any Elasticsearch cluster (locally and hosted as provided by [Appbase.io](https://appbase.io)).
 
 ```
                              .------------------------------------------.
@@ -50,6 +46,7 @@ Elasticsearch cluster (locally and hosted as provided by [Appbase.io](https://ap
 ## Installation
 
 ### Running it
+
 In order to run arc, you'll require an Elasticsearch node. There are multiple ways you can [setup an Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/current/setup.html), either locally or remotely. We, however, are delineating the steps for local setup of a single node Elasticsearch via it's Docker image.
 
 **Note**: The steps described here assumes a [docker](https://docs.docker.com/install/) installation on the system.
@@ -90,7 +87,7 @@ Alternatively, you could execute the following commands to start the server with
     go run main.go --env=config/manual.env
 
 
-**Note**: Running the executable assumes an active Elasticsearch connection whose url is to be provided in the `.env` file. manual.env configures it to be the localhost.
+**Note**: Running the executable assumes an active Elasticsearch upstream whose URL is provided in the `.env` file.
 
 ### Logging
 Define the run time flag (`log`) to change the default log mode, the possible options are:
@@ -104,22 +101,21 @@ Only log the errors
 
 #### TLS Support
 
-You can optionally start arc to serve https requests instead of http requests using the flag https.
-You also need to provide the server key & certificate file location through the environment file.
-manual.env is configured to use demo server key & certificates, which work for localhost.
+You can optionally start arc to serve https requests instead of http requests using the flag https. You also need to provide the server key & certificate file location through the environment file. `config/manual.env` is configured to use demo server key & certificates, which work for localhost.
+
 ```bash
     go run main.go --log=info --env=config/manual.env --https
 ```
-If you wish to manually test TLS support at localhost,
-curl needs to be also passed an extra parameter providing the cacert, in this case.
+
+If you wish to manually test TLS support at localhost, curl needs to be also passed an extra parameter providing the cacert, in this case.
+
 ```bash
     curl https://foo:bar@localhost:8000/_user --cacert sample/rootCA.pem
 ```
 
 #### JWT Key Loading through HTTP
 
-If you wish to test loading JWT Key through HTTP, you can use the following commands to start a HTTP
-server serving the key
+If you wish to test loading JWT Key through HTTP, you can use the following commands to start a HTTP server serving the key
 ```bash
     cd sample
     python -m SimpleHTTPServer 8500
@@ -129,30 +125,25 @@ Then start arc using the command:
     go run main.go --log=info --env=config/manual-http-jwt.env
 ```
 
+Arc also exposes an API endpoint to set the key at runtime, so this need not be set initially.
+
 #### Run Tests
 
-Currently, tests are WIP and implemented for auth, permissions and users modules. You can run tests using:
+Currently, tests are implemented for auth, permissions, users and billing modules. You can run tests using:
 
     go test ./...
 
 ### Implementation
 
-The functionality in Arc can extended via plugins. An Arc plugin can be considered as a service in itself; it can have its
-own set of routes that it handles (keeping in mind it doesn't overlap with existing routes of other plugins), its own chain of
-middleware and more importantly its own database it intends to interact with (in our case it is Elasticsearch). For example, one
-can easily have multiple plugins providing specific services that interact with more than one database. The plugin is responsible for its own request lifecycle in this case.
+The functionality in Arc can extended via plugins. An Arc plugin can be considered as a service in itself; it can have its own set of routes that it handles (keeping in mind it doesn't overlap with existing routes of other plugins), its own chain of middleware and more importantly its own database it intends to interact with (in our case it is Elasticsearch). For example, one can easily have multiple plugins providing specific services that interact with more than one database. The plugin is responsible for its own request lifecycle in this case.
 
-However, it is not necessary for a plugin to define a set of routes for a service. A plugin can easily be a middleware
-that can be used by other plugins with no new defined routes whatsoever. A middleware can either interact with a database or
-not is an implementation choice, but the important point here is that a plugin can be used by other plugins as long as it
-doesn't end up being a cyclic dependency.
+However, it is not necessary for a plugin to define a set of routes for a service. A plugin can easily be a middleware that can be used by other plugins with no new defined routes whatsoever. A middleware can either interact with a database or not is an implementation choice, but the important point here is that a plugin can be used by other plugins as long as it doesn't end up being a cyclic dependency.
 
 Each plugin is structured in a particular way for brevity. Refer to the plugin [docs](https://github.com/appbaseio/arc/blob/master/docs/plugins.md) which describes a basic plugin implementation.
 
 ### Abstractions
 
-Since every request made to Elasticsearch hits Arc first, it becomes beneficial to provide a set of abstractions that allows
-the client to define control over the Elasticsearch RESTful API and Arc's functionality. Arc provides several essential abstractions that are required in order to interact with Elasticsearch and Arc itself.
+Since every request made to Elasticsearch hits Arc first, it becomes beneficial to provide a set of abstractions that allows the client to define control over the Elasticsearch RESTful API and Arc's functionality. Arc provides several essential abstractions that are required in order to interact with Elasticsearch and Arc itself.
 
 ## Available Plugins
 
@@ -172,7 +163,7 @@ In order to interact with Arc, the client must define a `User`. A `User` encapsu
 
 ### Permission
 
-A `User` grants a `Permission` to a certain `User`, predefining its capabilities, in order to access Elasticsearch's RESTful API. Permissions serve as an entrypoint for accessing the Elasticsearch API and has a fixed *time-to-live* unlike a user, after which it will no longer be operational. A `User` is always in charge of the `Permission` it creates.
+A `User` grants a `Permission` to a certain `User`, predefining its capabilities in order to access Elasticsearch's RESTful API. Permissions serve as an entry point for accessing the Elasticsearch API and has a fixed *time-to-live* unlike a user, after which it will no longer be operational. A `User` is always in charge of the `Permission` they create.
 
 - `username`: an auto generated username that uniquely identifies the permission
 - `password`: an auto generated password that verifies the identity of the permission