Hi all,

 

during the last days, while starting to migrate the editor UI module to
Angular, I did some experiments with different serialization approaches.

 

Currently, we use two different serialization approaches in the UI:

1.      JSON for most things and the editor module also uses JSON to
represent static properties (which are used to render the UI components in
the pipeline element configuration)
2.      The (newer) Connect module uses JSON-LD (which is also used in the
core to represent pipeline elements) to represent static properties.

 

Both approaches have advantages and disadvantages:

For (1), we use GSON for serializing JSON, which is easy and fast for most
cases, but there is no direct mapping to TypeScript classes for complex
objects (like static property definitions with polymorphism), so that we
rely on the <any> type here in most cases (especially in the editor module)
-> all type information is lost and UI development is more error-prone.

For (2), we use a self-made JSON-LD serializer named Tson-LD. This works
great, but TypeScript-classes need to be manually modified every time
classes in streampipes-core change, which increases maintenance effort and
also is rather error-prone. On the other hand, Tson-LD deserializes JSON-LD
into TypeScript classes, which is quite convenient from a developer
perspective.

 

As we will soon be able to completely remove AngularJS from the UI, it also
makes sense to rethink and streamline our serialization approach (mainly to
have a single component that cares about generating UI components from
static properties, both in Connect and the Pipeline Editor).

 

So after doing some research and testing I'd propose the following approach:

*       Use only JSON as a serialization format for UI-core communication
and remove JSON-LD from the UI
*       Use Jackson over GSON as a serialization library, as this better
works with the next point:
*       Use typescript-generator [1] to auto-generate TypeScript classes
from Java models. There is not much configuration needed and there is a
Maven plugin which could automatically run the code generation at every
build.

 

This approach would have less overhead, guarantees that all models are
always up-to-date and reduces maintenance effort. Drawback is that quite a
few UI modules would need to be changed.

 

I have already a prototype running which shows that the approach works quite
well. But before I continue, I'm interested whether you think this is a good
or bad idea and if you have any other best practice approaches?

 

Dominik

 

[1]  <https://github.com/vojtechhabarta/typescript-generator>
https://github.com/vojtechhabarta/typescript-generator

 

 

Reply via email to