Graphiti comes with a debugger that shows the queries executed for a
given request. Remember that Resources have a query interface independent of a request or response. And Resources connect similar to ActiveRecord’s
Remember, this is all customizable.
That means we can log the requests made by individual Resources:
And even copy/paste these queries into a console session to debug:
If you’re having trouble with a request, see if you can isolate to a specific Resource, then test that Resource directly.
Finally: if an error occurs, we’ll note the query that caused it:
It can be helpful to have this debug output come back as part of the JSON response. To enable this:
And request the debug output:
You should now see the debug output in
If there’s an error, and you’ve enabled raw errors, you’ll also see the query that caused the error in the JSON response:
By default, we’ll log to
Rails.logger, and only enable debugging (logs
or JSON) when
Rails.logger.level is set to
debug. Here are the
various ways to configure.
config.debug to explicitly toggle debugging:
config.debug_models to get additional (but verbose) output:
As noted above,
allow_graphiti_debug_json? must return
true if you
want JSON output:
Note you need to explicitly pass
?debug=true in the request.
Assign a different logger:
Manually apply the debugging (when using Rails, this normally happens in
2 Rake Tasks
There are some common debugging scenarios that are possible to do manually, but their frequency warrants common patterns. For these, we have rake tasks.
Execute a request using
underlies request specs).
This can be helpful when you don’t have, or don’t want to spin up, a web server. Imagine you want to debug something on production, so you shell into a docker container and edit some files locally. Now you want to execute a request and see if your changes worked:
Will execute the request and spit out the JSON response. You may want to run with the Debugger enabled:
Which add Debugger output as well.
PATH should not contain the domain unless you want to hit a live
API instead of a test server.
It can be helpful to run a quick benchmark without hitting a live web server, to eliminate the vagaries of latency. To do this:
Which will return the average response time.
When debugging an application, try to isolate the individual Resource call and debug the Resource directly (instead of running the entire request). This helps eliminate variables, and plain ruby code is easier to work with. If possible, try to remove Graphiti entirely and focus on your Models and Backends.
The most common scenario is debugging a query. We suggest overriding
resolve and using pry (or equivalent):