[erlang-questions] Is Erlang a good tool for this particular project?

[Chad DePue]

Matthew,

Inaka has built native applications exactly like this for iPad and iPhone
and started w/HTTP-comet style polling and we started with comet-style long
polling but ended up at simple REST for the api commands and a TCP socket
connection for the persistant stuff... The socket is far more efficient and
quite simply with a mobile app there's no need to use long-polling.

We also use Rails for admin but Erlang for all API commands, even HTTP. Ping
me off-list and I can share some of what we learned.

Chad DePue
inakanetworks.com - development consulting | skype cdepue | @chaddepue
+1 206.866.5707



On Tue, Jul 12, 2011 at 5:25 PM, Matthew Hillsborough <
matthew.hillsborough@REDACTED> wrote:

> Greetings Erlang community,
>
> Let me further elaborate on my question that's in the subject of this
> message. I tried to reach out with this question on StackOverflow, however I
> did not have much luck there. Perhaps the community here can provide some
> feedback here for me to let me know if I'm on the right track or if Erlang
> is not the right tool for what I'm trying to accomplish.
>
> I'm building native mobile applications in both iOS and Android. These apps
> require "realtime" updates from and to the server, same as many (but not
> all) network-based application does (Facebook, social games like Words with
> Friends, Finance applications, etc). The communication here is
> bi-directional, in the sense that the server might have updates for the
> mobile clients and the clients will be pushing data down to the server
> whenever necessary.
>
> I think using HTTP long polling for this is over kill in the sense that
> long polling can be detrimental to battery life, especially with a lot of
> TCP setup/teardown for every HTTP connection the device needs to send out
> through the wire. It might make sense to have the mobile applications use
> persistent TCP sockets to establish a connection to the server, and send RPC
> style commands to the server for all web service communication. This
> ofcourse, would require a server to handle the long-lived TCP connection and
> be able to speak to a web service once it makes sense of the data passed
> down the TCP pipe. I'm thinking of passing data in plain text using JSON or
> XML and then using some kind of Erlang interface to HTTP to call a web
> service to handle all the REST type communication. The responses would then
> go back to the "RPC" Erlang instance, which would send the updates to the
> appropriate client(s).
>
> Perhaps an Erlang based RPC server would do well for a network based
> application like this. It would allow for the mobile apps to send and
> receive data from the server all over one connection without multiple
> setup/tear down that individual HTTP requests would do. Since no web browser
> is involved, we do not need to deal with the nuances of HTTP long-polling at
> the mobile client level. I also haven't seen great long polling/keep-alive
> support on the client-side in iOS, but that's irrelevant for the community
> here.
>
> A lot of these "COMET" and long-polling/streaming servers are built with
> HTTP in mind. I'm thinking just using a plain-text protocol over TCP is
> better catered for the type of app I'm building, will make the client more
> responsive, allow for receiving of updates from the server without
> constantly polling the server, etc.
>
> I also looked into HTTP pipelining, but it doesn't look to be worth the
> trouble when it comes to implementing it on the clients. Also, I'm not sure
> if it would allow for bi-directional communication in the client<->server
> communication channel.
>
> Am I completely out of line in thinking that building a custom solution in
> Erlang is a good idea here? To my understanding, Erlang excels at servers
> like this, and if I run the server on tcp/80, I should be able to avoid most
> firewall/port issues. The client would need work to deal with timeouts, re
> connections, acknowledging receipt of asynchronous requests, but that's not
> Erlang's problem.
>
> Has anyone built something similar before? Should I just stick to a web
> server and deal with "COMET" type technologies? (WebSockets, long-polling,
> client-side polling).
>
> Was hoping someone could solidify that I'm not entirely insane for wanting
> a better solution than HTTP would serve in this case, at least at the client
> level. I'll still be using HTTP/REST extensively, the Erlang server would
> just handle the persistent connections and messaging to the Web Service
> (which would probably be something like Django or Rails).
>
> Sorry for the long post; I am just excited to get into the heads of people
> who are smarter than I.
>
> Happy hacking!
>
> Matthew
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110714/66be29cd/attachment.htm>