Looking Forward to What’s Coming from Stream in 2018

Thierry S.
Thierry S.
Published March 21, 2018 Updated October 9, 2019

Looking Back

2017 wrapped up with the launch of Stream V2 and multi-region support. The new version of our API uses Go, RocksDB and Raft to power the feeds for over 300 million users. V2 represents our largest improvement in performance so far. Switching from Cassandra to RocksDB was a major step forward for Stream. It’s also been great to see a similar move by Instagram and other companies who have adopted RocksDB. In terms of numbers, here’s what Stream looks like today:

  • Number of servers: 140
  • Feed updates per month: 34 billion
  • Average API response time: 12 milliseconds
  • Average real-time response time: 2 milliseconds
  • Regions: 4 (US-East, EU-West, Tokyo and Singapore)
  • API requests per month: 1 billion (~20k/minute)
  • Team members: 22

Multi-region support substantially reduced the latency for our customers in Asia and Europe. Sketchfab, for instance, moved from US-east (V1) to Ireland (V2) and noticed an increase in performance, resulting in a round-trip decrease from 146ms to only 12ms.

Our real-time infrastructure also received a full rewrite and greatly improved performance. So, if you want to use feeds for real time use cases such as events, games or discussions between famous users, we’ve got you covered.

In true Stream fashion, we’ve created the following roadmap for 2018 based on customer input. We’d like to encourage all users to email us if you have any questions or feedback.

Here are several enhancements to look forward to in the coming months:

1. Filtering

There are a few different use cases for filtering support:

  • Privacy settings on activities
  • Removing flagged/inappropriate content
  • Filtering mature content
  • Selecting activities of a certain type (ie: showing only posts or likes)
  • Complex follows (ie: houses listed in Boulder below $1 million)

While there is a way to do this currently, it’s not a simple process. Right now, the only way to build that with Stream is to create multiple feed groups. Many of our customers have setup feed groups called user_private, user_friends, user_public, etc. While that approach works, it makes it harder to integrate Stream. Additionally, it doesn’t work if you need more complex filtering criteria or if you have a combination of filtering criteria (ie. supporting both privacy settings and filtering on activities of a certain type).

2. React Components

The popularity of Based, our UI Kit for feeds, has inspired us to create a React component library for feeds. This will make it extremely easy to add notification feeds, activity streams or news feeds to your React based app.

We’re even thinking about including a generator for the React components in the dashboard, making it easier to get up and running with Stream. What do you think?

3. Likes & Comments

Many of our customers want to store likes and comments in their own database. For a long time, we’ve considered likes and comments to be out of scope. To our surprise, many of our enterprise customers asked for us to include this functionality. As we previously mentioned, we believe in the importance of listening to customer feedback and can admit when we’re wrong. In the coming months, we’ll add support for likes, comments and other reactions to Stream’s API. When you read the feed you’ll automatically see the counts and if the user has already liked the given activity.

4. Enrichment and normalization

One of the hardest aspects of integrating with Stream is enrichment. Most of our customers' store IDs to external objects in the activities. One example is user IDs. When you read the feed you need to:

  • Gather the list of objects referenced
  • Efficiently lookup those objects in cache and your database
  • Replace the IDs with the full objects

While this isn’t very complex it definitely makes it a bit harder to integrate with Stream. Our plan is to remove this complexity from the integration and take care of the whole process transparently.

For example, say you want the actor field of an activity to be a user from your application. Right now you would store the user ID in the actor field and, at read time, replace all IDs with the data from your primary storage.

With the new approach, you can send the data in the actor field as it is and Stream will take care of the rest.

activity = {
     distance:'20 miles'

In the example above, Stream could detect that you added a track object, normalized it and stored it separately from the activity. When reading the feed we would simply lookup the “track:123” object and show you the full details. You could update the object using our collections endpoint.

5. Personalization V2

A. Currently, personalization is only supported through our Python SDK. Customers using other languages have to directly use the REST SDKs which isn’t ideal.
Next step: updating our other SDKs to make it easier to integrate personalization.

B. Our analytics endpoint currently doesn’t have a REST API. However many larger customers prefer to integrate analytics on the server side.
Next step: adding a REST endpoint to batch create impressions and events.

C. We’re going to release a “getting started” type of tutorial for personalization. This will make it easier to get up and running with any of the 5 use cases for personalization. Read the docs.

6. Performance & Scalability Improvements

After we released the new version of Stream based on Go, RocksDB, and Raft, we saw a large and immediate performance improvement. There’s still a lot of room left for optimization on the new architecture. This means you’ll continue to see performance improvements in the coming months.

7. Documentation

One thing that always amazed me is that the documentation for many APIs isn’t great - even when the product is! It’s surprising since I know, as a developer, that docs are one of the main things we look at when deciding whether or not to adopt a new tool. Over the past few years, Stream’s documentation has not been kept entirely up-to-date. It’s actually quite difficult to keep the docs completely relevant when your product is moving quickly. We’re going to invest a good amount of time to improving the writing, updating the code and checking all our example apps and integrations.

Send us your Feedback!

Once again, we’d love to get your feedback. Send us an email with your thoughts, product improvements, new features, etc. Even small things like spotting issues in our documentation help make the API easier to use for the entire Stream community. We look forward to hearing from you!