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

Cool! Permalink for future readers: http://blog.telepat.io/2015/08/17/hello-world/

:)

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

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

I don't like the fact that the Tux logo is linked to http://linux.com

Should be http://kernel.org as linux.com has a spammy feeling..

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

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

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.

Thank you for the clarification!

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

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.

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.

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/

I think the creators are https://github.com/gabidobo and 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 .

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

Hi, for node-only usage, how is this different from Racer[0] (part of DerbyJS)?

[0]: https://github.com/derbyjs/racer

They make a comparison in their Docs. http://docs.telepat.io/#comparison

Thanks!

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

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.

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.

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

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

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.

So if two users are working on the same textfield there is no way to merge their changes at the moment?

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

How do they make money?

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

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.

looks great - will you been adding offline support?

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

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

Looks really awesome!

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

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?

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.