6 ms·

Telepat: Real-Time, Open Source Data Sync

100 points by kanche 11y ago

EGreg 11y ago
Looks really awesome!
- andreimarinescu 11y ago
  Thanks! If you end up using telepat and have any questions / feedback, feel free to ping us @ founders@telepat.io
  - avtar 11y ago
    Great work on the architecture documentation. I'm looking at your repos on Github and I'm curious about something. What are you using to test telepat-api, workers, and the integration with all the third party projects listed in the docs?
    - razvan_botea 11y ago
      We're using a combination of should, assert, supertest, mocha and istambul right now. We're still working on a larger code coverage, but we will be releasing the tests along with our next release.
- deleted 11y ago
  [deleted]
dal 11y ago
I don't like the fact that the Tux logo is linked to http://linux.com http://linux.com Should be http://kernel.org http://kernel.org as linux.com has a spammy feeling..
- deleted 11y ago
  [deleted]
- razvan_botea 11y ago
  Thanks for your suggestion, we've just updated the link :)
itsyogesh 11y ago
Like your usecase for implementing 1 to 1 chat, is there any chance you are adding examples to the repo. Would love to see how it can be implemented.
- andreimarinescu 11y ago
  We're actually working on a full example with code and a short video, we'll add this to our website and github repos as soon as it's done
adim86 11y ago
How do they make money?
- wilsonfiifi 11y ago
  1) Professional/Consulting services and support for paid users 2) Hosted version (SAAS) 3) Book deal 4) Paid client/server plugins for additional functionality 5) Get "aqui-hired" 6) Enterprise version that's more stable and battle tested 7) etc...
  - sebivaduva 11y ago
    Number 2 is coming up first, later this fall: public cloud with a generous free tier for developers and some paid ones for companies that scale. We'll share updates along the road, meanwhile - we're eager to talk to developers that are tackling real-time and refine the product together.
wilsonfiifi 11y ago
This is great stuff! I was wondering though, looking at the stack, if some parts couldn't be substituted with "lighter" alternatives? I'm assuming couchbase is being used for the changes feed and since you can't do adhoc querying you need "elastic search" for that, however wouldn't it be possible to replace both with just rehinkdb? Anyway I'm just speculating here, I should probably dig into the code. Thanks for sharing this and keep up the good work! Update: seems you'll still need elastic search for rethinkdb full text search [0] [0] http://www.rethinkdb.com/docs/elasticsearch/ http://www.rethinkdb.com/docs/elasticsearch/
- kanche 11y ago
  I think the creators are https://github.com/gabidobo https://github.com/gabidobo and https://github.com/Mayhem93 https://github.com/Mayhem93 I was searching for a good framework for an online booking system, and though one link and other stumbled upon this. I have't heard about it before, so I thought it would be nice to share it with HN; github repo seems to have a low involvement from anyone outside the creators https://github.com/telepat-io https://github.com/telepat-io .
- andreimarinescu 11y ago
  We're working on providing plugins for a wide range of components, so that you can switch couchbase, kafka or elastic for other, lighter products that you might have on your stack already
