Winter release ❄️ (Clockwork 4.0)

[itsgoingd]

This is a meta issue for tracking progress on the next major release (Clockwork 4.0), scheduled roughly for early 2019.

Clockwork server-side

• 3.1 fix serialization of private properties from parent classes (different prefix)
• 3.1 make serialization configurable via config file in Laravel
• 3.1 filtered uris should not collect data at all, instead of just throwing it away on save (BR Memory exhausted in StackTrace.php:17 when request has large number of queries #278)
• 3.1 add support for click to open in text editor in stack traces (FR ide (VSCode, phpstorm..etc) uri scheme implementation clockwork-chrome#65)
• add support for performance logging (tagging log messages to appear in performance tab) (PR Added performance warnings to the "performance" tab underground-works/clockwork-app#5)
• add support for logging redis queries w/ timing (FR Show Redis commands and times #290, PR
  Added support for collecting Redis commands #311)
• collect dispatched queue jobs (PR Added support for collecting dispatched queue jobs #312)
• collect json request bodies (eg. api requests) (FR post param not recorded for axios request #267, PR
  Added support for collecting raw and json request data (body) #310)
• 3.1 collect authenticated user info (PR Added support for collecting authenticated user #296)
• add support for marking and reporting slow queries
• add n+1 query detection (PR Detecting duplicate (N+1) queries in Eloquent #317)
• make requests history searchable (PR Searchable requests history #318)
• add support for gzip compression for the file storage (PR Ability to compress metadata files #320)
  • Clockwork can easily collect up to 100M data for a request, simply gzipping the file reduces disk usage to less than 3M
• improve how storage filter works
  • currently we are always collecting all data and throwing away the unwanted data on save, we should never collect unwanted data to improve performance and memory usage
  • 3.0.1 view data is no longer collected with viewData filter (default)
• improve handling of large metadata, add hard-caps for the collected data size
• configurable stack traces (ignored vendor packages, last frames limit) (FR Make ignored packages for the stack traces configurable #306)
• 3.1 improve vanilla PHP usage (FR Vanilla PHP Response Resolution Problem #284, PR Improved vanilla support #291)
  • introduce a new facade-class for adding db queries, resolving metadata, sending headers etc.

Under consideration

• add support for an on-demand mode where Clockwork is active only when the extension is open (FR X-Clockwork-Requested-With header for lean usage clockwork-chrome#7)

Clockwork app

• move to a single repository for Chrome, Firefox extension and web UI since
  • the code is already the same except for a few different icons for Firefox
• 3.1 add better UI for HTTP 500 responses with easy access to the exception message, trace, etc. (PR Better exceptions UI clockwork-chrome#71, Improved logging of exceptions #297)
• add queue tab
• 3.1 show authenticated user info in the session tab (PR Show authenticated user in session tab clockwork-chrome#70)
• make requests history searchable (PR Searchable requests history underground-works/clockwork-app#6)
• add models tab as alternative to database tab more centred around models
• 3.1 add support for click to open in text editor in stack traces (FR ide (VSCode, phpstorm..etc) uri scheme implementation clockwork-chrome#65)
• fix opening the web UI before any metadata is available leads to a broken state (BR Clockwork with laravel REST Api  #307)
• add "copy query" button to database tab
• bundle the javascript
• vue.js rewrite

Under consideration

• add support for search via client ip ("show only my requests")
• hide clockwork dev tools tab when not used on the site (FR Hide Clockwork Tab clockwork-chrome#68)
• add request replay support
• add "response" tab for simple responses (FR Response Tab #127)

Meta

• clean up and open-source the website code
• create a clean test project for each supported framework version
  • end goal is to move to automated testing
• automated way to handle changelogs, releases and stuff

[fgilio]

The "on-demand mode" mode sounds nice, and "add request replay support" would be awesome.

Going to try out 3.0! Thanks for the update 😃

[L3o-pold]

An idea with the new multiple request feature is to have this information on the timeline of the main request.

[robclancy]

You need to check https://github.com/laravel/telescope. Anything it is tracking so can clockwork, and maybe even just be able to integrate etc.

[itsgoingd]

nice, was waiting for this to go public

so I've took a look and no surprises, it works in a pretty similar way to clockwork - listen to a bunch of framework events, store the data in a database and present it in an spa.

here are a couple of cool ideas I liked, some already on the todo list, some entirely fresh, that can make their way to clockwork in some form:

• searchable requests history (was always on todo list)
• authenticated user info (might combine with session tab)
• reporting and marking slow queries (already planned, but never got around to do this)
• models tab (kinda like an alternative to the database tab more centred around models)
• queue tab (a new callback for logging pushed queue jobs was added to laravel for telescope, was going to PR something similar, so this makes my work implementing queue tab much easier)
• notifications tab (kinda overlaps with emails tab, but laravel also has sms and all kinds of notifications)
• ability to specify a filter callback to log only certain kinds of requests (useful for profiling in production, tho it seems to have the same problem as clockwork where the data is already collected at the point where the filter is applied, so the overhead from profiling will always be there)
• pretty web ui? (the telescope ui is way more flashy, even when showing pretty much the same stuff)

[robclancy]

The thing I like about clockwork over telescope is that it is in the devtools. I don't want a whole tab dedicated to this. And also with clockwork you get requests just for that single tab whereas telescope is for all requests regardless of how they come in. This will be good for production (I would never run clockwork in production) but not as useful for development.

I'll be using both, clockwork for development/debugging and telescope for a more general overview of things and also will be useful for emails/notifications.

You can assume everyone who uses laravel will use telescope so it means some things it does better you can probably stop doing or integrate. For example your cache counts could link to telescopes cache page.

[Zolak94]

What about showing all triggered events? next to Session tab we would have Events where it will show all events triggered, and option to show more details about every event?

[itsgoingd]

@Zolak94 Hey, we actually already do, available since Clockwork 3.0. If your app dispatches custom events you should see an "events" tab including payloads and listeners for each event (framework events are filtered by default).

[StringKe]

hi,How do I view the parameters passed by the laravel blade? (view template data)

[itsgoingd]

@StringKe Hey, you can deploy the Clockwork config file and remove "viewData" form the "filter" setting. Now you should see a new "views" tab with all rendered views including view data. Note that this is turned off by default since it can be a lot of extra data to collect, depending on what you pass in to your views.

[StringKe]

@StringKe Hey, you can deploy the Clockwork config file and remove "viewData" form the "filter" setting. Now you should see a new "views" tab with all rendered views including view data. Note that this is turned off by default since it can be a lot of extra data to collect, depending on what you pass in to your views.

thinks