Research some UI designs for query builder

[ZiyedB]

A simple example is this :

We could integrate cool other ones ( depending on the need for PQL ). We need to define some spec. Let's use this ticket for this

[Netherdrake]

I'm a big fan of query builder inside of https://www.metabase.com/

They give you the ability to see intermediate steps which makes it easy to create/debug a multi-step pipeline like that found in PQL.

[jbargu]

Snippets could be a very useful feature here. We could code in some of the most used snippets, e.g. 'Add Bitcoin price from CoinGecko', 'Add Bitcoin price from CoinBase', which could be browsed/searched through.

In the case of editing JSON in the editor we can export the JSON schema from the backend and validate PQL in the editor on the go. This is already supported by the current Ace editor. Probably could also be used in the query builder setting to validate the input.

[Frenkiee]

What about that we go totally without JSON editing and fully UX PQL building - like it is introduced in Metabase (https://www.metabase.com/). What I like about their product is the right-side nav in which the user configures the next step of a process. What I would suggest is to keep the right-side nav and as his core use the PQL process (like shown in the picture). It would allow the user to interactively view the intermediate results just by clicking on one any process component. But by clicking on the run button (or final process component) full process would be run.

To break it down a bit we would have the next groups in the process:

• Load: each new loader opens up a new pipeline in PQL and is crucial in the process,
• Operations: After the load, the user can apply operations over data,
• Aggregation: Aggregate the results of pipelines. Note for BE I would recommend moving aggregation into the pipeline, this way the user could do aggregations, and after it applies additional operations <- currently I don't think this is possible,
• Validate: TBC,
• Callback: TBC,
• onError: TBC.

One awesome thing to have would be draggable operations in the PQL process. Let's use https://github.com/atlassian/react-beautiful-dnd library where the Droppable components would be PQL pipelines and the items would be Draggable. With the current PQL scheme Load and Aggregation, items would be disabled from dragging. This would allow the user to quickly apply some operation before the other.
All process items would also have a configuration and remove option.

Adding new actions would trigger the configuration process, which would slide over the PQL process as a child component, opening up first action possibilities and after it possibility configuration. Some possibilities are without configurations, like some Aggregations methods (min, max, mean,...).

Adding Load actions:

• Http -> configure: method, uri,
• SQL -> configure: method, uri, query,
• ETH -> configure: method, address, chain.

Adding Operation actions:

• Traverse -> configure: params,
• GetIndex -> configure: params,
• Math -> configure: method, params,
• Query SQL -> configure: method, query,
• Custom step -> configure: ???.

Aggregation actions:

• Min,
• Max,
• Mean,
• Median,
• Query SQL -> configure: params, query, result.

With this the user would graphically design PQL code, but he would not have the access to modify PQL JSON.

About the snippets, I would move them on the page before Query builder and would present them as templates, from which you start writing your PQL statements. Maybe on the same principle as creating the new project on GitLab, which allows you to create a blank project or pick some of the existing templates.

What do you think about it?

[jbargu]

Note for BE I would recommend moving aggregation into the pipeline, this way the user could do aggregations, and after it applies additional operations <- currently I don't think this is possible,

How do you imagine such change?

With this the user would graphically design PQL code, but he would not have the access to modify PQL JSON.

I would always leave the option for editing JSON. Even in Metabase you can change the SQL if needed. The query builder should be an enhancement of editing the JSON only. It does not hurt to make a small button: "Edit JSON" that switches to the current view and be done with it. The mapping between the views does not need to be bidirectional but if it can be, even better when switching.