jsilence 11y ago
Just curious: How is this different from the MQTT ecosystem?
- gabidobocan 11y ago
  Good question, we get this asked a lot (usually in relation with companies such as PubNub or Pusher.io). It's different in a number of ways: - it's compatible with any number of protocols (we call them transports). Currently, we support websockets, APNS and GCM. MQTT could easily be added as a transport protocol for subscribing to channels - it also handles data aggregation (for example if you have a large number of updates on an object in a short amount of time, the system will aggregate them and send only the relevant updates to the subscriber) - it's more open (in my opinion) as it's designed to enable developers to swap out one component for another (and writing a thin adapter for it if it's not already available). This should also mean that the whole system can be better optimized depending on the workload type and use-case.
  - jsilence 11y ago
    Thank you for the clarification!
gabidobocan 11y ago
Hey everyone, one of the founders here! We've written a blog post that pretty much sums up our vision on real time infrastructures and our drive for this product. Have a look: http://blog.telepat.io http://blog.telepat.io
- cpach 11y ago
  Cool! Permalink for future readers: http://blog.telepat.io/2015/08/17/hello-world/ http://blog.telepat.io/2015/08/17/hello-world/ :)
- fit2rule 11y ago
  I would love to have a way to use your system with Lua ..
  - andreimarinescu 11y ago
    Noted. Would probably make for some nice use-cases as well. No ETA of course, but we'll do some digging :)
justinkelly 11y ago
looks great - will you been adding offline support? mainly ability to sync changes made offline on clients back to server and handle conflicts?
- gabidobocan 11y ago
  Thanks! Offline support is on the roadmap - the iOS and Android clients actually already use a local database, so we're nearly there.
janmonschke 11y ago
Which strategy do you use to sync data? (e.g. in the context of collaborative editing)
- gabidobocan 11y ago
  Collaborating on different properties of a single object is no problem; for working on the same property we don't do diff/merge yet, it's just FIFO.
  - janmonschke 11y ago
    So if two users are working on the same textfield there is no way to merge their changes at the moment?
    - gabidobocan 11y ago
      Not yet - unless you do it client-side. We're working on having a proper implementation for this use case.
oDot 11y ago
Hi, for node-only usage, how is this different from Racer[0] (part of DerbyJS)? [0]: https://github.com/derbyjs/racer https://github.com/derbyjs/racer
- gawry 11y ago
  They make a comparison in their Docs. http://docs.telepat.io/#comparison http://docs.telepat.io/#comparison
  - oDot 11y ago
    Thanks! EDIT: looks like the comparison is Derby only - racer is a bit more flexible IMO
    - gabidobocan 11y ago
      Racer is great at synchronizing objects, and more flexible than Derby. One key difference between Racer and Telepat is that the Racer client needs to run within a JS container, while Telepat offloads native functionality to native clients. I'd say we're more mobile and user-access oriented than Racer, basically, but we're more architecturally apart as well.
guidouil 11y ago
I think your comparison with Meteor is not fair. You are not obliged to use Meteor in back and front, you can have a meteor backend and load a DDP client in about any language. And as I'm doing one right now you can have a only front application talking to a rest server. So it's more flexible than what you tell in your comparison. Also I might not be fair because I'm a Meteor addict :D
- andreimarinescu 11y ago
  Thanks, we'll revisit this and check our comparison, we haven't used Meteor extensively so far, so we might have missed stuff. The reason we have that comparison section is that we get asked about this quite a lot, so we wanted to have a public statement on what we think the main differences are from similar products.
  - rgoomar 11y ago
    To comment further on that, here's some more information for you guys based on the comparison notes: * Meteor is a solution for both frontend and backend development, while Telepat focuses on backend functionality. - You can use it for just the backend if you want. This statement is true, but just noting that you don't have to use both sides. * When using Meteor in the backend, you also need to use it in your frontend app. Telepat lets you use any frontend framework. - You don't have to use it with just Meteor's front end (which is I think what you meant). It has integrations with other front end frameworks and you could use it with just about any front end framework as long as you add some boilerplate to communicate with the client-side store and DDP. * Meteor is a solution for creating webapps, and running on mobile devices works only via webviews. Telepat enables native clients and native functionality for mobile or embedded. - Not true actually. They make it the easiest to get mobile apps out with Cordova and webviews, but there are various libraries out there like the ObjectiveC-DDP or meteor-ios library that integrates natively with iOS applications. * Telepat allows using adapters for 3rd party databases, messaging queues and push transports. - You can do this with Meteor as well and integrate NPM packages. I hope that helps shed some light on the comparison. The platform looks great though. I'll definitely have to take a look at it sometime soon.

100 points by kanche 11y ago

EGreg 11y ago

Looks really awesome!

andreimarinescu 11y ago
Thanks! If you end up using telepat and have any questions / feedback, feel free to ping us @ founders@telepat.io
- avtar 11y ago
  Great work on the architecture documentation. I'm looking at your repos on Github and I'm curious about something. What are you using to test telepat-api, workers, and the integration with all the third party projects listed in the docs?
  - razvan_botea 11y ago
    We're using a combination of should, assert, supertest, mocha and istambul right now. We're still working on a larger code coverage, but we will be releasing the tests along with our next release.
deleted 11y ago
[deleted]

dal 11y ago

I don't like the fact that the Tux logo is linked to http://linux.com http://linux.com Should be http://kernel.org http://kernel.org as linux.com has a spammy feeling..

deleted 11y ago
[deleted]
razvan_botea 11y ago
Thanks for your suggestion, we've just updated the link :)

itsyogesh 11y ago

Like your usecase for implementing 1 to 1 chat, is there any chance you are adding examples to the repo. Would love to see how it can be implemented.

andreimarinescu 11y ago
We're actually working on a full example with code and a short video, we'll add this to our website and github repos as soon as it's done

adim86 11y ago

How do they make money?

wilsonfiifi 11y ago
1) Professional/Consulting services and support for paid users 2) Hosted version (SAAS) 3) Book deal 4) Paid client/server plugins for additional functionality 5) Get "aqui-hired" 6) Enterprise version that's more stable and battle tested 7) etc...
- sebivaduva 11y ago
  Number 2 is coming up first, later this fall: public cloud with a generous free tier for developers and some paid ones for companies that scale. We'll share updates along the road, meanwhile - we're eager to talk to developers that are tackling real-time and refine the product together.

wilsonfiifi 11y ago

This is great stuff! I was wondering though, looking at the stack, if some parts couldn't be substituted with "lighter" alternatives? I'm assuming couchbase is being used for the changes feed and since you can't do adhoc querying you need "elastic search" for that, however wouldn't it be possible to replace both with just rehinkdb? Anyway I'm just speculating here, I should probably dig into the code. Thanks for sharing this and keep up the good work! Update: seems you'll still need elastic search for rethinkdb full text search [0] [0] http://www.rethinkdb.com/docs/elasticsearch/ http://www.rethinkdb.com/docs/elasticsearch/

