search

ComunisApp / Planning

0 stars 0 forks source link

Fronted Framework #4

Closed CheeseTastisch closed 3 months ago

CheeseTastisch commented 3 months ago

We need to decide which frontend framework we want to use.

All three posibilities support all required features. However, there are good and bad factors about some of them.

Flutter

We think (yes it's our personal opinion, LIVE WITH IT!) that Flutter has many drawbacks compared to the other two.

At first, Flutter does not have the same clear structure as the other two, at least when you didn't do much with it, therefore we see codebases more complex than PWA or Compose-Multiplatform.

On the other hand, we consider Dart a little bit chunky and unintuitive.

Therefore we decided against Flutter.

PWA (Svelt)

In general a Progressive Web App is a website that can be installed and used like a native app. The features are the same as just creating a website with svelte.

Push Notifications are easy to implemente, a ready to use Java/Kotlin library could be used to send push notifications. The reactivity is implemented via Svelte and can be used just like Svelte.

After the Svelte page is build, it must be deployed to some server, from which on it can be installed.

An integration with KeyCloak would be easy, as it's just a redirect to the KeyCloak server. For fetch requests the native featch api or the Svelte Fetch Api could be used. However i think, that the Svelt Fetch Api is unly usefull, if the backend is also writen in Svelte (with Svelte Kit).

The App could take some functionality offline. However, in any case it's only usefull to check a connection and if no connection can be established, show an error page.

For the storage of data, either cookies (shared between client and server) or the local storage (only available on client) can be used.

In general PWAs are a powerfull way to create apps, however, they also have some negativies:

Proberly the biggest issue with PWAs is, that they don't support Push Notifications on Apple. This is a major drawback, as many users are using iOS as ther main device. Therfore if any person in a group does not have a Android divice, the complete group could effectivly not use the App.

Thefore, we decided against PWA.

Kotlin (Compose-Multiplatform, with kotlinx.rpc)

In general Compose-Multiplatform is built on top of Android Compose, which is a nice framework for designing pages.

Push notifications are implementable on a native level, the same goes for the storage of data. Offline functionality is given to any wanted extend, as it is a fully installed app, that can work online or offline (however, it is in any case only usefull, to show that a connection to the backend could not be established).

The integration with KeyCloak should be possibly, by just opening a browser window/a new tab, that shows the KeyCloak website.

A major benefit is, that the Api can be desigend end-to-end typesafe, as both would use Kotlin and can debend on the same "Api-Module". In addition with kotlinx.rpc, even the api can be designed to be usable with classes, and therfore (almost?) no direct call to any RestAPI must be made. However, kotlinx.rpc can (and we proberly will) use Ktor and RestApis.

The only drawback we could find with Compose-Multiplatform is, that the rendering on the web is done via a canvas tag. This is bad, as it disallowes the ability to copy-and-paste text or open the default browser context menu. However, we are sure, as we are super good developers, we will find a way to enable copy-and-pasteing text and allow some sort of context menu.

As Kotlin (Compose-Multiplatform, with kotlinx.rpc) has the most dismisable drawbacks and the best benefits, we decided to use it.

Demo Application

In order to check functionality, we should implement a demo application.

It should involve:

  1. Basic push notifications (Hello World)
  2. PoC layout as we want it to look like
  3. Reactivity (todo-app: add and remove items, marke items as completed, show/hide completed items)

In addition to that, we should check the following things for both frameworks:

  1. Integration with other services, especially KeyCloak
  2. Possibility to integrate with the backend (fetch, kotlinx.rpc), including type safety
  3. Offiline Functionality
  4. Storage of data
CheeseTastisch commented 3 months ago

@SIMULATAN please check the decision and approve it.

SIMULATAN commented 3 months ago

Now, we (I) didn't implement our planned demo applications but surely KMP is the superior choice here :) WCGW