Hi Philipp, coming back to your questions after doing more experiments and code refactoring:
* I integrated a Maven Plugin [1] to streampipes-model and streampipes-model-client. It creates typescript files by executing mvn typescript-generator:generate and outputs a single file to target/typescript-generator. * I added an annotation @TsModel, the plugin picks up every class with this annotation and generates typescript classes [2]. * There is a folder core-model/gen in the UI where model files need to be copied to [3] * The serialization layer is now based on JSON/Jackson, it's still WIP and there are quite a few things that need to be modified in the UI. I'm gradually replacing @Gson annotations in the REST interfaces with @JacksonSerialized so that all models can be easily deserialized using some utility methods provided by the typescript-generator * To support serialization of polymorphic classes (e.g., lists of static properties), type hints need to be added to the abstract class, see an example here [4]. This is similar to the GSON adapters we had before. * So coming back to your questions, in case any data models served by our REST interfaces are changed, the typescript-generator needs to be run (copying can probably be automated). In case classes need to be changed in the UI you can either cast types to <any> or create wrapper objects. In general, the new approach should make UI development much less error-prone. It would be great if you all have a look - feedback is welcome! Dominik [1] https://github.com/apache/incubator-streampipes/blob/STREAMPIPES-145/streampipes-model/pom.xml [2] https://github.com/apache/incubator-streampipes/blob/STREAMPIPES-145/streampipes-model-shared/src/main/java/org/apache/streampipes/model/shared/annotation/TsModel.java [3] https://github.com/apache/incubator-streampipes/blob/STREAMPIPES-145/ui/src/app/core-model/gen/streampipes-model.ts [4] https://github.com/apache/incubator-streampipes/blob/STREAMPIPES-145/streampipes-model/src/main/java/org/apache/streampipes/model/schema/EventProperty.java On 2020/06/05 08:19:47, Philipp Zehnder <[email protected]> wrote: > 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 > ......................................................... > >
