Verbosity of Nodes

[radumg]

From @radumg on December 24, 2017 15:35

Expected Behavior

Users should :

• be able to build & execute web requests in as few nodes as possible
• not need extensive background knowledge on how web requests work (shallow learning curve)

Actual Behavior

The bad bits

The current implementation of DynaWeb :

• uses a builder pattern (albeit incomplete to be simpler)
• is quite verbose in that it exposes many methods to progressively construct a web request (AddHeader, AddBody, AddParameter, etc)
• as such, complex requests can require many nodes to build (see sample 8 for a Forge request)
• assumes the complexity of a request will be hidden in a custom node (package is designed to be used to make specific integration packages).

The good bits

The current implementation of DynaWeb :

• matches closely the standard terminology used with web requests in public documentation (wiki, mozzila dev docs, etc) or the terminology & steps presented in middleman apps for interacting with the web such as Postman
• the C# code generator in Postman translates 1-to-1 to steps required to build a request with DynaWeb
• highly flexible library, allowing you to build very specific request structures
• the structure of the codebase maps nicely to a Dynamo package
• once the terminology of web requests is known, usage of the package is quite easy & clear

Discuss

This issue is meant to be a place to discuss how the package verbosity should be tackled in the context of integrating it into the Dynamo Core Library. Screenshots, ideas, options, every suggestion is welcomed :)

Copied from original issue: radumg/DynWWW#40

[radumg]

From @radumg on December 24, 2017 15:35

AU Vegas notes

Below are some of the things I remember discussing with @Racel & @kronz at AU about this - they're by no means complete or a faithful representation, so please feel free to add/clarify things 😄

Tackling verbosity of nodes

In discussing how we could potentially address the problem of needing 10 nodes to build a request, one idea was to use a custom UI node that we can add/subtract components from, much like the List.Create node works. The components would be things like headers, parameters, etc.

We'd go from this (sample 7) :

to something like this, where item0 would be replaced by what that component is (header example).

This shifts the building pattern from a series of nodes to a single, albeit jellyfish node. Most of the components, like headers, are dictionary-like items and require 2 inputs ('header typeandheader value`). Could play well with dictionaries if they're added to DYN @Racel ?

This should also help reduce the overall number of nodes in the package as nodes like AddHeader would not be exposed as nodes anymore and accomplished through the node UI.

The obvious downside to this is that it gets coupled to the NodeModel and the WPF UI, so don't know how this would evolve.

[radumg]

From @radumg on February 13, 2017 19:56

Discussed with @Racel & @mjkkirschner

• immutability of nodes to fit into Dynamo Core
• combine nodes into a constructor with 4-5 inputs max
• put into Import/Export > Web
• JSON de/serialisation into Import/Export > Data, DYN team to discuss with @pboyer

[kronz]

Hi @radumg
One thing to thing about with the jellyfish node . . . there's been a little investigation around creating nodes that change their port configurations based on the kinds of inputs they receive. This is able to be done with regular UI node capabilities, it's more about how to make a reusable pattern for how people could do this generally. There is an example that is too complicated for an "official" sample, but you might want to check it out anyway as you're already pretty advanced in this stuff:
DynamoDS/DynamoSamples#27
And some of the discussion leading to the move to create more abstraction:
DynamoDS/Dynamo#9005

I think there's some amazing possibilities here by combining dropdowns with variable arguments being surfaced for nodes, effectively limiting the number of nodes exposed to users for larger libraries with complicated workflow needs.

-Z

[radumg]

Thanks @kronz for the notes!
I still haven't come up with a pattern that i'm completely satisfied with yet, will keep thinking about it, open to any suggestions/mock-ups/etc 😎