FLS-1452 - Form Runner - Retrieve forms from Pre-Award API

[wjrm500]

🎫 Ticket

Form Runner - Retrieve forms from Pre-Award API

♻️ Changes

• Rename RegisterFormPublishApi to RegisterFormsApi - The previous name felt overly-specific, given that the API endpoints defined in this file also include ones that are foundational to the application, including for getting form pages and submitting form data. Plus, we're about to remove the publish functionality.
• Remove environmental preview mode - 'Preview mode' is an environment variable that is currently set on an environment-by-environment basis. It controls whether we allow passage through the application's 'publishing' endpoints. These publishing endpoints, which support FAB and Form Designer to offer form preview even where forms are not loaded into the Runner cache at app startup, are being removed as part of Live Services' forms re-architecture work. In future, instead of the Runner supporting publishing of arbitrary forms into its cache, all forms will exist in a shared location in Pre-Award, and there will be no practical use case for rendering an arbitrary form. Please note that removing this environment variable does not itself stop forms being previewed, or the preview banner from being rendered when a form is previewed. This is because the preview banner rendering is dependent on the prefix 'preview' being present at the beginning of the form session identifier retrieved from the URL.
• Remove publishing endpoints - Publishing endpoints in Form Runner are used as Form Designer's primary persistence mechanism - each change made to a form in Form Designer will trigger a POST request to the /publish endpoint, updating the form configuration in the Runner's cache. They are also used as a means to allow FAB and Form Designer to offer form previews for forms that are not loaded into the Runner cache on app startup. Thus they are integral to the current functioning of the application, and this commit can very much be considered a potentially breaking change, so it's important that FAB and Form Designer are redirected at Pre-Award before this goes live. Why are we removing them then? They are components of a flawed system that is being revamped by Live Services as part of our forms re-architecture work. In the future, there will be no need for arbitrary forms to be published into the cache, in order to support persistence or preview. Forms will be stored in a new location - the Pre-Award database - and Form Designer will POST updated form configuration data to a Pre-Award API. And regarding form preview, for a form to even be shown in Form Designer or FAB it must exist in the Pre-Award database, and so rendering it from Form Designer or FAB will be a simple case of requesting the form directly from the Runner, which will get it from the Pre-Award API, with no precursor publish call necessary.
• Remove redundant method getFormConfigurations from AdapterCacheService - getFormConfigurations was used within one of the publishing endpoints to send back all of the forms in the cache to Form Designer so it could display them on its existing forms page. This endpoint has been removed from Runner now and Form Designer is being re-pointed at the Pre-Award API to support this requirement.
• Refactor RegisterFormsApi for readability - This is a non-functional change, a pure refactor. We now inline consistently in calls to server.route() (instead of creating variables only used in one place), group middleware functions and place them above route functions, and reduce whitespace.
• Simplify code in AdapterCacheService around Redis client - Currently we have duplicate Redis client configuration code in the private AdapterCacheService method getRedisClient and in the catboxProvider function. The way the code is formatted is also unnecessarily space-consuming. This commit creates a new shared utility function createRedisClient which can be used in both places, and uses concise formatting to reduce lines of code significantly.
• Abstract Redis and Catbox cache clients in AdapterCacheService - This commit introduces a common interface attribute formStorage on the AdapterCacheService to represent either a Redis client or a Catbox (in-memory) cache client. This enables us to save significant lines of code, where previously we branched off to different functions depending on whether we were using Redis or not, now we can concentrate logic in fewer functions with no branching. We're able to do this because the way we use the two clients is almost identical since we no longer need getKeys functionality. Previously, because the Catbox cache client doesn't have a getKeys utility built-in like Redis, special code was required to keep track of the keys in the cache in the case of Catbox.
• Stop loading forms from fsd_config into cache on app startup - We are going to fetch forms from the Pre-Award API instead. We need to keep the loading of specific forms to ensure unit tests pass.
• Create and register new PreAwardApiService - This new service facilitates calls to endpoints in the Pre-Award API - the GET /forms/{name}/hash endpoint, and the GET /forms/{name}/published endpoint.
• Actually retrieve forms from Pre-Award API - All of the work we've done has been leading up to this point! In this commit we introduce two new methods into the AdapterCacheService - validateCachedForm and fetchAndCacheForm. These are then used in a revamped getAdapterFormModel. Now, instead of simply looking in the cache, which is no longer in itself sufficient as we don't preload the cache on app startup, we check the cache for the form, if it's not there we go and fetch it from the Pre-Award API and cache it, and if it IS there, then we check to make sure that it hasn't been updated in Pre-Award by comparing the hashed form configurations. Session management is unaffected.
• Use server logger in AdapterCacheService to reduce logging noise - Using the request logger as we do at the moment introduces the 'req' object into every log message, which is noisy and duplicative, especially given that we log the request path upstream.

[sonarqubecloud]

Quality Gate passed

Issues
13 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed

Issues
14 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud