:wave: :thinking_face: Would it make sense to have...

# supabase-kt

[Nacho Ruiz Martin]

👋
🤔 Would it make sense to have something like the gen types typescript for Kotlin?

[Jan]

Maybe. Not sure how it would look like. Generate Kotlin Database classes?

[Nacho Ruiz Martin]

Yes!

[Jan]

We could maybe do that via ksp. Retrieve DB types via the API and then generate classes at compile time 🤔

[Nacho Ruiz Martin]

That would be great, right? This way you wouldn't need to create those data classes yourself. I've never used KSP but I could take a look.

[Jan]

Sure, that would probably be a heavier PR. Could you create a feature request on Github?

[Nacho Ruiz Martin]

Sure

[Maanrifa Bacar Ali]

Hi all, I think I’ll need such a feature soon. Has anyone planned or started working on it or do I have to build it from scratch ?

[Jan]

Well its probably going to be similar to typescript and that is built into the Supabase API. To add Kotlin support we need to create a Kotlin generator in https://github.com/supabase/postgres-meta.
I haven't started yet but its on my ToDo.

[Maanrifa Bacar Ali]

Well, just started working on this.

I’ll not create a Kotlin generator under the postgres-meta project from Supabase because it is very limited in its current form regarding code generation (for a Kotlin project under Gradle build system). I have something better in mind and more Kotlin/Gradle friendly.

So the plan is to provide a way to generate Kotlin types for database table and enum types.

The generated types would be usable in both server (using edge-functions-kt) and client side (kotlin application).

I’d like to discuss about types mapping if anyone is interested in suggesting a type map table.

Is there anything special that the community is waiting for ?

[sigmadelta]

I’m not sure if I understood the intention completely right, but if so it feels like this might also be a very double-edged sword.

Average developer is very lazy, and (pre-)generated data classes might be a gateway to just spamming * into raw column joins.

Whilst it speeds up development to certain extent, it also removes the necessity to think about which data is really relevant for your query and can potentially also lead to a slew of “Why are my queries so slow, I thought that Postgres was supposed to be fast”-type of situations. 😅

[Jan]

Note that there is some discussion about a new way of selecting postgres data / generate needed columns automatically from data models in #761

[Maanrifa Bacar Ali]

Ok, going back from several months of deep embedded C programming and its seems that i need to update myself with supabase and supbase-kt first.

My main goal is to completely remove the need of typing these data models as it can be quite cumbersome for huge database with more than hundred of tables distributed in multiple schemas.

After having read promising #761, and now that I'm aware that developers cares about database performances and are afraid of double-edged swords, I've reviewed my initial thoughts but I keep thinking that there is still something to do. Furthermore, the interesting turn that supabase-kt is taking makes me think that we are not taking enough advantage of the Kotlin ecosystem. Tomorrow, Kotlin will be the preferred way to get started with Supabase kodee loving.

Even if it will involve more work than expected, I'll continue my work on this subject while taking into account newcomers, JS to KT switchers and lazy developers needs (⚔️) as well as advanced and performance aware developers needs (🏎️).

@sigmadelta Sorry for the lack of explanations, I'm still in an exploration phase so I can't provide more details. I'll put details on this topic once available.