decisions

[markus2330]

soon

• rss generator (Gabriel)
• Decision: Map Collaboration & Data Synchronization (Offline) #382 offline vs. collaborative: undo/redo etc. (Paul)

to have a look at:

if this is easily possible, we will:

• decision: mail client #375 contact form sends email via backend (smtp in rust) https://docs.rs/mail-smtp/latest/mail_smtp/ (Gabriel)
• membership onboarding via keycloak (Thorben)

probably decided

• have cron jobs within PermaplanT backend (Gabriel)
• Backend logging #391 logging of incoming actix requests and diesel SQL statements (Gabriel)

done

• state management and architecture decision #30 state management & main architecture pattern
• Write decision about Frontend Documentation system #128 frontend documentation
• add swagger doc using utoipa resolves #85 #101
• database features #26 database (@aidnurs et al.)
• Diesel PostGIS documentation (@NurramoX)
• translations (enum and frontend)
• auth/login OAuth client Rust libs (Gabriel)
• Add backend ORM decision resolves #170 #172 diesel async
• Nextcloud as OAuth server? (@absurd-turtle)
• Decision for "reversible deletion" #130
• 117 nextcloud integration decision - authentication #131
• Decision: Which ORM/SQL crate do we want to use in the backend. #170
• which programming language
• which drawing lib
• which other libs?
• REST
• API blueprint
• Testing framework
• ORM engine https://diesel.rs/ and https://lib.rs/crates/postgis_diesel?
• frontend zusammenbauen? (build tool)
• type-safety between Rust and Typescript

[markus2330]

Great work so far! I added three more decisions to be done (REST+API blueprint+Testing framework). Let us discuss today who will work on that.

[buenaflor]

• Testing framework

After further research and from some little experience I have it seems Jest is a common standard for testing for React apps and it is also a recommended tool by React. I don't think a decision here is necessary, what do you think?

[markus2330]

I agree, no decision is needed but there should be a short documentation about the testing strategy.

[buenaflor]

Sounds good to me!

API Blueprint

Can I get more context on API Blueprint please, do you mean this?

[markus2330]

Exactly, then we can use like https://apiblueprint.org/tools.html e.g. for testing in the CI. Doesn't seem to have Rust generators, though. Maybe it is over-engineering to use something like this.

[buenaflor]

I see, it is not needed then for now I suppose?

Do you have a suggestion on how in-depth the testing strategy documentation should be/what it should include?

[markus2330]

Yes, if you document the API properly as code comments it is fine by me, too.

Do you have a suggestion on how in-depth the testing strategy documentation should be/what it should include?

It doesn't need to be very in-depth, it should mostly cover:

• what should be unit tested in frontend and backend
• integration tests, e.g. for REST API (see also https://actix.rs/docs/testing/)
• how to do manual tests for everything together

At the moment very rough descriptions are enough, as we are not finished with the use cases yet.

[markus2330]

Someone told me about tauri-apps/tauri#1514 (Tauri itself might also be interested in the long-term), which discusses type-safety between Rust and Typescript. There seem to be quite a few options:

• https://rspc.dev/overview/ (works with a Rust backend and Typescript frontend)
• https://trpc.io/ (older then rspc)
• https://crates.io/crates/typeshare (supports Typescript)
• An example how it could be: https://github.com/oscartbeaumont/tauri-specta
• https://github.com/Aleph-Alpha/ts-rs
• https://github.com/tauri-apps/tauri-bindgen

Can you please write up a decision, even if we decide to not do anything of it.

[markus2330]

The main architecture pattern for the frontend is also to be decided, e.g.:

• https://redux.js.org/
• https://reactjs.org/blog/2014/05/06/flux.html
• https://www.evozon.com/model-view-viewmodel-in-reactjs/

The decision will also influence how undo is done, e.g. by using https://www.npmjs.com/package/redux-undo-redo-middleware?

[markus2330]

If we are using JSON schema, another option would be: https://imfeld.dev/writing/generating_typescript_types_from_rust
(If not, direct ways are preferable.)

[buenaflor]

I played around with a bit and it seems like typeshare is the one that works the best seamlessly, it is also easy to configure so I'm leaning towards using it

[markus2330]

LGTM, too.

[markus2330]

@buenaflor if you want to look into graphql anyway, it would be nice to have a short write-up what you found in a decision. (If you don't look, don't write 😉). Some libs seem to be a bit immature but there already seems to be everything needed:

• https://typed-graphql-builder.spion.dev/ (alternative to https://tql.dev/) for type-safe code in frontend.
• https://github.com/graphql-rust/juniper
• Example how it could be done: https://github.com/husseinraoouf/graphql-actix-example or https://github.com/nenjotsu/rust-actix-graphql

It is not totally unrealistic that for lookups in the map REST is not ideal (slow).

[markus2330]

We got very positive feedback about our decisions: "React + Vite + TypeScript klingt gut, das ist aktuell der populärste & stabilste Stack für Frontend Projekte"

For State Management, however, we should look into:

• Recoil/Jotai
• React Query

I updated the top post.

[absurd-turtle]

There is already a small state-management solution in use. It's called zustand. If we switch to a different library we should get rid of this dependency.

[markus2330]

@absurd-turtle exactly, that is what is to be decided. See #30 for prior work, I think you can take over the work on this PR.

[markus2330]

@ElektraInitiative/permaplant
I tried to add all decisions at the top post (including the ones we discussed in the Backend meeting). Are there any other decisions

• we need to decide upon or
• are already open and not linked above?

If you want one of them assigned, please write here.

[kitzbergerg]

@markus2330 about the rss generator: What should I write there and where?
There is a crate rss which can be used. As far as I understand we would need to put articles (or whatever else we want to serve) in the database and sort by date when querying. Then when a requests come in we query the ~15 newest articles and parse the entity to the rss Channel. So Channel would be kind of like a DTO in this case.
Apart from that we have to think about how to insert into the RSS and that we have to serve the data as xml instead of json.

However there isn't really a decision involved. It is more 'How to implement a RSS generator' so it doesn't really fit in decisions.

[markus2330]

The idea was to have some Markdown file (or something else easy to write manually) that is used for both:

1. to generate the news in the frontend
2. to generate an RSS feed

Ideally we would use something that already fully implements this, which doesn't seem to exist in Rust.

@absurd-turtle can you maybe share your idea? Would the backend be involved? Is there some ready-made solution.

[absurd-turtle]

I think the best solution is to generate the RSS feed in the backend and serve the XML on a specific endpoint.
Then have a separate endpoint for the blog posts to serve the data in json to the frontend.

To store the data we could just have files that are served directly or put it in the database.
If we store the data in the database we would also need some UI/cli for the author to put the new post there.

[markus2330]

@absurd-turtle As the news feed on the web site should now be a NC chat, it would be great if we can generate the RSS feed from the chat's content. Is this better implemented in the frontend or in the backend?

[markus2330]

We could try to use

• https://github.com/nextcloud/talk_matterbridge
• https://github.com/42wim/matterbridge
• https://mattermost.com/marketplace/rssfeed-plugin/

But it is a bit much experimental technology involved but maybe okay for a public announcement channel. Having our announcement channel in many formats would not be a bad thing.