docs(readme): update contribution guidelines and add stub server features

Author: jackie muzakki

Readme.md

@@ -1,60 +1,62 @@
 # GripMock
-GripMock is a **mock server** for **GRPC** services. It's using a `.proto` file to generate implementation of gRPC service for you.
+GripMock is a **mock server** for **gRPC** services. It uses a `.proto` file to generate implementation of gRPC service for you.
 You can use gripmock for setting up end-to-end testing or as a dummy server in a software development phase.
-The server implementation is in GoLang but the client can be any programming language that support gRPC.
+The server implementation is in GoLang but the client can be in any programming language that supports gRPC.
 
 ---
 
-### Announcement:
-The latest [version (v1.10)](https://github.com/tokopedia/gripmock/releases/tag/v1.10) of gripmock is requiring `go_package` declaration in the `.proto` file. This is due to the latest update of `protoc` plugin that being used by gripmock is making the `go_package` declaration mandatory.
+### Note from the author
+Hi all, Jackie here. First of all, I would like to thank you for all those who have contributed to this project. This project has been and will be maintained in my free time, and I maintain it basically by myself, so I apologize for any extremely delayed responses from my side. 
 
-**Update Feb 2022:**
+Regarding contribution:
+- Please raise a PR with a detailed description and state a clear motivation. 
+- The code implementation should meet the standards that have been set in this repo. 
+- Only well-demanded features will be accepted, so if you think a feature is uniquely suited to your use case, you can keep it to yourself.
+- Tests are mandatory, both unit tests and integration tests whenever applicable. 
 
-[Version 1.11-beta](https://github.com/tokopedia/gripmock/releases/tag/v1.11-beta) release is available.
-It supports **NO** declaration of `go_package`, please download and test before it can be tagged as stable.
-
-you can get the docker image using `docker pull tkpd/gripmock:v1.11-beta`.
+Regarding roadmap:
+- I would like to keep gripmock as simple as possible. I want this tool to be as reliable as possible and easy to maintain.
+- My priority is to keep up with the latest updates from the frameworks (go, grpc, protoc, etc.) so that this tool can be used with the latest proto.
+- Once in a while, I'll check the issues and PR list to see what features are worth adding to gripmock. 
 
 ---
 
 ## Quick Usage
-First, prepare your `.proto` file. Or you can use `hello.proto` in `example/simple/` folder. Suppose you put it in `/mypath/hello.proto`. We are gonna use Docker image for easier example test.
-basic syntax to run GripMock is
-`gripmock <protofile>`
+First, prepare your `.proto` file. Or you can use `hello.proto` in `example/simple/` folder. Suppose you put it in `/mypath/hello.proto`. We will use Docker image for easier example test.
 
 - Install [Docker](https://docs.docker.com/install/)
 - Run `docker pull tkpd/gripmock` to pull the image
-- We are gonna mount `/mypath/hello.proto` (it must be a fullpath) into a container and also we expose ports needed. Run `docker run -p 4770:4770 -p 4771:4771 -v /mypath:/proto tkpd/gripmock /proto/hello.proto`
-- On a separate terminal we are gonna add a stub into the stub service. Run `curl -X POST -d '{"service":"Gripmock","method":"SayHello","input":{"equals":{"name":"gripmock"}},"output":{"data":{"message":"Hello GripMock"}}}' localhost:4771/add `
-- Now we are ready to test it with our client. You can find a client example file under `example/simple/client/`. Execute one of your preferred language. Example for go: `go run example/simple/client/*.go`
+- We will mount `/mypath/hello.proto` (it must be a fullpath) into a container and also we expose ports needed. Run `docker run -p 4770:4770 -p 4771:4771 -v /mypath:/proto tkpd/gripmock /proto/hello.proto`
+- On a separate terminal, we will add a stub into the stub service. Run `curl -X POST -d '{"service":"Gripmock","method":"SayHello","input":{"equals":{"name":"gripmock"}},"output":{"data":{"message":"Hello GripMock"}}}' localhost:4771/add `
+- Now we are ready to test it with our client. You can find a client example file under `example/simple/client/`. Execute the example in your preferred language. Example for Go: `go run example/simple/client/*.go`
 
-Check [`example`](https://github.com/tokopedia/gripmock/tree/master/example) folder for various usecase of gripmock.
+Check [`example`](https://github.com/tokopedia/gripmock/tree/master/example) folder for various use cases of gripmock.
 
 ---
 
 ## How It Works
 ![Running Gripmock](/assets/images/gripmock_readme-running%20system.png)
 
 From client perspective, GripMock has 2 main components:
-1. GRPC server that serves on `tcp://localhost:4770`. Its main job is to serve incoming rpc call from client and then parse the input so that it can be posted to Stub service to find the perfect stub match.
-2. Stub server that serves on `http://localhost:4771`. Its main job is to store all the stub mapping. We can add a new stub or list existing stub using http request.
+1. GRPC server that serves on `tcp://localhost:4770`. Its main job is to serve incoming RPC calls from client and then parse the input so that it can be posted to Stub service to find the perfect stub match.
+2. Stub server that serves on `http://localhost:4771`. Its main job is to store all the stub mappings. We can add a new stub or list existing stubs using http request.
 
-Matched stub will be returned to GRPC service then further parse it to response the rpc call.
+Matched stub will be returned to GRPC service then further parse it to respond to the RPC call.
 
 
 From technical perspective, GripMock consists of 2 binaries. 
-The first binary is the gripmock itself, when it will generate the gRPC server using the plugin installed in the system (see [Dockerfile](Dockerfile)). 
-When the server sucessfully generated, it will be invoked in parallel with stub server which ends up opening 2 ports for client to use.
+The first binary is the gripmock itself, which will generate the gRPC server using the plugin installed in the system (see [Dockerfile](Dockerfile)). 
+When the server successfully generated, it will be invoked in parallel with stub server which ends up opening 2 ports for client to use.
 
-The second binary is the protoc plugin which located in folder [protoc-gen-gripmock](/protoc-gen-gripmock). This plugin is the one who translates protobuf declaration into a gRPC server in Go programming language. 
+The second binary is the protoc plugin which is located in the folder [protoc-gen-gripmock](/protoc-gen-gripmock). This plugin is the one who translates protobuf declaration into a gRPC server in Go programming language. 
 
 ![Inside GripMock](/assets/images/gripmock_readme-inside.png)
 
 ---
 
 ## Stubbing
 
-Stubbing is the essential mocking of GripMock. It will match and return the expected result into GRPC service. This is where you put all your request expectation and response
+Stubbing is the essential mocking feature of GripMock. It will match and return the expected result into GRPC service. This is where you put all your request expectations and responses.
 
 ### Dynamic stubbing
 You could add stubbing on the fly with a simple REST API. HTTP stub server is running on port `:4771`
@@ -63,6 +65,8 @@ You could add stubbing on the fly with a simple REST API. HTTP stub server is ru
 - `POST /add` Will add stub with provided stub data
 - `POST /find` Find matching stub with provided input. see [Input Matching](#input_matching) below.
 - `GET /clear` Clear stub mappings.
+- `POST /reset` Reset stub mappings by clearing all stubs and reloading them from the configured stub file path (if provided).
+- `GET /requests` List all recorded requests that have been made to the stub server.
 
 Stub Format is JSON text format. It has a skeleton as follows:
 ```
@@ -118,11 +122,11 @@ Stub will respond with the expected response only if the request matches any rul
   "service":"<service name>",
   "method":"<method name>",
   "data":{
-    // input that suppose to match with stored stubs
+    // input that is supposed to match with stored stubs
   }
 }
 ```
-So if you do a `curl -X POST -d '{"service":"Greeter","method":"SayHello","data":{"name":"gripmock"}}' localhost:4771/find` stub service will find a match from listed stubs stored there.
+So if you do a `curl -X POST -d '{"service":"Greeter","method":"SayHello","data":{"name":"gripmock"}}' localhost:4771/find` stub service will find a match from listed stubs.
 
 ### Input Matching Rule
 Input matching has 4 rules to match an input: **equals**, **equals_unordered**, **contains** and **regex**
@@ -145,7 +149,7 @@ Nested fields are allowed for input matching too for all JSON data types. (`stri
             "turkish": "Merhaba Dünya!"
       },
       "ok": true,
-      "numbers": [4, 8, 15, 16, 23, 42]
+      "numbers": [4, 8, 15, 16, 23, 42],
       "null": null
     }
   }
@@ -170,7 +174,7 @@ Nested fields are allowed for input matching too for all JSON data types. (`stri
             "turkish": "Merhaba Dünya!"
       },
       "ok": true,
-      "numbers": [4, 8, 15, 16, 23, 42]
+      "numbers": [4, 8, 15, 16, 23, 42],
       "null": null
     }
   }