Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Simperium, a realtime data layer

simperium.com

Post reply on HN
Print view View original

81–90 of 90 posts

Re: Show HN: Simperium, a realtime data layer

#81

Post by andy_gayton »

saurik wrote: post #71

One thing that came up in the discussion about some other related offerings (such as Firebase) is the question: "what is your durability story"? When I'm spending the time to store things for my company, I make certain to ask such questions as "is this data important enough to keep on multiple servers, or is having a backup sufficient". When storing data in services provided and managed by other companies, it becomes…

Important question saurik! Our primary store is mongo. All data is replicated in different availability zones and at least one additional replica which is kept in a different ec2 region. A running snapshot backup is also taken at least every 30 minutes. Simperium isn't a messaging service. Every change is persisted and versioned. So for the Simplesmash demo, you could have a slider that would allow you to go back in time and replay movements. A note on versions: they are stored in an RRD like fashion. At first every version is kept, and as they accumulate; older versions are compacted and become less granular. We plan on making what level of granularity is kept an adjustable option in the future.

Re: Show HN: Simperium, a realtime data layer

#82

Post by cloudmike »

saurik wrote: post #70
ecksor wrote: post #41

Earlier quoted context omitted.

Correct, each object is on a separate timeline for purposes of operational transform. If both clients are connected at the time the changes are made, then it shouldnt be possible to see the second change before the first. We keep an ordered history of all changes to all objects, though for efficiency, if a client that wasn't present when changes were initially made syncs, changes to multiple objects may appear in a d…

Ok, with those semantics (and I think I understand the basis implementations that would cause them), do you perform the "resync" step (which has the property that you can at least get the catch-up changes in a single bulk and hopefully fast download for the entire bucket, even with the internal reordering that happened over time) as a single transaction (by locking the persistant store coordinator); and if not, why?…

There's currently no explicit lock or transaction, but due to the way we're multithreading, multiple changes are propagated back to your context in one shot.

Core Data relationships (including their inverses) that come over the wire can be lazily resolved by Simperium if necessary.

Re: Show HN: Simperium, a realtime data layer

#83

Post by zbowling »

Void_ wrote: post #72
zbowling wrote: post #62

This is interesting. We built something very much like this internally at SeatMe. On the iOS side, it's almost identical. It's how we keep our iPads up to date. Might not of built something internally ourselves a year ago if there was a platform like this. The biggest difference is that since we are not a general platform, we can make assumptions about the model and how version each release and we can built in some c…

Any argument against using CocoaPods for managing ASIHTTPRequest, Socket.IO, etc.? Renaming seems like an ugly solution.

As a library library writer, if you are going to include dependencies, you have to rename pretty much everything.

Objective-C is dynamic and the last implementation wins if they are named the same so it's possible for third party libs to suddenly smash your implementation.

Re: Show HN: Simperium, a realtime data layer

#84

Post by akrymski »

cloudmike wrote: post #79
akrymski wrote: post #77

Earlier quoted context omitted.

Another interesting approach is: - CouchDB - PouchDB: https://github.com/daleharvey/pouchdb - Backbone PouchDB Adapter: https://github.com/jo/backbone-pouchdb But the Map-Reduce paradigm didn't seem to fit well onto our data model.

Our goal on the client-side (compared to CouchDB) was simpler, more lightweight libraries that work well with existing tools that developers already use, like Core Data on iOS and sqlite/ContentProviders on Android. Whereas CouchDB does master-master replication among instances of itself, Simperium can accomplish something similar with any database: e.g. sqlite on iOS, to MongoDB in our backend, and to whatever datab…

Just strange that you don't support offline for web apps, only iOS & Android, even though web apps can use websql.

That's probably cause you're used to writing native iOS apps, but we're attempting a web app that works via phonegap across all devices from one source code base.

So for us storing all the data in Backbone collections isn't an option - models add too much memory overhead, versus native JSON objects.

As I understand multiple collections update independently of each other? How do you deal with relational data in that case?

Re: Show HN: Simperium, a realtime data layer

#85

Post by daleharvey »

