glimpse / home Goto Github PK
View Code? Open in Web Editor NEWProject Glimpse: Node Edition - Spend less time debugging and more time developing.
Home Page: http://node.getglimpse.com
License: Other
Project Glimpse: Node Edition - Spend less time debugging and more time developing.
Home Page: http://node.getglimpse.com
License: Other
When getting to Glimpse using following url:
localhost:3000/glimpse/client/?baseUrl=/glimpse/client
Metadata server prompted twice? shouldn't it only prompt once?
This is a pretty minor issue, but since error messages display the red icon, it would be great if users could visually scan their logs for issues, without seeing any false negatives.
Repro steps:
console.trace
into your appLogs
tabExpected: To see the call to console.trace
, displayed as an informational message
Actual: The trace call shows up, but it is labeled as an error.
We're sorry to hear you're having an issue.
We're going to do everything we can to make it right, but to be most helpful, we'd really like for you to include the following in your issue report:
Please delete this boilerplate text before you hit the "Submit New Issue" button.
Requests on Glimpse Client hosted on Azure doesn't get update in real time. Please take a look into this.
Most of the time that I'm using the client, I want to inspect the most recently made request, so it would be a small, but nice experience to have the UI auto-select the first request for me. This behavior would also likely help the first impression of the tool, by populating the UI with data, instead of just seeing a mostly blank screen.
Ideally, we could add the same behavior to all master/detail views (e.g. the Data
tab) as well, to provide a consistent experience that makes navigating around the UI "feel" a little smoother. When we added this feature to many of the F12 tools (as applicable), we were surprised how it impacted people's perception of the product, especially on first load.
node v6.5.0 on OSX
When I start my express app and load the first page I see this glimpse error:
Glimpse (101): Glimpse unexpected context value at location ExpressInspectorActionRouteView::onResponseRender(). Expecting context ID 72dd251077cf11e6a780919d90438b54. Actual context ID is undefined
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onRenderComplete()
Glimpse (101): Glimpse unexpected context value at location ExpressInspectorActionRouteView::onResponseSend(). Expecting context ID 72dd251077cf11e6a780919d90438b54. Actual context ID is undefined
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onRenderCompleteError()
{"time":"2016-09-11T03:25:55.419Z","hostname":"avi","pid":9878,"level":"error","name":"mjournal","message":"express error handler middleware","err":{"name":"TypeError","message":"Cannot read property 'hudScriptTemplate' of undefined","stack":"TypeError: Cannot read property 'hudScriptTemplate' of undefined\n at ScriptManager.hudScript (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/messaging/ScriptManager.js:28:42)\n at ScriptManager.getScriptTagsForCurrentRequest (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/messaging/ScriptManager.js:45:21)\n at ExpressInspectorActionRouteView.onResponseSend (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/inspectors/ExpressInspectorActionRouteView.js:204:50)\n at Object.listener (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/inspectors/ExpressInspectorActionRouteView.js:26:19)\n at Tracing.publish (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/tracing/Tracing.js:30:26)\n at ServerResponse.sendResponse [as send] (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:61:35)\n at done (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:104:22)\n at onRenderComplete (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:88:13)\n at Object.exports.renderFile (/Users/plyons/projects/mjournal/node_modules/pug/lib/index.js:405:12)\n at View.exports.__express [as engine] (/Users/plyons/projects/mjournal/node_modules/pug/lib/index.js:448:11)\n at View.render [as originalRender] (/Users/plyons/projects/mjournal/node_modules/express/lib/view.js:126:8)\n at View.viewRender [as render] (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:28:31)\n at tryRender (/Users/plyons/projects/mjournal/node_modules/express/lib/application.js:639:10)\n at EventEmitter.render (/Users/plyons/projects/mjournal/node_modules/express/lib/application.js:591:3)\n at ServerResponse.render (/Users/plyons/projects/mjournal/node_modules/express/lib/response.js:961:7)\n at ServerResponse.renderResponse [as render] (/Users/plyons/projects/mjournal/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:52:35)"}}
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
GET /glimpse/hud/main.js?hash={hash} 200 516.763 ms - 554299
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
GET /glimpse/agent/agent.js?hash={hash} 200 4.381 ms - 54744
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseSend()
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
GET /glimpse/context/?contextId=72dd251077cf11e6a780919d90438b54&types=environment,user-identification,web-response,web-request,after-action-invoked,after-action-view-invoked,before-execute-command,after-execute-command,after-view-component 200 1.461 ms - 5418
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
GET /glimpse/hud/assets/glimpse-logo.png 200 0.961 ms - 810
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
GET /glimpse/hud/assets/selawk.woff2 200 0.839 ms - 14632
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseSend()
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
POST /glimpse/message-ingress/ 202 16.843 ms - 8
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseSend()
Glimpse (100): Glimpse was unable to retrieve the context associated with a request at location ExpressInspectorActionRouteView::onResponseEnd()
POST /glimpse/message-ingress/ 202 1.189 ms - 8
If I reload the page, the app starts working correctly. This only seems to happen on the first request after app startup. The glimpse HUD is visible on the page and otherwise seems to be working.
I'm sure this is already planned for accessibility/etc., but as a "keyboard-preferred" user, I just wanted to log the request to be able to fully navigate the UI via the keyboard. For my use-cases (and many of users), this would dramatically improve the usability. As a data point, this is actually one area where we "won" over some users to F12, because our tools were much more keyboard friendly than Chrome's were at one point. They've improved this significantly, so I'm not suggesting that it's a differentiating point, but it became very clear to us from working with many devs that keyboard nav is a not just a valuable feature, but a "table stakes" experience that is expected by many users.
For requests/responses with a decent number of cookies being transmitted, it can be tricky to parse the key-value pairs when reading it as a single line. It would be awesome to have a structured visualization of this data, that was sortable by name. I'm sure this is on the backlog, so I just wanted to log it as part of my first-experience usage.
You guys already provide a richer view of form data and query strings, so having a better way to view cookies would help "complete" the core experience for profiling requests/responses in a way that many folks may be familiar with from other tools.
When I have a lot of requests in the left panel, I found myself spending a lot of time looking through each one to see which one I should be investigating. This is not very helpful.
After discussing with Phil, I would like to purpose a simple way to get around this problem:
1.2. Add error/warning icon in front of status number. This will base on status code semantic (for example, 404 = error) as well as what's being generated in logs tab. For example, GET 200 is not an error but there is an error message in the logs tab for the associated request, therefore warning icon appear next to the GET 200 status code. We can limit this behavior to only warning and error.
In order to spot potential performance optimizations, it would be pretty awesome to see whether a database call was using an efficient index or not, based on seeing the difference between the number of documents returned and the number of documents scanned. This may be a little low level, but it seems like folks use the explain
method to help identify these kinds of opportunities "manually", so having Glimpse do it for you could be pretty cool. That way, you're not just relying on the duration of the database call to know if its efficient.
Data filtering is always tricky, so I'm not sure if this is even the right decision, but it seems somewhat strange to see a cookie and response header in each request entry, that were introduced because of Glimpse. We did a lot of filtering in the F12 network tool, because we wanted to prevent the "observer effect" as much as possible, but I'm not sure whether that is a goal of yours. On one side, you can optimize for accuracy, ala Fiddler, and display the actual over-the-wire request/response, but I can't help but feel like Glimpse wants to be optimized for intuition/simplicity/etc., and therefore, stripping out stuff like this could be valuable to prevent unnecessary clutter.
I think this is pretty low-pri, but I just wanted to log it, since when we worked on the F12 profilers, we tended to err on the side of data filtering in order to project the most curated experience as possible, that was still actionable. For data that isn't important to end-users, we tried to remove it as much as possible.
"Date" in overview section only shows time. Please take a look into this.
Log messages are expandable when their content represents an object, however, if the content is a string with newlines in it (e.g. a stack), then there doesn't appear to be any support for this, which makes it hard to parse. For example, if you run a failing assert (or console.trace
), that will generate a stack log, which Glimpse displays, however, its pretty unreadable:
If you look at the contents of this string within the DOM, it has the expected newlines, but those aren't being correctly handled in the UI in order to make the data more easily readable.
In /create/api/search request
There is no web services information shown but the header shows "1 request"? Shouldn't this be at "0 request"?
Glimpse did a really great job capturing logs messages, however, I was left wondering of what to do next with that information ... It would be super helpful if we can allow users to click/hover on the logs message, errors logs message for example, and link back to the exact line of code that it came from.
This way, we truly are helping our users to do their job better.
I wasn't able to figure out how to get this to display in the UI, so maybe I missed it, but it would be handy to understand which middleware are attempting to change the response status code via the res.status
or res.statusCode
methods.
Repro Steps:
Expected: To be navigated to the exact request that the URL points to
Actual: I get the following error, and have to navigate back to /glimpse/client
and find the request again (in Chrome).
Cannot GET /glimpse/client/requests/fcbd12807b6d11e6bf4e5b3990f7f65f/request?requestAxis=headers&responseAxis=headers
Note: I can repro this issue by simply refreshing the browser tab when a request is selected, so the bug doesn't appear to be restricted to a new tab.
Update (9/15/2016 - 4:48 PM): I updated to the new glimpse-node
umbrella package, and the NaN
issue displayed below is fixed, but I still don't see the actual service call in the list.
Repro steps:
http.get
(or http.request
, or any "higher-level" library which uses them under the covers) within one of your app's routes.Web Services
tabExpected: To see the get request
Actual: The get request isn't displayed, however, the heading bar displays "1 Requests".
If I open up the dev tools, I can see an error logged that may be the source of the issue, so this may not be specific to http.get
, but rather, simply an issue with the web services UI in general.
Repro steps:
Data
tabExpected: To see the data that was inserted or deleted from the DB
Actual: The Command
section is empty.
The logs feature works great for me, but there are a few things about the UI filters that I'm unclear about:
console.*
method or something else? I wasn't able to figure out how to get it to do anything.Debug
relevant? I know that the browser has a console.debug
, but I had thought this wasn't available in Node? When I tried doing a console.debug
, it doesn't seem to work. Is this there specifically for client-side logs? Would it make sense to hide this filter if there aren't any client-side logs? Maybe it doesn't matter, but I just wonder whether a Node dev would find this odd. Additionally, even in the browser, I believe that console.debug
may be an alias for console.log
, and I'm not sure how commonly used it is, so I'm curious if there's that much value it provides in general.console.log
, which I think is the standard logging mechanism, and I'm not sure whether it would be considered a "verbose mode" or not. If anything, console.debug
would seem more akin to what is traditionally thought of as "verbose data", but as #2 mentioned, this isn't even available in Node. Chrome calls this "Logs" and F12 calls this "Messages", both of which I feel like are better than "Verbose". This is obviously hugely nit-picky, so take it with a grain of salt :)console.assert
calls are labeled as "Errors", which is probably fine, but kind of strange, since as mentioned above, there are already filters for methods which are simply aliases (e.g. console.debug
), as well as potentially unused for Node (e.g. "Critical"), so not having a dedicated filter for a first-class type of console message seems somewhat inconsistent, but not really a big deal.console.time
/ console.timeEnd
pairs show up as "Verbose"? Maybe the verbose category is the catch-all? If so, then I suppose my comment #3 can be disregarded, but it would be cool to have some kind of tooltip/indication as to what "Verbose" represents.In general, it would be awesome if the filter buttons had tooltips or something which articulated what they actually mapped to from a code-perspective, that way I could rationalize the functionality quickly.
Using the Node glimpse on my local machine I am getting the following error the first time a request executes (so not on start up but when I hit a route):
Tue, 13 Sep 2016 23:59:38 GMT morgan deprecated default format: use combined format at node_modules/lodash/lodash.js:12282:42
(node) warning: possible EventEmitter memory leak detected. 11 finish listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
at ServerResponse.addListener (events.js:239:17)
at ServerResponse.wrappedTransition [as on] (/Users/admin/opensource/ospo-opensource/node_modules/@glimpse/glimpse-node-agent/release/async-track/async-track.js:412:40)
at ServerResponse.on (/Users/admin/opensource/ospo-opensource/node_modules/compression/index.js:120:20)
at Function.MiddlewareWrapper.wrapCommonMiddleware (/Users/admin/opensource/ospo-opensource/node_modules/@glimpse/glimpse-node-agent/release/inspectors/util/MiddlewareWrapper.js:103:13)
at wrappedMiddleware (/Users/admin/opensource/ospo-opensource/node_modules/@glimpse/glimpse-node-agent/release/inspectors/util/MiddlewareWrapper.js:152:31)
at Layer.handle [as handle_request] (/Users/admin/opensource/ospo-opensource/node_modules/express/lib/router/layer.js:95:5)
at next (/Users/admin/opensource/ospo-opensource/node_modules/express/lib/router/route.js:131:13)
at Route.dispatch (/Users/admin/opensource/ospo-opensource/node_modules/express/lib/router/route.js:112:3)
at Route.dispatchRoute (/Users/admin/opensource/ospo-opensource/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:17:29)
at Route.dispatchRoute [as dispatch] (/Users/admin/opensource/ospo-opensource/node_modules/@glimpse/glimpse-node-agent/release/tracing/proxies/ExpressProxyActionRouteView.js:17:29)
(node) warning: possible EventEmitter memory leak detected. 11 headers listeners added. Use emitter.setMaxListeners() to increase limit.
I am bootstrapping from bin/www in express before any other requires run.
Node version is 4.4.7
Code appears to still work, but Glimpse doesn't fully load. I get the g
icon but the rest of the bar is not there. I can click the icon and get the profiler.
Let me know what you would like me to do for further troubleshooting.
Edge:
I'm probably just used to having used Fiddler, Chrome DevTools and the Edge DevTools, etc. but I found it a little odd at first that the request list is sorted descending. This was particularly confusing when a request was made as a result of a redirect, and I found it kind of unnatural to read the flow of requests bottom up.
I'm not sure I would recommend changing the default behavior (despite there being a decent amount of prior art/precendence), but it would be awesome to be able to at least change the sort direction for folks that may find it more intutuive to read the flow of requests top down as opposed to bottom up.
We are currently showing only logs messages that associated with a request. I found myself using logs messages to see if my simple node app is hooked up with NodeJS correctly. The only way for me to see that log message right now is through command line. Would it be beneficial to show this information as well?
Currently when there is nothing found in Request body/ Response body nothing shows up. We can show simple messages saying "No body response found" etc.
This behavior should also applied in other places in the platform where we cannot generate information.
In practice, I believe most devs would use console.log
, since that provides the same kind of behavior as console.dir
does (at least in most tools), however, there are apps that may be using console.dir
from a historical perspective, and so it would be ideal if Glimpse displayed them as part of supporting the standard console API.
In my super basic node application, a request was successfully executed. Texts were visible in the browser but Glimpse client did not show anything in response body tab. Here's my code for this section:
app.get('/chet', function (req, res) {
res.send('Hello Chet!' + '<html><head>HUD Test</head><body>This is a HUD test</body></html>');
console.log("NodeJs Works");
});
In the Debug tab, here's the message for web-response:
{
"url": "http://localhost:3333/chet",
"headers": {
"x-glimpse-contextid": [
"4a817b306fcc11e6ac0b41de37da9755"
],
"x-powered-by": [
"Express"
],
"content-type": [
"text/html; charset=utf-8"
],
"content-length": [
"772"
],
"etag": [
"W/\"304-qBlMEO+qGD9duB+6/uFbPQ\""
]
},
"statusCode": 200,
"duration": 4.795834,
"endTime": "2016-08-31T15:43:09.544-0700",
"body": {
"size": 0,
"encoding": "utf8",
"content": ""
}
}
"content" doesn't seem to capture any value. Please take a look into this.
Repro steps:
{ foo: { bar: { baz: 23 } }
).Log
sub tabMessage
columnExpected: To be able to continue expanding the subsequent "levels" of the object hierarchy
Actual: It appears to only allow expanding/collapsing the object's root level members, and then displays everything else inline, which could get hard to read if object's were logged as a result of web service calls/etc.
Awesome object visualizations was a big point of feedback when we worked on the F12 side, and is something that Chrome has done really well. This isn't super high pri, but it would be a nice-to-have for sure.
Repro steps:
Expected: To see the Query/Count
metric reflect the single Mongo call and its duration.
Actual: The metric simply displays 0ms / 0
If I select the Data
sub-tab, I do in fact see the Mongo call and its duration, so it just seems to be an issue with the request metric in its summary pane. Apologies if I'm misinterpreting what this metric is meant to represent.
It's awesome that Glimpse displays console.time
/console.timeEnd
intervals (I was so happy to see this!). However, there are a few things which I found somewhat strange about the way they're currently displayed:
From Start
or Duration
columns are populated, which would actually be very useful, particularly for custom time interval entries. The duration is displayed in the log message, so this isn't a blocker, but it's generally easier to read structured data in a tabular format (for me at least), instead of needing to parse the message content for relevant data.console.timeEnd
was), but in general, the mismatch between individual messages and intervals isn't completely ideal.In practice, neither of these suggestions may actually matter to users, but I just thought I would throw it out there.
Update (4:01 PM 9/19/2016) - This same issue impacts the res.links
method as well, and has the same odd display as the res.cookie
method.
Repro steps:
res.cookie("foo", "bar")
)Expected: To see the cookie as being set from both middleware
Actual: Glimpse shows the later middleware as having set the cookie twice, and it crosses out the cookie being set from the previous middleware. Since both cookies are being sent across the wire, I don't know if it makes sense to cross one of them out. And the fact that the later middleware is depicted as having set the cookie twice seems misleading.
Repro steps:
Expected: To see the list of requests
Actual: The client UI appears, but the request list is empty
The client works perfectly in Chrome, so the issue appears to be limited to IE/Edge. When I open up the dev tools, there is an error in the console, so maybe the databinding logic doesn't work currently in IE/Edge?
Repro Steps:
Web Services
tabExpected: To see the list of web service calls
Actual: I get a React red screen of death
Interestingly, I don't get this if a request only made one web service call. However #26 occurs in that instance.
In /create/api/search request
When there is no timing information in web services tab, it shouldn't show "(NaN ms)" next to the page header.
Repro Steps:
Expected: To see a Connection
and Date
header, which confirmed in both Chrome DevTools are Fiddler are actually present present.
Actual: Every request and response header is correctly displayed, except for the Connection
and Date
response headers.
This is a pretty low-priority bug from my perspective, but I was confused when I didn't see these headers in Glimpse, and so I jumped to other tools to confirm. When I had worked on the F12 network tool, we had a lot of customers that would "cross check" us against Chrome and Fiddler to gain confidence in the data, so these kinds of mismatches can be meaningful sometimes to try to address.
Environment:
There is currently no hover functionality in the platform. Please take a look into this.
After using Glimpse a little bit over the last couple of days, I keep finding it somewhat disorienting that it doesn't display static assets anywhere. I really like the "focused" view that Glimpse is providing, but if a Node server is setup to actually receive and serve static assets (as opposed to delegating that to a reverse proxy such as nginx), then it seems a little odd (for me at least) for that traffic to be entirely omitted from the UI. I think I agree with not showing these requests by default, but I can't help but feel like it would be valuable to allow the end-user to choose to see them somewhere, if for nothing else than to be able to "cross check" what the tool is showing them, and feel comfortable with the data.
When we re-built the network tool in F12, we had a lot of users compare us against Fiddler or Chrome's network tool, and I suspect that Glimpse might receive similar comparisons. The lack of static assets is definitely an obvious divergence.
Personally, I think it would be pretty awesome if static assets were displayed either as child rows within the request list (if that list was turned into a tree), or if there was a new tab added to the request details page that displayed the child requests that were made as a result of it. I may be alone in wanting to see this, based on having used traditional web tools for a long time, but I just wanted to log this perspective as a first-time user.
After installing the latest Mongoose, as well as Glimpse Node package, the following two logs show up in nearly all of my requests:
Neither of these are actionable for the user, so its unfortunate that the logs list could potentially get cluttered with noise, and it could be hard to know which ones represent user code or not. Having stacks for each message would be cool, but it would also be nice to just be able to completely filter out logs that came from non-user code, almost like a "just my code" for log messages.
I haven't been able to determine when and why the Network
, Server
and Client
metrics appear in the summary for a request when selecting it. Are these expected to always show up? Is there a specific attribute of a request that causes it to have this data? Apologies if this is cluttering up the issues, but I figured I would log this question in case its a bug that this data doesn't seem to consistently or reliably display.
I tried to get Glimpse running on my node application for the first time but had trouble seeing Glimpse client using the following Url:
localhost:3000/glimpse/client
After several tried, a new url that finally works was
localhost:3000/glimpse/client/?baseUrl=/glimpse/client
Please take a look into it. Thanks.
In order to reduce noise and better orient myself when viewing profiling data, its really valuable to be able to clear past data, particularly if I'm not interested in any of the historical requests. There's something physiologically valuable to knowing that everything being displayed is relevant to my current needs.
I was able to work around this by simply cycling the server, but it would be awesome to be able to clear the request list within the UI. When we did the network and performance tools in F12, this was a really common request, particularly because many similar tools provide this option for the workflow style that I mentioned above.
Navigating to /glimpse/client/?baseUrl=/glimpse/client
appears to do nothing in Safari. You will be prompted (once) to select the metadata URI, but using the default does not result in a page being shown. The console window shows the following error:
[Warning] Invalid CSS property declaration at: ; (main.css, line 920)
[Error] TypeError: window.fetch is not a function. (In 'window.fetch(metadataUri)', 'window.fetch' is undefined)
(anonymous function)
(anonymous function)
(anonymous function)
onEnter
(anonymous function)
(anonymous function)
(anonymous function)
next
loopAsync
runTransitionHooks
runEnterHooks
(anonymous function)
runTransitionHooks
runChangeHooks
finishMatch
(anonymous function)
next
loopAsync
matchRoutes
match
(anonymous function)
listen
listen
Router_componentWillMount
performInitialMount
mountComponent
mountComponent
performInitialMount
mountComponent
mountComponent
performInitialMount
mountComponent
mountComponent
performInitialMount
mountComponent
mountComponent
mountComponentIntoNode
perform
batchedMountComponentIntoNode
perform
batchedUpdates
batchedUpdates
_renderNewRootComponent
_renderSubtreeIntoContainer
render
render
eval code
eval
(anonymous function) (bundle.js:59)
__webpack_require__ (bundle.js:20)
eval code
eval
(anonymous function) (bundle.js:50)
__webpack_require__ (bundle.js:20)
(anonymous function) (bundle.js:40)
global code (bundle.js:41)
I'm not even sure whether what Glimpse already shows for Mongo operations isn't sufficient, but I couldn't help but wonder whether the difference between Mongoose code and the underlying MongoDB protocol operation couldn't be confusing (or at least non-ideal) for some users. For example, in my app, I have the following code:
Todo.find({ user_id : user_id }).sort( '-updated_at' )
Which translates into the following within Glimpse:
{ "find": "admin.todos", "limit": 0, "skip": 0, "query": { "user_id": "2YgMPUBERMIRrRyYLWQLfbMFBNb7YolP" }, "sort": { "updated_at": -1 }, "slaveOk": false }
It's pretty straight forward to map between the two, but you'll notice that the syntax for specifying sort direction is different, the query is targeting the "raw" collection as opposed to my model object (Todo
), and I didn't specify any paging, so seeing the limit
and skip
fields may seem superfluous.
In practice, this might not be a big deal at all, but since we're generally striving to provide an app-specific view of execution, in a way that is as semantically rich and as close to what developer's are familiar with as possible, it seems worth investigating whether doing something to light up Mongoose-based apps would be valuable for folks or not.
Most web devs probably know what a 200
, 404
, 500
etc. are, but the distinction between a 301
and 304
can be subtle for folks, and so displaying the "friendly name" in addition to just the actual status code can be pretty helpful (e.g. Moved Permanently
vs. Not Modified
).
This is definitely a nice-to-have, but it was something we did in the F12 network tool based on feedback, and we found it to be a simple improvement, somewhat similarly to how the Glimpse client displays a "friendly name" for well known middleware.
The Glimpse Client shows error when selecting Web Services tab:
TypeError: Cannot read property 'duration' of undefined
eval
/Users/avanderhoorn/Projects/Glimpse.Client.Strawman/src/client/routes/requests/details/service/ServiceView.tsx
Array.forEach
(native)
ServiceTab.getMinMaxTime
webpack:///./src/client/routes/requests/details/service/ServiceView.tsx?:414:23
ServiceTab.getHeaderText
webpack:///./src/client/routes/requests/details/service/ServiceView.tsx?:301:39
ServiceTab.renderMaster
webpack:///./src/client/routes/requests/details/service/ServiceView.tsx?:109:26
ServiceTab.render
webpack:///./src/client/routes/requests/details/service/ServiceView.tsx?:94:22
ServiceTab.tryRender
webpack:///./~/react-transform-catch-errors/lib/index.js?:34:31
ReactCompositeComponentWrapper._renderValidatedComponentWithoutOwnerOrContext
webpack:///./~/react/lib/ReactCompositeComponent.js?:785:34
ReactCompositeComponentWrapper._renderValidatedComponent
webpack:///./~/react/lib/ReactCompositeComponent.js?:811:32
ReactCompositeComponentWrapper.performInitialMount
webpack:///./~/react/lib/ReactCompositeComponent.js?:353:30
This application makes a large number of web service calls. The Debug tab appears to show the responses containing a duration
property.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.