Akshat Singhal

@Umang01-hash Hope we are routing the reads within a transaction to the primary? I couldn't find any the corresponding code for it.

> This PR implements SQL-level routing (parsing queries) to split reads vs writes. Another approach is to use the HTTP method (e.g. `GET`=**read**, `POST/PUT`=**write**) to choose the DB. Given cases...

> One issue which might occur is if there is a POST request and user is first inserting the value and then fetching it. based on the query pattern which...

Routes will need to have the method as well. We would be better off accepting this configuration via code instead of complicating the ENV file. What we should ensure is...

Having standardisation is helpful for sure; however, we should be vary of over generalisation. Error interfaces should be defined at the store, service and delivery layer separately so that they...

>It leads to duplicated concepts - e.g., RecordNotFoundError, InvalidIdentifierError, NotFoundError which are all representing the same failure from different perspectives. While they are similar errors from different perspectives, the behaviour/handling...

> Can you share an example explaining the nature of layering expected here ? Helps provide more insights into it. Each layer (store, service, delivery) would have it's own error...

something like this.. ``` type StoreError interface { error getServiceError() ServiceError getRootCause() string } type ServiceError interface { error getHTTPError() HTTPError getGrpcError() GrpcError getRootCause() string } type HTTPError interface {...

**Counter view**: In case there's an error in the initialisation which was logged and application launched, subsequent operations would not work as intended and the developer is left digging for...

> We would like to keep RBAC as a separate module. Hence add go.mod in it. So that it does not get added in the binary of the gofr framework....