Hi Dominik,

+1
I totally agree, we need a unified solution for the communication of the 
backend and front-end.

I have question regarding the TypeScript code generation. You mentioned we 
could generate the classes in a Maven build, right?
How would the development of the UI then look like? How can a UI developer 
generate those classes and can they be changed or are they immutable?

Philipp

> On 2. Jun 2020, at 23:33, Dominik Riemer <[email protected]> wrote:
> 
> 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
> 
> 
> 
> 
> 

.........................................................
M. Sc. Philipp Zehnder
Wissenschaftlicher Mitarbeiter | Research Scientist
Information Process Engineering (IPE)
 
FZI Forschungszentrum Informatik
Haid-und-Neu-Str. 10–14 
76131 Karlsruhe, Germany
Tel.: +49 721 9654-805
Fax: +49 721 9654-806

[email protected] <mailto:[email protected]>
https://www.fzi.de/mitarbeiter/philipp-zehnder
 
.........................................................
FZI Forschungszentrum Informatik
Stiftung des bürgerlichen Rechts
Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Prof. Dr. Andreas Oberweis, Jan Wiesenberger, Prof. Dr.-Ing. J. 
Marius Zöllner
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
.........................................................

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to