https://kotlinlang.org logo
#apollo-kotlin
Title
# apollo-kotlin
s

Stylianos Gakis

03/14/2023, 10:48 AM
For a type like this in the schema
Copy code
type Money {
    amount: Float!
    "Currency of the money (ISO 4217)."
    currencyCode: CurrencyCode!
}
If this were a scalar, I would know how to make an adapter so that in code I can always use some more apt money type (if you have suggestions here for a good Money library, only to represent it, not to do maths on the client, open to hear about it) Since it’s just a type, it will by default generate a Kotlin object which is gonna represent
amount
as a
Float
. Is there a way for me to change that so I never see the
amount
as a float in the first place?
m

mbonnin

03/14/2023, 10:50 AM
You could patch your schema and define your scalar type client side. It's a bit hacky but that'd work
schema.writeText(schema.readText().replace("Money", "CustomMoney"))
and then
Copy code
#extra.graphqls
scalar CustomMoney
s

Stylianos Gakis

03/14/2023, 10:55 AM
Aha! And then I can make my adapter take in the value and read it as a float (as that’s what it really is), and convert it to CustomMoney just as I normally would if it was a scalar in the first place
m

mbonnin

03/14/2023, 10:56 AM
I think that'd work
It'd have cache implications though because it means there's no
__typename
anymore
All the
CustomMoney
would be embedded in their parent record
Which is certainly fine for this specific case but probably not in more complex ones
s

Stylianos Gakis

03/14/2023, 11:00 AM
Yeah makes sense for caching, I think this will be fine for our case. I am discussing basically this type with some backenders and I really don’t want to have a float for money so I am exploring what options I have on my end to at least make my life easier. So can’t test atm, but when the time comes I will need to check out how to do this So the follow-up questions: • Does a Float look fine in this context? My intuition tells me it’s odd to represent it as a Float on the schema, but I may be over-reacting since we’re not gonna be performing any actual calculations client-side • Do you actually have some favourite Money library for jvm/Kotlin? Just if you’ve happened to work with money related things before.
m

mbonnin

03/14/2023, 11:01 AM
Isn't the usual thing with Money that you want bigint or anything to avoid loosing (or winning) money due to rounding errors?
If that's only for display, I'd be fine with
Float
Also note that GraphQL
Float
is Kotlin
Double
for some reason so it's 64 bits
s

Stylianos Gakis

03/14/2023, 11:04 AM
Yeah definitely, I think on the backend it is BigSomething, but then only when handed off to the clients it’s translated to Float, supposedly since the web clients had an easier time with it this way. That’s what I understood. Ah good to know about the double, thanks! I will probably need this information when I have to build the adapter.
m

mbonnin

03/14/2023, 11:04 AM
on the backend it is BigSomething, but then only when handed off to the clients it’s translated to Float, supposedly since the web clients had an easier time with it this way. That’s what I understood.
Sounds like a reasonable approach 👍
b

bod

03/14/2023, 11:16 AM
I'd recommend using strings on the wire
Floats usually bring precision issues, ints have a max value. Strings can be converted to a BigInteger on the client.
m

mbonnin

03/14/2023, 11:23 AM
I'm team 'Float', it makes it explicit that it's not for computations but for display (if that is what it really is)
I wish my bank would give me monthly report with BitDecimal accuracy though 😄
I wish my bank had an API lol
b

bod

03/14/2023, 11:24 AM
isn't String even more explicit about it being for display? 🙂
m

mbonnin

03/14/2023, 11:25 AM
Yea I guess so, if it were for computation, I'd expect a custom scalar
But some clients might still want to tune the displayed precision in which case Float is better
Like do you need a coma or a dot
I wish Excel stopped using comas!
I wish a lot of things!
b

bod

03/14/2023, 11:27 AM
I think I would go with a custom scalar with the amount being "cents" represented as Strings [some currencies don't have cents]. But yeah... "it depends" 😄 Not an obvious topic actually.
s

Stylianos Gakis

03/14/2023, 11:30 AM
But some clients might still want to tune the displayed precision in which case Float is better
Shouldn’t a client anyway be taking this Float, turning it into [Insert favorite Money type here, let’s call it CustomMoney] and use the formatter that it provides anyway, so that it will be respecting current locale etc. to know how to represent this in the UI. So whether the input to [CustomMoney] is a Float, or a String doesn’t matter for the client, since it should be able to handle both (As I understand, BigDecimal can handle both for the JVM for example) and the only thing one is doing by sending a Float over the wire is potentially losing some precision?
m

mbonnin

03/14/2023, 11:35 AM
Losing precision and also losing network bytes
But yea, in all cases it should be formatted
s

Stylianos Gakis

03/14/2023, 11:44 AM
Losing precision and also losing network bytes
So are you team String now too? 😂
m

mbonnin

03/14/2023, 11:45 AM
Nope, losing network bytes is a good thign
(in that case 🙂 )
s

Stylianos Gakis

03/14/2023, 11:46 AM
Oh, losing, as in less, not "losing space" aka taking up more space 💀
m

mbonnin

03/14/2023, 11:46 AM
yep!
Sorry that wasn't clear, it's more "trimming" than "losing"
Because we don't care it's lost
I'm team Float or scalar with fixed precision like @bod hinted at before (with cents)
s

Stylianos Gakis

03/14/2023, 11:58 AM
Seems like today every discussion I’m having I always turn out to be wrong about stuff 😅 But hey, the more you know! Thanks for the help and the discussion 🤗
20 Views