Brainstorming on persisting the requests

[kannananil]

This is a discussion thread to brainstorm on the initial ideas on persisting the requests and related data of req.io so that users would be able to come back and utilise the same requests even after closing the application. (This is different from the short time runtime state management that could be done via redux or similar frameworks which is yet to be implemented)

Instead of over complicating things by involving our usual concepts like collections, environments etc which we used to follow in all the main http clients we have seen. These extended concepts like collections, folders, nested folders, environments etc can be brought going forward in future.

We will start of with a simple scratchpad this acts as a collection of all the requests a user holds. This data for the scratchpad will be stored within the users machines storage as normal file structure with each file mapped to each request. The path for this scratch pad will be by default configured in an env variable for the application to utilise something like $HOME/.reqio/scratchpad which can be made configurable for users through our application UI itself or via updating the env variable.

Our intent is to make this request file simpler in structure, easily accessible and understandable. We could potentially follow any standard and simpler structures which follows json or yaml approach(or could come up with our own structure too if necessary)

@keerthanak-tw and @Pravithaop share your thoughts

[kannananil]

Attaching two example structure of the request file structure to demonstrate the idea clearly

POST request

name: Add an expense
type: request
method: POST
url: http://expensetracker.io/expense
body:
  {
    "title": "Train ticket",
    "category": "tavel",
    "amount": 456.30
    "date": "24/10/2023"
  }
headers:
  - key: Content-Type
    value: application/json
  - key: x-api-key
    value: abcdefg

GET request

name: Get travel expenses
type: request
method: GET
url: http://expensetracker.io/expense
headers:
  - key: Content-Type
    value: application/json
  - key: x-api-key
    value: abcdefg
query:
  - key: category
    value: travel

[keerthanak-tw]

From what I am understanding, for such desktop apps, it might make sense to store it local disk itself. If user wants to share, they have to export it (for which our app should support) and then import it. The idea of accounts come up when user doesn't want to do this export/import.

This was something I saw in an article - https://www.electronjs.org/docs/latest/api/safe-storage. Similarly there is also electron-store and other packages like this which will abstract the read/write operations for us.

Maybe this blog might also be of some use. It explains how to store user data in electron apps. We can extend this to store application data.

[kannananil]

Yes what you mentioned makes sense, for now the storage will be completely on the users local machine and when we introduce the concept of account it can have features like cloud sync.
Regarding sharing the collections exporting is one way, but as we are keeping the request files in an accessible folder of default path/or users choice and the files are in a readable format even the users could choose to commit those to any version control tools like github or gitlab(Definitely need to think about the sensitive informations in those scenarios and how to exclude them)

The blogs you shared are really helpful will go through them and can have further discussions on the options.
Thanks for sharing your thoughts :)