Design thought on handling URL request when Webhook as EndPoint (ItemList for splitting field after 2 Code nodes)

As I working toward my prototype, I’d encountered increase overhead from my initial scope. I wasn’t keen to populate the HTTPRequest response into a db ie. nocodb, baserow, as it was thought to be a wf execution and returning the concatenated payload. I choose to hold the data in ItemList and Code nodes as needed.

When I’d seen $count in the parameter, it was easy to take it out and supply the count in the json. As I work through the implementation I’d realised the front end calling the webhook when sort/filter/page (25 per row) page is clicked.

image

Suddenly I found myself needing to handle more query options for saving the IO to the rest enabled data platform as previously thought these are experience calls (admin, insert result, query result, and cleanup) per call. I find it becomes a balance point that either using handling in n8n (preferred) or writing to nocodb.
image

I wonder anyone has had the same experience using webhook as endpoint and had build a query proof handler?

Information on your n8n setup

  • n8n version: 0.2262
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): npm
  • Operating system:

I wonder anyone has had the same experience using webhook as endpoint and had build a query proof handler?

Hi @engowen, perhaps you can share more details on what exactly you are looking for here? I imagine a lot of n8n users are handling webhooks in some way, and quite often also process url parameters. n8n imho make this reasonably simple as it automatically splits these up into individual fields (query.StartingOBID and query.NavigateReis in your screenshot).

Hi @MutedJam, I was hoping someone would said just import abc and i got something that’s usable, but good to hear i went with the correct path that I have to handle the each request as it goes. Right now I’d managed $count, $filter, $orderby, and will work on the rest. I started this workflow thinking I could get away without using Code node but I’m using it more regularly and it is really powerful as long as I build a mock data and test it to ensure the expected result is returned. I’m getting there slowly :sweat_smile:

@MutedJam Any idea how do I split out the params when the value is after 2 Code nodes?

If the array is next to ItemList I can type out the Field To Split Out without using expression.

I can get the list of params here by specifying the key as fixed value but this isn’t the node needing the output.

I couldn’t get the actual Item List to split out the Params regardless of syntax as expression. I tried typing Params as fixed string but doesn’t works too.

Any idea?

As per the documentation Field to Split Out: the field containing the list you want to separate out into individual items. Must be plain text and not an expression.

How do I refer to the node’s field from the node “2 nodes back” when the field is not accessible at “1 node back”?

Hi @engowen, the “Field To Split Out” would take the name of a field on the current node. So it’s not possible to reference data from two nodes back.

You could, however, use a Set node just before your Item Lists node to read the params field using your expression {{ $node["Code"].json.params }}. Then, in the Item Lists node itself simply specifc params as the field to split out.

2 Likes

Thanks @MutedJam for the information and workaround :+1:

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.