Hi everyone. I have a little bit specific question...

# apollo-kotlin

[Sevban Bayir]

Hi everyone. I have a little bit specific question about apollo's models(data classes) genereated from queries. In a multimodule android project, if we are using REST we'd create DTOs to represent network data and then use mappers to translate these network representations into models we can use in presentation layers. On the other hand when using apollo for android, those DTOs we'd create are already created (generated) by apollo actually. My question is when writing mappers to apollos generated models i feel like im coupling the network layer with data layer more than necessary because in case of graphql is gone than those mappers will be completely useless right ? Im trying to design a scalable codebase and dont want to couple anything more than necessary. Would you suggest creating my own DTOs as network data representations even though apollo creates those models behalf of me, for the sake of loose coupling in mappers ? Your help is much appreciated in advance. Thank you.

[mbonnin]

My 2 cents is I would probably reuse the same models between data & network but I also know there are tons of different views on that question.

[mbonnin]

So I guess what's making you & your team comfortable is your best bet.

[mbonnin]

Saving your data to a DB like Room might be an argument for different data models but if you end up radically changing your API, chances are you'll have to change a bunch of other things too

[agrosner]

Not sure how it’s any different than what you described “if we’re using rest to create DTOS” then using mappers to translate into models in presentation layers. Apollo just does the first part for you..so no change except profit 🤑

[Sevban Bayir]

thanks for your reply but the point is if you rely on grapqhls generated models then you are coupling your project directly to a library. On the other hand if you have DTOs as plain data classes then when networking library changes you dont have to refactor all those imports that come from graphql models, you might just have to change DTO fields

[Eduard Boloș]

First of all, ask yourself very hard, realistically speaking, are you ever going to move away from GraphQL? Chances are that probably not, so your hypothesis is a moot problem.

But to answer your question, your network DTOs, even for REST, will have a certain level of coupling to your API, even if you realise it or not. So if you'd have to move away from your GraphQL API to something else, you'd have to rewrite your hand-rolled network DTOs either way. So what you'd really achieve by this "decoupling" would be to double the amount of work needed for such a hypothetical migration 🙃

So my conclusion would be that it's totally fine to keep Apollo's generated models as your network DTOs. Also, this is an I/O layer, so you really shouldn't care that much about its stability, if you design the rest of your app properly. Which leads me to my next point, which I started to feel quite strongly about: don't leak the generated Apollo models (or any other network or data DTO for that matter) in your other layers (UI, domain). Especially with Apollo, where you have way less control over the generated code, and also the code will reflect the structure of your GQL operations, you want to minimise as much as possible the blast radius in case of any changes in it (e.g. if you extract a GQL fragment).

So yeah, like above said, just map the Apollo generated DTOs to your domain models, and profit 🙂

[Sevban Bayir]

:)) wow, this really helps a lot hahahah. Thank you very much.