For a type like this in the schema

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?

You could patch your schema and define your scalar type client side. It's a bit hacky but that'd work

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

I think that'd work

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.

Isn't the usual thing with Money that you want bigint or anything to avoid loosing (or winning) money due to rounding errors?

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.

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 👍

I'd recommend using strings on the wire

I'm team 'Float', it makes it explicit that it's not for computations but for display (if that is what it really is)

isn't String even more explicit about it being for display? 🙂

Yea I guess so, if it were for computation, I'd expect a custom scalar

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.

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?

Losing precision and also losing network bytes

Losing precision and also losing network bytes

So are you team String now too? 😂

Nope, losing network bytes is a good thign

Oh, losing, as in less, not "losing space" aka taking up more space 💀

yep!

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 🤗