Our final day saw huge progress in the application’s client and server sides coming together. This was really the focus of the day with Greg A, Andrew and Greg G working together to solve the final challenges and get the client communicating with the server.
Server-side
Andrew finished off the implementation of server-side validation in the morning before moving on to providing endpoints on the API for fetching form configuration data – because the forms are user-defined, their configuration (everything from which fields they show down to their validation and visibility rules) is sent to the client along with the data they display. The afternoon was spent working with both Gregs on getting the client-server communication working.
Julian finally saw success getting EventFlow working with a Cosmos database, this time using the Cosmos Mongo API, which, because Mongo is a nosql server got around our issue of an expectation of an identity column. With that in the bag Julian began preparing to integrate Cosmos as at least one of the data stores for our solution although that was side-lined by the focus on getting the client-server interaction up and running.
Client-side
Ned spent the day focussing on implementing support for some more field-type components in the Blazor project. On the simpler end of the spectrum he added a checkbox component along with a boolean field type and a textarea component. At the more complex end he began work on a multi-file upload field. Ned also implemented support for read-only views of all the components, necessary for when presenting existing data for review but not edit as part of a form.
Greg H added a layer on top of the standard GUIDs we had been using until this point, enabling us to have identifiers that incorporate a description of the entity type. Following that he prepared the Blazor app to receive initial form values from the API before moving on to assisting Andrew in getting communication over the API working successfully.
Shared code
Greg A made some final adjustments to the shared definitions of our form definition types and then also began work on the API communication.
Client-server communication
As you’ve read, by the end of the day most of the team was working on getting the client and server talking successfully. The main issue we faced here was in handling the serialization and deserialization of the configuration of the form the client was to display. This configuration was defined in a C# class (for lack of a UI to do that) and then serialized to a JSON file – our temporary “stored” for this config data. This config could then be read by the server and the relevant objects serialized back to JSON and transmitted over to the client.
However, we encountered problems deserializing the JSON on the client-side. It appeared that because the server was running .NET Core 2.2 (due to compatibility with EventFlow) and the client .NET Core 3.0 (for Blazor) there was sufficient differences in how the serialization handled data types that the two were not directly compatible. We tried several tweaks to the serialization to compensate for this but did not resolve all the issues before the end of the day.
What’s next?
Andrew is putting in some time looking at the serialization issue. So far he’s managed to get the form definition successfully over to the Blazor application but when the form is submitted the application hangs and he’s yet to dig into the cause of that, however it’s likely to be related.
The team will also be doing some write-ups of their highlights of the week, which we’ll post on the blog here, but will also communicate to the rest of OCC through our internal talks.