Parse Android SDK vs. using GraphQL with Apollo

Client SDKs
#1

Hello,

I’m wondering what are the differences between using the pure Parse Android SDK and using the GraphQL API with Apollo for example. From what I observed:

  • Most of the APIs are available on both
  • Looks like Apollo have great support for persist on the local storage
  • GraphQL adds a bit of complexity and maybe boilerplate where Parse Android SDK take cares of

Besides these are they other cons, pros?
Are they any significant APIs missing?
Can anybody who switched from pure Android SDK to GraphQL with Apollo gives some feedback?

Thanks,
Asen

1 Like
#2

I think you’ve already done a great summary. They have almost the same functionalities implemented. GraphQL brings little more complexity but opens a new world of possibilites (usage of Apollo Client, for example). The only thing that come up in my mind now is the live query. We don’t have GraphQL subscriptions yet so you’d need to continue using Live Query for real time queries.

#3

I was trying to create a pure Kotlin Android SDK, but faced several issues which in Swift Language can be workaround as I can see from the Parse Swift implementation. These issues are regarding the types and serialisation, deserialisation of freeform data lets say, to a strongly typed ones. I realised that actually what I was trying to accomplish is basically implementing Apollo but using the Parse REST APIs, which rings me the bell.

Maybe a little off-topic but @davimacedo - can you bring some light about the future of the Android SDK? Do you guys have plans? I’m interested in collaboration, but unfortunately looks like the Parse Android community is a little bit rusty or sleepy. I know the Android SDK is solid enough, but still…

If I start contributing there to make it up-to-date regarding dependencies and start migrating some stuff to Kotlin for example is there any who can review it?

Regarding the subscriptions, I’m pretty sure there is a one MR for the GraphQL subscriptions, and I remember that is from you, correct me if I’m wrong.

#4

About Subscriptions, yes, I have opened a PR but haven’t the chance to finish it yet.

About the Android SDK, new contributors are very welcome to the project!

#5

@L3K0V The Swift SDK should build for Android and I believe it should be able to work with gradle, but I don’t know much about it:

https://medium.com/android-news/swift-for-android-our-experience-and-tools-7a2f0ba58ab3

Since you have experience, let me know if you are interested and want to pick up this PR:

#6

Hey @cbaker6,

I will take a look probably next week. Interesting finding you got there. I’m not sure about who will gonna use it at it should be used via JNI and the footprint as I read is 35mb because of the core libraries which are bundled.

Do you have something particular in mind with this Swift build for Android?

I think the more suitable and standard way is actually writing everything in Kotlin using multi platform module (KMM - https://kotlinlang.org/lp/mobile/) and build both Swift and Kotlin libraries to be consumed

#7

You might be right, I’ve heard swift builds on Android tend to be large. My original goal is to get a basic build for CI to make sure the SDK always builds for Android.

Get a basic build for Android, similar to the Linux build

This could work. I don’t know much about Android or Kotlin, but from what I understand there needs to be some underlying framework Kotlin would need access to. The JS and Swift SDKs seem to have the most up-to-date features with respect to the server. Flutter seems to be next, but doesn’t have adequate CI testing. The Android and iOS SDKs have the fundamental features, but are missing a lot when compared to JS and Swift SDKs.

#8

In this case I will find some time next week and will try making it work.

Any idea who is supporting the Android SDK now? After my not so successful attempt to create pure Kotlin SDK, I’m thinking - first to update all dependencies of the current Android SDK and start migrating to Kotlin. (Currently It’s building, working and the tests runs, but it’s very behind, eg. firebase is not working anymore with the recent versions) Next will be to start with some massive refactoring like replacing bolts with native Kotlin coroutines. And later on the problematic “state” pattern which I saw has a lot of issues reported around recursive persistence. Last but not least adding all missing JS features and subscriptions similar to the Kotlin PoC where you can have stream of results using live queries.

#9

There are two approaches here. Wrapping the existing SDK with KMM or writing the core in Kotlin and maintaining only single source code targeting multiple platforms. But as you know I stuck with my Kotlin PoC. Using the first wrapping approach actually does not come with any benefits. Maybe we can check if we can wrap the Swift SDK instead building it for the JVM…

#10

I’m not sure of the maintaining process for the Android SDK. My suggestion would be to start submitting issues/PRs and I’m sure someone from the Parse Core Team will get them reviewed

This sounds reasonable, then Kotlin devs should benefit from the updated Swift SDK