kanche 11y ago
I think the creators are https://github.com/gabidobo https://github.com/gabidobo and https://github.com/Mayhem93 https://github.com/Mayhem93 I was searching for a good framework for an online booking system, and though one link and other stumbled upon this. I have't heard about it before, so I thought it would be nice to share it with HN; github repo seems to have a low involvement from anyone outside the creators https://github.com/telepat-io https://github.com/telepat-io .
andreimarinescu 11y ago
We're working on providing plugins for a wide range of components, so that you can switch couchbase, kafka or elastic for other, lighter products that you might have on your stack already

jsilence 11y ago

Just curious: How is this different from the MQTT ecosystem?

gabidobocan 11y ago
Good question, we get this asked a lot (usually in relation with companies such as PubNub or Pusher.io). It's different in a number of ways: - it's compatible with any number of protocols (we call them transports). Currently, we support websockets, APNS and GCM. MQTT could easily be added as a transport protocol for subscribing to channels - it also handles data aggregation (for example if you have a large number of updates on an object in a short amount of time, the system will aggregate them and send only the relevant updates to the subscriber) - it's more open (in my opinion) as it's designed to enable developers to swap out one component for another (and writing a thin adapter for it if it's not already available). This should also mean that the whole system can be better optimized depending on the workload type and use-case.
- jsilence 11y ago
  Thank you for the clarification!

gabidobocan 11y ago

Hey everyone, one of the founders here! We've written a blog post that pretty much sums up our vision on real time infrastructures and our drive for this product. Have a look: http://blog.telepat.io http://blog.telepat.io

cpach 11y ago
Cool! Permalink for future readers: http://blog.telepat.io/2015/08/17/hello-world/ http://blog.telepat.io/2015/08/17/hello-world/ :)
fit2rule 11y ago
I would love to have a way to use your system with Lua ..
- andreimarinescu 11y ago
  Noted. Would probably make for some nice use-cases as well. No ETA of course, but we'll do some digging :)

justinkelly 11y ago

looks great - will you been adding offline support? mainly ability to sync changes made offline on clients back to server and handle conflicts?

gabidobocan 11y ago
Thanks! Offline support is on the roadmap - the iOS and Android clients actually already use a local database, so we're nearly there.

janmonschke 11y ago

Which strategy do you use to sync data? (e.g. in the context of collaborative editing)

gabidobocan 11y ago
Collaborating on different properties of a single object is no problem; for working on the same property we don't do diff/merge yet, it's just FIFO.
- janmonschke 11y ago
  So if two users are working on the same textfield there is no way to merge their changes at the moment?
  - gabidobocan 11y ago
    Not yet - unless you do it client-side. We're working on having a proper implementation for this use case.

oDot 11y ago

Hi, for node-only usage, how is this different from Racer[0] (part of DerbyJS)? [0]: https://github.com/derbyjs/racer https://github.com/derbyjs/racer

gawry 11y ago
They make a comparison in their Docs. http://docs.telepat.io/#comparison http://docs.telepat.io/#comparison
- oDot 11y ago
  Thanks! EDIT: looks like the comparison is Derby only - racer is a bit more flexible IMO
  - gabidobocan 11y ago
    Racer is great at synchronizing objects, and more flexible than Derby. One key difference between Racer and Telepat is that the Racer client needs to run within a JS container, while Telepat offloads native functionality to native clients. I'd say we're more mobile and user-access oriented than Racer, basically, but we're more architecturally apart as well.

guidouil 11y ago

I think your comparison with Meteor is not fair. You are not obliged to use Meteor in back and front, you can have a meteor backend and load a DDP client in about any language. And as I'm doing one right now you can have a only front application talking to a rest server. So it's more flexible than what you tell in your comparison. Also I might not be fair because I'm a Meteor addict :D

andreimarinescu 11y ago
Thanks, we'll revisit this and check our comparison, we haven't used Meteor extensively so far, so we might have missed stuff. The reason we have that comparison section is that we get asked about this quite a lot, so we wanted to have a public statement on what we think the main differences are from similar products.
- rgoomar 11y ago
  To comment further on that, here's some more information for you guys based on the comparison notes: * Meteor is a solution for both frontend and backend development, while Telepat focuses on backend functionality. - You can use it for just the backend if you want. This statement is true, but just noting that you don't have to use both sides. * When using Meteor in the backend, you also need to use it in your frontend app. Telepat lets you use any frontend framework. - You don't have to use it with just Meteor's front end (which is I think what you meant). It has integrations with other front end frameworks and you could use it with just about any front end framework as long as you add some boilerplate to communicate with the client-side store and DDP. * Meteor is a solution for creating webapps, and running on mobile devices works only via webviews. Telepat enables native clients and native functionality for mobile or embedded. - Not true actually. They make it the easiest to get mobile apps out with Cordova and webviews, but there are various libraries out there like the ObjectiveC-DDP or meteor-ios library that integrates natively with iOS applications. * Telepat allows using adapters for 3rd party databases, messaging queues and push transports. - You can do this with Meteor as well and integrate NPM packages. I hope that helps shed some light on the comparison. The platform looks great though. I'll definitely have to take a look at it sometime soon.