You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 29, 2018. It is now read-only.
A web page http request is initiated by the browser.
The app handler parses the request and uses the API client to create a new http request to itself but on to api routes.
The api handler handles the request from the api client and fetches/changes the relevant data in the datastore.
The api handler marshals a JSON response and sends it back to the api client.
The app then unmarshals the JSON response from the api client and renders it in a template?
—
Reply to this email directly or view it on GitHub.
What is the benefit of having it like this rather than having the app use the same data interface as the api? It seems like more overhead (extra marshal & unmarshal) and added complexity on every web request.
It does use the same interface. Why not just do all of the logic in the same Go process? We want to load balance, cache, and instrument our API calls. While this simple app obviously doesn't require those, it's a demonstration of what we do in Sourcegraph.com. For example, some of our frontend handlers make 10 API calls in parallel, and it's nice that we can use standard HTTP caching, and AWS Elastic Load Balancers, and appmon (our HTTP instrumenter) instead of inventing new things. This all reduces complexity.
Also, as a practical matter, the de/serialization time is negligible.
What is the benefit of having it like this rather than having the app use the same data interface as the api? It seems like more overhead (extra marshal & unmarshal) and added complexity on every web request.
—
Reply to this email directly or view it on GitHub.
Am I following this right?
The text was updated successfully, but these errors were encountered: