ARC version 8

Recently I've published an update to the beta channel of the Advanced REST Client. It is a version 8 of the app.

This update introduce many changes in the background so it is a starting point for father development.

Database structure

First of all the database structure completely changed. Old database and data in it are intact and will just stay there for some time. At leat until I'm sure that everyone migrated the app to new structure.

The app has migrated to use PouchDB as a wrapped for IndexedDB. It gives powerful options especially in terms of data integrity management (thanks to its revision system) and synchronizations with external databases (which is not yet in the app but it's in the roadmap).

But the man reason for database structure change was performance. Previously, when querying the history data to build a listing view it was getting out all objects from the datastore (yes, every request object with it's history of calls which includes request and response data) just to show time, name and method. It was very inefficient and was slowing down the app drastically.
New database structure is more complex and is using different databases for each object type but it makes performance much better.

History analysis

When you making a request the response is saved to the database. So far it was never used and I had an issue on issue tracker marked as "do something with it in the future". So finally I did something with it.
When you open a request (from history or from saved data) or just enter an URL a new process will start and will search the database for history of requests made to this endpoint. A small button in the bottom right of the app appear when data are available to open data explorer.

This data explorer shows charts for:

Time data

• Response time as an overall time need to perform full request cycle
• Connection time - time needed to to make a connection to remote server
• SSL negotiation time (only for https endpoints) as a time needed for SSL negotiation
• Message sent time - a number of milliseconds needed to  transport headers and request body to the remote machine
• Time to first byte - as a time between finished sending a message and receiving first bytes of data. You can say is that it is a server request process time
• Data receive time which is a time measured since first byte arrives until connection was closed or last message byte was read.

All times are in milliseconds. Note that this data are not available for "XHR requests" (if you use this option to make a connection).

Size data

• Request headers size - size of the HTTP message (headers part) sent to the server
• Request payload size - size of the body data send to the server. This data are not available for GET and  HEAD requests
• Response headers and response payload size - similar to above but as the data received from the server.

Both size and time data has calculated median for each chart so you can see what's abnormal and when did it happened.

Last chart is a histogram of the response status codes. It shows how reliable the endpoint is in a reference to responding the same way all the time.

Other changes

Projects in form as they are right now are now deprecated. New projects will be implemented in next release. You can check out this prototype to see proof of concept of the new app.

The app now have a status bar. Besides actions for data explorer and other planned actions it also contains a status message for the request. You normally won't need it. But when the connection or server is really slow you'll see at which part of the request the process slows.

If you are using ARC exported files in some other way than importing it back to the app you'll have a problem because file structure has changed.

CTRL/COMMAND + S shortcut saves current request in the database by default without showing save dialog.  At least if the request was previously saved. You need to click on the save icon on the top bar or use CTRL/COMMAND+SHIFT+S to open "save as" dialog.

Rest of the changes are minor bug fixes reported by the users. Issue tracker is the fastest way to stay in contact and request a feature or file a bug report. I check if even more often that an email.

Beta trials will end in coming days (depends on if I or anyone find a really annoying bug) and then the update will be pushed to the stable channel.