[Roadmap doc] - Redesign data storage - removal of Saved requests

[jarrodek]

This issue is a request for comment on redesigning data storage model and removal of "saved requests" list.

Background

Saved requests were created to allow freely store any arbitrary request in a main "saved" data store so it can be restored later. That was one of 3 ways of storing the data next to history view and projects.

Over time navigation in the application changed by adding a quick list of history/saved/projects and recently rest APIs menu has been added to the view.
After reviewing the design of the navigation and what we want to achieve in the future we have decided to remove saved section from the application.

Redesign

Right now navigation consist with 2 main sections of the application (HTTP request and Web socket) and 4 quick lists of saved/history/projects/Rest APIs. This navigation is inefficient as introduces to many options that can be confusing for new users.
Google Analytics data shows us that saved requests are used as often as the history. However difference of use of corresponding full screen versions of the lists is significant. This means that most of you use "saved" from the menu panel.
Navigation process can be optimized by reducing number of available panels and moving current saved requests to a "default" project. Change for the user is very little as the same goal can be achieved with other structure that already exists (projects list).

Data redesign

Current data model is focused around history and saved requests. Technically the only difference between two objects is the type (saved or history) and that saved can have a name and description. Projects are just a relation flag between saved requests.
In the future we are planning to focus data structure around projects and not the requests. Projects would become base organizational object for requests.
This would influence every data model in the application and thus export / import models. Naturally the application would support every previous data model and would transform it to a new data model during the import.

End user considerations

Migration to new data structure would be automatic for users who have saved requests not added to a project. The data would be moved to (probably) "Saved requests" default project.
After that there would be no option to save a request without a project name. By default project would be "Saved requests" project unless during the session other project was previously selected.

Navigation will be simplified by removing "saved" tab leaving only 3 options: history, projects, and REST APIs.

Time frame

Public notification of the change will be added to the application in July 2018. The data model won't change for at least next 3 months but it may take longer depending on the discussion and other factors.

We value your voice and we would like to know your opinion about planned changes. Leave a comment bellow and I will respond as soon as I can.

[ashishbodhale]

is there any way to recover the earlier stored requests? As I have no backup, it's very depressing to see all the saved request gone with the update

[jarrodek]

@ashishbodhale I am not sure what are you referring to. Nothing has changed yet. It's a design doc.

[dnut]

I think it's a good idea to base everything around projects. All requests should exist solely within a specific project, and your projects should be treated as totally independent from each other and saved to separate files. It would be nice to be able to save, load, clone, and close projects on an individual basis.

Some use cases I'm looking for are exporting a single project for people to test without having to share every project I ever worked on. Also, I'd like to clean up some of the projects cluttering my UI and only open them when I need them, or save one version with localhost and one version with qa or prod urls (as a sidenote it would be nice to have a master base URL for a project that you can edit once and it changes every request in that project). I've been struggling to find a way to delete a project, but if you make each project save to its own file, then you could just "close" it instead of deleting it from your profile where everything is currently managed as a whole.

Currently I meet my needs by editing the export JSON, cleaning out all my local user data for ARC, then restarting ARC and re-importing the JSON. I have one master JSON file with everything, plus I have some other JSON files with individual projects. It's kind of a pain to do this, especially since I have to manually delete all user data to delete projects, and all requests are saved outside projects making it hard to edit the JSON by hand.

[jarrodek]

@dnut Thank you for your use case. I will take it into the account when redesigning the model.

As for exporting/deleting, in the navigation you have an arrow pointing right, next to the project name. You can enter project page there and then you have more options like adding a description, deleting the project or exporting it to the file.

[jarrodek]

I just got a verbal feedback related to this matter.
Apparently folders in a project would be a nice to have feature after the redesign. I can understand the use case for the sub projects to reflect structure of the API.
I would, however, argue that this should be done in an API spec file and not in ARC. Unless ARC would provide a way to design API using one of the specs.

I see projects as a set of related requests that not necessarily make an API. It may or the API is being developed without the spec file. In this case sub-folders would be unnecessary complication that adds work to develop and maintain the app and then to the user to think about project's structure.

Instead I would prefer to suggest the users to use API designer (either the one offered by Mulesoft for free) or some ARC's version of an API designer to create more complex structure definition of an API.

Postman uses collections to keep API documentation in the collection declaration. I would do the same thing using ARC and API designer.

[ryanpcmcquen]

I like the idea of just tagging a request with a project, and then it being filed that way. I don't have a use case for the 'Saved' tab.

[sulu99]

I don't like the idea of having to save simple requests in a project. It doesn't fit with the usual scenario, in my case. Just my two cents. -Su

[jarrodek]

Hi @sulu99
What is your use case if you don't mind asking? Would a "Default" project be a solution for you? I mean by default a request would be added to a project that is called default (or whatever). Since projects are just tags on a request object it either have a tag or not.
The reason for the removal would be simplifying the navigation that grew over time. But I would really like to hear more about your use case.

[ryanpcmcquen]

I think the 'Default' project offers a nice migration from the current workflow.

[akornilkov]

So, about 'saved': In earlier version I had had troubles using it, because of imposibility of loading saved requests. Now, your app improved those interface and I like it.
'Projects' is the best. I think it is necessary to move saved to Projects and 'saving Projects to files' operation have to add all its requests like an json-array

[domints]

So yeah, today I came to see your update. I am not sure what happened and where my requests were saved before. I had them grouped into projects and well, today I open ARC to not finding any of my requests. Where are they gone?

[jarrodek]

@domints were you upgrading from Chrome application to Desktop client? In this case you need to move data manually as there's no way to access protected data in Chrome. Otherwise please tell me from which version were you upgrading to which version.

[domints]

I didn’t upgrade anything on my own. I just open app once in a time and it is different than the last time and now it lost all my data. W dniu wt., 15.10.2019 o 21:40 Paweł Psztyć <notifications@github.com> napisał(a):

…

@domints <https://github.com/domints> were you upgrading from Chrome application to Desktop client? In this case you need to move data manually as there's no way to access protected data in Chrome. Otherwise please tell me from which version were you upgrading to which version. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#80?email_source=notifications&email_token=AAILTYMHHR236Y2FLF2OWV3QOYMELA5CNFSM4FGSTFQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBJ7GSA#issuecomment-542372680>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAILTYLVFA76RCVMECVHGFDQOYMELANCNFSM4FGSTFQA> .

[jarrodek]

@domints could you please file an issue report about that? Including your current version number? It may affect other people and I would like to take a look into this before next release.

[jarrodek]

I would like to redirect this discussion here: #434
In this discussion I am describing how I am planning to change ARC projects and "saved". This is already a work in progress though, it will take weeks before it's ready.

[jarrodek]

Furthermore, the following issue #435 replaces this one. Thank you all for different point of views. I believe I am applying all of them in the new concept of projects.