search

DerZyklop / hitchhikr

0 stars 0 forks source link

evaluating socket.io #28

Closed DerZyklop closed 10 years ago

DerZyklop commented 10 years ago

maybe this is interesting for os... maybe not.

i have read some texts about it. it basically abstracts and simplifies the transmission between server and client. so that one don't have to worry about which protocol or technology to use.

when i got the idea correct then we wont need it in case we use hoodie. but i didn't get hoodie to work as mentioned in #25.

DerZyklop commented 10 years ago

@mssimor i assigned you to it because this is backend/database-stuff.

mssimor commented 10 years ago

I had a quick look at socket.io and from my point of view it is "just" a node module implementing websockets.

So the problems i see here are the following: It just abstracts and simplifies websockets on the the server/backend side. There is no persisting of the data involved at all (aka no use of a database) - therefore no synchronization of any data. This means we would have to implement all this "hairy" bits on our own! In addition it does not provide user authentication or a client side JS-Lib as Hoodie does.

A quick Google search led me over here: http://nobackend.org/solutions.html I had heard about Firebase in context of Angular, because it's promoted as the preferred persistence solution for Angular Apps. Unfortunately Firebase and Parse are hosted services and are not for free - at least if our user base grows. Backendless is basically for free but it can't be self hosted. I'd would prefer a self hosted solution and i guess you would too? So i think we should evaluate dployed and remoteStorage and should also keep an eye on Hoodie.