NIFI-9309: Include a uiOnly flag when requesting flow for a given pro…

[markap14]

…cess group. In that case, do not include the property descriptors, property values, etc. for Processors. When fetching Variable Registry, improved logic to cache the VariableImpact for each property value instead of parsing/recreating it every time. When fetching bulletins for a component, avoid filtering through all components' bulletins and instead only look at bulletins that might pertain to the appropriate component

Thank you for submitting a contribution to Apache NiFi.

Please provide a short description of the PR here:

Description of PR

Enables X functionality; fixes bug NIFI-YYYY.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

For all changes:

• Is there a JIRA ticket associated with this PR? Is it referenced
  in the commit message?

• Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

• Has your PR been rebased against the latest commit within the target branch (typically main)?

• Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

• Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
• Have you written or updated unit tests to verify your changes?
• Have you verified that the full build is successful on JDK 8?
• Have you verified that the full build is successful on JDK 11?
• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
• If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
• If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
• If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

• Have you ensured that format looks appropriate for the output in which it is rendered?

Note:

Please ensure that once the PR is submitted, you check GitHub Actions CI for build issues and submit an update to your PR as soon as possible.

[exceptionfactory]

Thanks for this improvement @markap14! The concept seems like a helpful improvement, but what do you think about changing the name of the flag to something different than uiOnly?

Although the flag is descriptive in terms of the purpose, it seems somewhat more narrow than necessary. Another REST API consumer may make use of the resource for some other purpose where a more optimized response is preferable, but not be related to a user interface. What do you think about something along the lines of minimal, truncated, or summarized? It is a minor thing when it comes to implementation, but some more descriptive of the function, versus the implied consumer, seems like it would be helpful.

[markap14]

@exceptionfactory i did consider some alternatives. I went with uiOnly because I specifically wanted to make it very clear that no other consumer should be using it. Ever. Because the point of it is that we can change what gets returned for that response at all. If we called it minimal, truncated, summarized, etc. even with that fact documented, a consumer would be likely to assume that if a field is populated in version 1.15.0, then in 1.15.1 it should be populated as well, etc.

Typically, we do use a flag of verbose, where that can be set to false in order to bring back minimal details. But we maintain backward compatibility between versions there. Here, we do not want to guarantee any sort of backward compatibility between versions.

[simonbence]

Hi @markap14! I quickly tested your changes with a bigger flow (around 32_000 proceccors organized into multiple levels of groups) and the request time for variable in a group dropped significantly. Originally it was around 16 seconds and after applying your commit, it was somewhere between 140 and 150 milliseconds. This is a great improvement! Meanwile I take a look on the code itself.

[simonbence]

As I wrote earlier, this is a significant boost. I tried some other things in order to make it even faster (like minimising the walks on the flow graph), but neither of my tries made it faster without secreficing on the functionality side. So it LGTM.

[mcgilman]

+1 on the front end changes.

[scottyaslan]

+1 as well

[exceptionfactory]

Here, we do not want to guarantee any sort of backward compatibility between versions.

Thanks for the background @markap14, that is helpful. In light of that purpose, using uiOnly makes a bit more sense. That may be the best approach, and as others have already approved the PR, I am fine with it going forward as implemented.

It seems like changing the parameter to something along the lines of internal or internalSummary might also work. It might even be better to introduce a separate REST API method to help indicate the unstable nature of this representation, but since others approve the changes as implemented, no need to make further adjustments.

[markap14]

Thanks for the theory reviews all. Given the three +1's here I'll go ahead and merge.