deepstream.io client for iOS

[WolframHempel]

Create a deepstream.io client for iOS (Swift / C#), that connects to deepstream via TCP and supports Authentication, Permissioning, Records, Events and RPCs. Additionally, for mobile it might make sense to emphasize on offline storage during connection drops.

Great resources to get started:
Writing a deepstream client
Deepstream Messaging structure
Detailed Cucumber Specs for Incoming and Outgoing messages (and associated behaviors)
Fully featured NodeJS Client as a reference

[sanderpick]

Is there a branch with any work on thing? I'd love to peep it / contribute if so.

[yasserf]

Hey Sanderpick, thank you for reaching out!

We are actually transpiling our objective-c codebase from java using J2OBC. You can see all the artifacts here

The work on the iOS side is creating a swift wrapper, ensuring everything works and creating an pod via CI to publish releases.

I would really appretiate if you can see anything in the API that doesn't make sense in iOS land. Currently the main thing I'm aware of is that we using GSON rather than a native JSON parser.

Thanks!

[NathanFlurry]

I understand you guys are almost done with this already, but I feel that if you insist upon transpiling, it would be better to use Kotlin (which has a Java -> Kotlin transpiler, so it'd be fairly easy to migrate). This will allow you to target Android, iOS/macOS/tvOS/watchOS (in Swift), and JavaScript all at once.

However, I always prefer handwritten implementations of libraries that utilize the native language features. I understand that you are writing a Swift wrapper around the Objective-C, transpiled code, but I'm not convince it will be Swift-y enough (but feel free to prove me wrong!).

Also, just an FYI, I'm about half way done with a pure Swift implementation of the Deepstream client (built on top of vapor/engine, so it works seamlessly on the backend and frontend). Hopefully it'll be finished within two to three weeks, since I'm only working on it in my little free time.

[yasserf]

Hey Nathan,

Thanks for the recommendation! We were actually thinking about having a main Java repo that transpiled to javascript as well, but I agree native implementations are what makes SDKs powerful and alot of javascript would be lost in the move.

Our ( early 2017 ) term milestone is to have a native C++ client that will deal with core functionality and then allow most other languages to call into. This means you'll be able to use the advantages of languages while the core logic ( records / merge issues / timeouts / permissions / etc ) will be written once and not need to be transpiled.

Great news on the swift client! Community editions are always nice, if you could post a link at some point that would be great!

Another thing is we are dropping TCP and EngineIO and will only use Websocket connections going forward. This is because we are using uWS which gives us an insane about of performance improvements and reliability. Just a heads up so you don't spent any time implementing TCP handling!

[viniciusrmcarneiro]

About dropping "TCP and EngineIO".... with the current version... on node environment there is any to not use TCP connection? I looked at the code and I couldn't found any thing.

[arunkjn]

Does dropping EngineIO mean no websocket fallback for browser clients?

[WolframHempel]

We were initially planing a HTTP longpolling fallback, but we've been doing a lot of research in the last couple of weeks and have yet to find a case where it is actually needed. Corporate firewalls are convinced by the current Websocket protocol's initial HTTP-like handshake and subsequent update and websocket support is ubiquitous in browsers http://caniuse.com/#feat=websockets

[WolframHempel]

There are additional benefits as well. E.g. AWS' elastic load balancer and similar distributed load balancers weren't able to maintain sticky sessions between protocols, cookies can be used in a unified fashion etc.