Switch from Svelte to Leptos

[kerkmann]

Would be awesome if this project would use leptos, this would help to get rid of the entire just/npm stuff. ❤️

Also one idea about leptos is, the frontend could be behind a feature flag and vice versa, headless feature would be awesome. :)

Feel free to close this issue, if you are not interested in leptos, or reach out if you need help! ❤️

[sebadob]

I am absolutely interested about leptos and already thinking about it anyway since quite some time, how we could do a migration smoothly.

I am using leptos almost exclusively for all my other (newer) projects already. When Rauthy has been started, there simply was no leptos. The only real Rust framework was Yew. But unfortunately, this has huge payloads and wasm sizes, which is why I never really considered it.

We will for sure not get rid of just because of other reasons. The most important is that it sets the DATABASE_URL for you each time. I don't have a better idea for the current handling of these for the moment, because sqlx broke the Any driver when they released 0.7. The Any driver was the reason why I used it in the first place, because I could just use the same setup independent of the database. v0.7 basically kills this Driver. A lot of things broke with it and my issues about it where simply ignored, which is why I moved to the feature gated approach at some point.
If I would start over, I would prefer native DB drivers and not use sqlx anymore tbh.

That was a bit off-topic. :)

I really like leptos, I am using it at lot in other projects and a migration would make the whole UI development thing a lot easier. The only considerations, before we can actually do this, are:

• Create at least a PoC and make 100% sure, that the whole Webauthn / Passkey flow does not have an issues on no device / browser (mobile especially) when used in a WASM context. This should work fine, but I would want to know this 100% beforehand.
• Find a nice way (already thinking about this) how the migration can be as smooth as possible. Just migrating everything in one go would be preferred, but this would be a really really huge PR and would possibly block other things in between like maybe important bugfixes, or we would need to implement them twice, which would be annoying too.
  The idea for now is to feature gate it at least for the time of the migration. This would work, but it would make the whole process more complicated as well, because quite a lot of things need a different handling then.
• Think about how to handle the backend calls. The server functions are very convenient to use and are my goto, usually, but I would not change the rauthy API layout like it is now. This means we would probably not use server_fns but actually do the requests manually with reqwasm or something. This is no big deal, but also removes some convenience in other places.
  The other way of doing it would be to have server functions as duplicates for the current API. This would be the most simple setup, but also the one with the most resource usage later on.
• Think about the above mentioned resource usage. One of Rauthy's goals is to be really efficient. Leptos SSR adds quite a bit of memory overhead right now. This will of course improve in the future, but it will always be a lot more than just the currently static HTML files.

In its current setup, a headless feature would be really easy - just don't add the API routes, but it does not give you any advantage tbh. There is simply almost no overhead at all with the UI. Svelte is not really running in production. Everything is compiled down to static HTML files. So the only overhead are a few kB of these files being cached in memory, that's it.
This is actually a very big con for leptos. All pre-rendered UI files together (in plain and pre-compressed gzip + br) are less then 3MB.

To make things short:
I am already thinking about leptos for quite a while now, because the DX would be a lot better, yes. :)

[sebadob]

@kerkmann regarding the just usage you mentioned - I renamed all the -sqlite recipes with the latest push. Basically, all -sqlite additions have been removed and you can simply just run to run the sqlite version. I guess this is most often the one used for local dev, so all of the just commands are shorter. The same is true for executing tests. just test will simply be the sqlite version instead of just test-sqlite before.

[kerkmann]

@sebadob Thanks! I am a little bit busy, but I'll take a look within the next few weeks, thanks for all your support. ❤️

[sebadob]

I did a few tests and played around with islands to see how far we can get with bringing down payload size.

As much as I like leptos and use it on different projects as well, I think you should always use the right tool for the job.
At the current state, it does not make sense to implement Leptos for different reasons:

1. The main reason why it does not make any sense is that we can't split WASMs easily. There are ways to do this and serve multiple frontends / WASMs from the same backend, but the setup is far from being straight forward.
   When we take a quick look at the raw numbers for the UI currently:

• static compiled payload (uncompressed) for all files is roughly 950kB
• the "normal user facing part" without the admin UI is ~100kB

When we assume that we have a small instance with a few hundred users, then we would probably have a handful of admins. But this means that a few hundred users need to download ~9x the payload they actually need and use, because they will never even need the admin UI parts. This is not only a pretty huge waste of bandwith with many users, but it also slows down each single one dramatically.
When we then take into consideration, that at the current state leptos WASMs are ~9-10x bigger than svelte's, this gets even worse. This will get better with v0.7 and islands, yes, but we still have the initial ~9x difference anyway, which will not go away.

2. I can get rid of the switch between npm dev server and rust backend by implementing a simple reverse proxy for local dev. I am doing that in other projects already, where I do use the svelte static HTML compiler as well.

3. It would be an awful lot of work just for the sake of "using leptos"

Rauthy is kind of the worst case scenario, when you can't split your frontend payloads. Only a fraction of all the users ever needs all the admin parts and all ways to solve this issue would be a way more complicated setup to run and build then it is now.

If the way browsers handle WASMs changes in the future and we will be able to split them easily (we can't right now because a WASM is loaded in a streaming way), then we can consider this again and open a new issue about it, but right now it does not make any sense and it would be weeks of work.

[erlend-sh]

The main reason why it does not make any sense is that we can't split WASMs easily.

There is hope! rustwasm/wasm-bindgen#3939 (comment)

[sebadob]

@erlend-sh Yes I saw it as well that greg forked the testing repo for that and I am really hyped about it. This is still in very early babyb steps, but if we can get this stable in the next months, this would be one of the most awesome things for WASM. This is one of the 2 biggest pain points with wasm.

Also the wasm size will shrink quite a bit with leptos v0.7 + islands. Maybe in the future it would make sense to migrate Rauthy's UI as well, but this would be a lot of work.