
Telepat: Real-Time, Open Source Data Sync - kanche
http://telepat.io/
======
gabidobocan
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)

~~~
fit2rule
I would love to have a way to use your system with Lua ..

~~~
andreimarinescu
Noted. Would probably make for some nice use-cases as well. No ETA of course,
but we'll do some digging :)

------
dal
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..

~~~
razvan_botea
Thanks for your suggestion, we've just updated the link :)

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

~~~
gabidobocan
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
Thank you for the clarification!

------
guidouil
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
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
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.

------
wilsonfiifi
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
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) .

------
oDot
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
They make a comparison in their Docs.
[http://docs.telepat.io/#comparison](http://docs.telepat.io/#comparison)

~~~
oDot
Thanks!

EDIT: looks like the comparison is Derby only - racer is a bit more flexible
IMO

~~~
gabidobocan
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.

------
itsyogesh
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
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

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

~~~
gabidobocan
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
So if two users are working on the same textfield there is no way to merge
their changes at the moment?

~~~
gabidobocan
Not yet - unless you do it client-side. We're working on having a proper
implementation for this use case.

------
adim86
How do they make money?

~~~
wilsonfiifi
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
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.

------
justinkelly
looks great - will you been adding offline support?

mainly ability to sync changes made offline on clients back to server and
handle conflicts?

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

------
EGreg
Looks really awesome!

~~~
andreimarinescu
Thanks! If you end up using telepat and have any questions / feedback, feel
free to ping us @ founders@telepat.io

~~~
avtar
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
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.