akrymski wrote: post #77
akrymski wrote: post #75

Guys congrats on the launch! I was wondering what was taking you so long ;) Very exciting stuff! I'm amazed that we're on the same wavelength - we've had to build very similar infrastructure for ourselves for Unipost (www.post.fm). Can't believe we didn't collaborate on this, we'd happily be your first customer :( A few interesting differences: - Our approach is more like Meteor - web only, no iOS support - The backe…

Another interesting approach is: - CouchDB - PouchDB: https://github.com/daleharvey/pouchdb - Backbone PouchDB Adapter: https://github.com/jo/backbone-pouchdb But the Map-Reduce paradigm didn't seem to fit well onto our data model.

The map reduce paradigm isnt particularly core to PouchDB, it mostly in there for completion, I expect a fairly large amount of more powerful and easier to use querying mechanisms on top of PouchDB

The data syncing is by far the priority

Re: Show HN: Simperium, a realtime data layer

#86

Post by mainsocial »

cloudmike wrote: post #80
arturadib wrote: post #76

I've been a SimpleNote user for a while, great to see the platform layer finally coming out. I have a few questions: - As a potential customer, I'm curious as to how sustainable is the company. I understand there was a YC seed investment in '10, but is the company well funded for the next couple of years at least? - The platform seems to be ahead of Meteor, Firebase, etc, in that it already seems to have implemented…

By "finer grained control" we mean control over expirations and read/write permissions for a particular token. It's definitely not possible to erase/modify data from other users. An example of where read-only permissions are useful is the live dashboard you see at simperium.com after you sign in. The "number of syncs" and alerts at the top are all pulled live from Simperium, but the token used on that page is a read-…

I'm dying to use this, but the ability to create read-only tokens is important for all the applications I have in mind. Do you have a sense of where this is in your priority queue, or even when you might be able to expose an HTTP endpoint?

Re: Show HN: Simperium, a realtime data layer

#87

Post by cloudmike »

mainsocial wrote: post #86
cloudmike wrote: post #80

Earlier quoted context omitted.

By "finer grained control" we mean control over expirations and read/write permissions for a particular token. It's definitely not possible to erase/modify data from other users. An example of where read-only permissions are useful is the live dashboard you see at simperium.com after you sign in. The "number of syncs" and alerts at the top are all pulled live from Simperium, but the token used on that page is a read-…

I'm dying to use this, but the ability to create read-only tokens is important for all the applications I have in mind. Do you have a sense of where this is in your priority queue, or even when you might be able to expose an HTTP endpoint?

Yes, support for this is imminent. But I believe you know that now since we're already in touch with you.

Re: Show HN: Simperium, a realtime data layer

#88

Post by cloudmike »

akrymski wrote: post #84
cloudmike wrote: post #79

Earlier quoted context omitted.

Our goal on the client-side (compared to CouchDB) was simpler, more lightweight libraries that work well with existing tools that developers already use, like Core Data on iOS and sqlite/ContentProviders on Android. Whereas CouchDB does master-master replication among instances of itself, Simperium can accomplish something similar with any database: e.g. sqlite on iOS, to MongoDB in our backend, and to whatever datab…

Just strange that you don't support offline for web apps, only iOS & Android, even though web apps can use websql. That's probably cause you're used to writing native iOS apps, but we're attempting a web app that works via phonegap across all devices from one source code base. So for us storing all the data in Backbone collections isn't an option - models add too much memory overhead, versus native JSON objects. As I…

Consistent browser support for storage (besides localStorage) is still quite frustrating. It's improving though and we're on it.

You can model relational data in Backbone quite effectively, or use another library (or your own). For example: https://github.com/PaulUithol/Backbone-relational/

Re: Show HN: Simperium, a realtime data layer

#90

Post by dbfreq »

Are there any recommendations for the maximum size of a data set used with Simperium? It looks like the perfect solution for a back office app for a small business, but I'd like to know if I will be running into a brick wall at some point.

Clients will be iOS and Mac OS X only, using Core Data.

Thanks.

Brad

Post reply on HN