Hacker News Reader

Comment by yasserf | Hacker News Reader

thanks for the feedback! Do you mean in the actual Hero or to elaborate more within the 'what it is' section on the home page?

View on HN

I spent 5 minutes trying to figure out what Deepstream, because I was intrigued. I was unable to figure it out based on the front page, documentation link and the GitHub repo.

What sort of documentation would make most sense? We went through iterations of example animated apps, code samples and text but can't seem to explain it clearly yet =( Any input would be much appreciated!

I think Facebook does a fantastic job of demonstrating the value of their tooling that they open source.

Buck: https://buck.build/

Presto: http://prestodb.github.io/

The front page of these contain the project name, one-line elevator pitch, long form description, and an automatically playing demo of the product.

This is a great comment. I've come across deepstream over the years. I've always come away thinking that I could make something similar that would serve my needs without adding a dependency into my project. You need to demonstrate some compelling feature.

Eg. sync

Naive copy sync: 53ms

DeepStream sync: 6ms

I would say the compelling feature is it's opensource 'serverless' data-sync with permissions, clustering, monitoring and auth built in. Serverless here meaning there is no server code required, just run the server. The easiest way to market it would just be the OS competitor to firebase.

The issue with that however is taking that approach means we lose the NodeJS ecosystem support which is massive (and required to add custom plugins/maintain the server). We tried it before and it was terrible in terms of metrics and participation.

Thank you for the feedback though! I will definitely be looking at redesigning the home page and will use your feedback when doing so!

> The issue with that however is taking that approach means we lose the NodeJS ecosystem support which is massive (and required to add custom plugins/maintain the server).

Could you explain what you mean here in greater detail? I'm only talking about changing your marketing copy. I don't understand why you lose the NodeJS ecosystem.

By the way I'd also remove most of the content from the front page. It's too busy. Make every word count.

Yeah when we made deepstream sound more like a standalone deployment, similar to nginx or rethinkdb (meaning you can get an executable/install via package managers and so forth) and downplayed the NodeJS part of it we ended up having alot less people contribute to the project or even using it as they wouldn't be aware that it could be installed via NPM. I guess my point is that the status quo of node server dependencies seem to be run as part of a bigger project (featherjs, meteor, socket.io, sockeetcluster) which means you npm install and configure it via javascript. The last couple versions have been me trying to navigate the landscape so I can provide a totally standalone/configuration based server that can also be extended by end users (hence all the typescript interfaces and support).

Basically I'm not certain how to pitch this exactly. I feel a bit of condolence from the fact that when it was a startup with over ten employees we had the same issue (specially since I was the tech guy)

Anyways, more than happy to hear any suggestions! I been involved with this project for over 3 years so I definitely have a biased view on trying to see the project for the first time.

I'd focus on sync as your headline feature. It's technologically complex to do well and it provides real value for mobile apps that want to do a great offline experience. Our phones are offline way more than most of us realize and we don't notice it because Google / Apple have did such a great job with sync. But many 3rd party apps are not great at that and consequently have crappier user experiences due to connectivity problems.

That's really not what serverless means (especially when right after you say just run the server). Id recommend leaving that out. Less buzzwords are better.

Just describe what deep stream is in one sentence on your landing page. Right at the top. "Deepstream is a pubsub solution that ...".

It isn't just a pubsub solution though

To compare to other frameworks out there:

featherjs: A framework for real-time applications and REST APIs

meteor: THE FASTEST WAY TO BUILD JAVASCRIPT APPS

deepstream: a fast and secure data-sync realtime server for mobile, web & iot

The problem is that once you provide more functionality then pub/sub you end up in this vague toolkit statement land.

I would assume that the issue is more around the fact that the term data synchronization is still not used as often and so doesn't give the same familiar feeling people get when looking at other pub/sub frameworks. Deepstream supports HTTP/MQTT/Binary and JSON websocket protocols for rpcs, records, events and presence. Maybe that should be the sentence!

A secure scalable realtime server that supports HTTP, MQTT and WebSockets for rpcs, data-sync, pubsub and presence functionality

Just my opinion, but the two most useful pieces of information that helped me understand what this does and visualize where it fits were

1) https://deepstream.io/tutorials/concepts/what-is-deepstream/ > "What is it for" section

2) and your comment that it's an alternative to firebase, socket.io, meteor.

Perhaps you can think of using these two pieces of information as the front-page blurb rather than make it abstract.

> What sort of documentation would make most sense?

A single sentence in the landing page with a clear description of what it is and what it does would suffice.

Reply on news.ycombinator.com