noahzeisberg
commented
7 months ago - Rust is therefore NOT suitable. 😅
Open noahzeisberg opened 7 months ago
noahzeisberg
commented
7 months ago noahzeisberg
commented
7 months ago This is not ready yet, we're still figuring out what the best possible solutions with our resources are.
Here's our approach by now:
We're developing both a small Android and a small iOS application that will only implement a WebView component and display the web version of the app. Native features like notifications will be handled by APIs and our backend. But we will rewrite our web version once again completely using our own components.
We will provide both an iOS and an Android version of eternity to enhance the experience of our users through native features like notifications. To maintain all of those versions, we think we chose a good way for this project to still comply with our resources and especially our developers.
I (Noah, the core dev) am currently on vacation and I'm therefore not able to contribute at this time. I already planned to continue the development on our own component framework, liquid after I'm back in Germany. Liquid consists out of the best aspects of Material UI, Nuxt UI, Apple's Human Interface Guidelines, shadcn and Tailwind UI (only visual). I don't know if you know what I mean, but personally, I find it better to develop most of the project completely by myself as I learn way more this way and it's also more convenient as you can adjust even the most subtle detail of every component by yourself. We will then rewrite the web version with better UX, those new components and therefore a better UI in general.
After the new web version is finished and working as expected, we will start building small but functional apps for iOS and Android that use a WebView to display the web version of eternity. Native features are then controlled by our API/Backend.
noahzeisberg
commented
7 months ago I guess we need some Swift devs...
noahzeisberg
commented
7 months ago We'll try to further provide the currently running version for as long as possible while developing our new backend. As soon as our new frontend is operable, we will also switch our web frontend and will then develop the platform specific frontends for iOS, Android and maybe also for desktop or other platforms.
noahzeisberg
commented
7 months ago Hey, it's me again. I have some news to tell you. As partially obvious, it's quite hard to build a component library completely alone, so we're not relying on liquid for this app. But at least we found a good alternative we already considered to use quite some time ago.
We're switching to shadcn! 🥳
Shadcn has been ported to Vue a while ago and also has quite some interesting components we absolutely need to use in the next web release of eternity. It also allows for smooth transitions and animations out-of-the-box. And the best feature of shadcn definitely is its great customizability, because you rather add every component to your /components directory instead of requiring them through a npm library.
Kotlin would be a great improvement for the app because it would obviously provide a much better performance since it's a native app. Apps are also much easier to access as you just need to open it and get all information you need right away. It will also give us more opportunities for new features like notifications. We could inform our users about the latest substitution table updates and more. It also offers our developers a good solution as we can first develop and test on Android and later on even migrate to Kotlin Multiplatform (KMP) to also provide an iOS version of our app. We could even deploy our Kotlin codebase to desktop devices or to the web which is quite unlikely though, because most of our users are already using our app on mobile devices only and serving additional platforms would also imply a bigger effort on our side.
There are only some things to consider:
We have to get the app on the Play Store or serve it as an APK from preferably a homepage.
If we want to deploy to iOS too, we must get the app on the App Store, which is much harder to achieve than the Play Store, because Apple has stricter restrictions on what we have to fulfill in order to apply for the app to be uploaded.
We would also need a solution to automatically update the app. We have to fix vulnerabilities or deploy bugfixes as fast as possible which is very important at the moment because the app is still in the active development phase and bugs are expected to occur.
We would need to replace integrations to Supabase, the BaaS of our choice and to our own backend which will be referred to in the future as "infinity". This is currently our TypeScript backend built with nitro. Those are obviously not the only things we need to integrate though.
It will of course take some time to at first learn Kotlin and then rewrite the entire frontend of eternity in this language, but it might not take as long as you might think, because I am one of the only developers working on this project anyways and I have quite some experience in learning new languages. Also we might find some support to contribute to this project as Kotlin is most likely being used by more people than our VUNT tech stack is.
We have to consider to also migrate the backend. One of the things, why we've chosen Nitro and TypeScript to be our backend was its great integration with Nuxt and the fact that it's just built into Nuxt. Now, as we're moving away from Nuxt in our main application (we might still use it for the product homepage), it's probably better to just also switch to another backend. Popular choices for the backend are listed below.
Backend choices
Go & http
Go and its default net/http package would be a great choice since I already gathered some experience and insight in how it works and how it's being used in my old project Sapphire. Even though it's one of the only technology for this type of application I know how to use, I consider the http part of it, mainly writing responses, quite complicated, but this should be balanced by the general power of Go.
Kotlin & ktor
Since we're already migrating to Kotlin for our frontend, we may also switch to Kotlin and use ktor as our framework. This way, if our team grows, we could swap in developers from the frontend to the backend and vice versa if we have a big feature to complete and a tight deadline to meet or just not enough human resources on one side. Ktor seems very simple and easy to learn. It may be complicated though to switch to a language none of our developers has experience in by now but seems possible, as we already have to learn it.
Rust & warp
Rust combined with warp would be another possible solution to write our backend in. Rust is a very powerful language but it's also a bit harder to learn than other languages and will therefore most likely be suitable for our project even though Rust is an amazing language.
Python & Flask/Django
Python is also one of our favorites since it's very easy to learn and therefore easy to find people who are interested in working with us. It will also be easy for us to migrate since most of the team already has experience in working with Python, so we just have to learn either Flask or Django as a framework. A trade-off of Python is however the performance, as we could get way more performance out of a Go or Rust app than out of a Python app, since Python is an interpreted language.