Hello Tulip Team and esteemed community members 
,
Working with HTTP connectors and interpreting the structure of various APIs has been both rewarding and, at times, a bit of a puzzle 
. We often bump into intricate nested objects, arrays, and arrays of objects in API results. This complexity can make data processing in connector functions quite the challenge.
Recently, I’ve delved into JSONata, a proficient query and transformation tool for JSON 
. Its prowess in effortlessly flattening complex JSON structures is commendable. By integrating JSONata’s transformative abilities into Tulip, we could potentially unlock a more streamlined approach to handle these JSON outputs 
.
Imagine a feature where we could seamlessly slot a JSONata transformation between the connector response and the JSON query. And, to sweeten the deal, what if we could auto-generate the function’s output structure based on the transformed JSON? That would be quite the enhancement 
.
Such an integration could substantially boost the efficiency and flexibility of our connector functions. I genuinely believe it would be a golden addition to Tulip’s repertoire 
.
Thank you for considering (or not) this suggestion, and I’m excited for the future advancements in the platform 
.
As Tulip allows us a great deal of freedom in the creation of applications, the underlying back-ends can become limiting if they only expose REST APIs. To overcome this difficulty, we are using more and more GraphQL data sources to enable our back-ends to meet the many demands of Tulip applications and also to simplify the complexity of certain Tulip apps. However, we are now coming up against the limits of Tulip’s ability to manage complex payloads (several levels of hierarchy, etc.). The ability to handle incoming messages would be a real plus in the future.
Hey @youri.regnaud -
Thanks for the bump here. We are in the process of code review for the addition of Json-path as another extractor type for connectors, and expect this to land in the next couple Tulip versions. Let me talk to the team to better understand the lift to add support for Jsonada.
Directionally, We want to expose as much flexibility in transformation as possible (to simplify app lofic) with as many of these different json parse formats as we can possibly support. We need to be careful about what we implement as it relates to longterm support, but both json-path and jsonada are widely adopted, so that is less of a concern.
Pete
1 Like
Function node in Node-RED is also a good example of easy payload transformation