Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deepstream.io client for iOS #68

Closed
WolframHempel opened this issue Jan 13, 2016 · 9 comments

Comments

@WolframHempel
Copy link
Member

@WolframHempel WolframHempel commented Jan 13, 2016

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

This comment has been minimized.

Copy link

@sanderpick sanderpick commented Sep 19, 2016

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

@yasserf

This comment has been minimized.

Copy link
Member

@yasserf yasserf commented Sep 20, 2016

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

This comment has been minimized.

Copy link

@NathanFlurry NathanFlurry commented Oct 3, 2016

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

This comment has been minimized.

Copy link
Member

@yasserf yasserf commented Oct 3, 2016

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

This comment has been minimized.

Copy link

@viniciusrmcarneiro viniciusrmcarneiro commented Oct 3, 2016

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

This comment has been minimized.

Copy link

@arunkjn arunkjn commented Oct 3, 2016

Does dropping EngineIO mean no websocket fallback for browser clients?

@WolframHempel

This comment has been minimized.

Copy link
Member Author

@WolframHempel WolframHempel commented Oct 3, 2016

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

This comment has been minimized.

Copy link
Member Author

@WolframHempel WolframHempel commented Oct 3, 2016

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.

@yasserf

This comment has been minimized.

Copy link
Member

@yasserf yasserf commented Aug 13, 2017

This has been done a while ago by converting the java codebase! Yaay

@yasserf yasserf closed this Aug 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.