Backend

For the average Stream integration, the development work focuses on code that executes in the client. The React, React Native, Swift, Kotlin or Flutter SDKs connect to the chat API directly from the client. However, some tasks must be executed from the server for safety.

The chat API has some features that client side code canmanage in specific cases but usually shouldn't. While these features can be initiated with client side code. We recommend managing them server side instead unless you are certain that you need to manage them from the client side for your specific use case.

The backend has full access to the chat API.

This quick start covers the basics of a backend integration. If we don't have an SDK for your favorite language be sure to review the REST documentation.

Generating user tokens

The backend creates a token for a user. You hand that token to the client side during login or registration. This token allows the client side to connect to the chat API for that user. Stream's permission system does the heavy work of determining which actions are valid for the user, so the backend just needs enough logic to provide a token to give the client side access to a specific user.

The following code shows how to instantiate a client and create a token for a user on the server:

# gem install getstream-ruby
require 'getstream_ruby'
require 'jwt'

# instantiate your stream client using the API key and secret
# the secret is only used server side and gives you full access to the API
client = GetStreamRuby.manual(api_key: '{{ api_key }}', api_secret: '{{ api_secret }}')
token = JWT.encode({ user_id: 'john' }, '{{ api_secret }}', 'HS256')
# next, hand this token to the client in your in your login or registration response

You can also generate tokens that expire after a certain time. The tokens & authentication section explains this in detail.

Syncing users

When a user starts a chat conversation with another user both users need to be present in Stream's user storage. So you'll want to make sure that users are synced in advance. The update users endpoint allows you to update 100 users at once, an example is shown below:

Models = GetStream::Generated::Models

client.common.update_users(
  Models::UpdateUsersRequest.new(
    users: { user_id => Models::UserRequest.new(id: user_id, role: 'admin', custom: { 'mycustomfield' => '123' }) }
  )
)

Note that user roles can only be changed server side. The role you assign to a user impacts their permissions and which actions they can take on a channel.

Syncing Channels

You can create channels client side, but for many applications you'll want to restrict the creation of channels to the backend. Especially if a chat is related to a certain object in your database. One example is building a livestream chat like Twitch. You'll want to create a channel for each Stream and set the channel creator to the owner of the Stream. The example below shows how to create a channel and update it:

Models = GetStream::Generated::Models

client.chat.get_or_create_channel('messaging', 'bob-and-jane',
  Models::ChannelGetOrCreateRequest.new(
    data: Models::ChannelInput.new(created_by_id: user_id)
  )
)
client.chat.update_channel('messaging', 'bob-and-jane',
  Models::UpdateChannelRequest.new(
    data: Models::ChannelInputRequest.new(
      custom: { 'name' => 'my channel name', 'image' => 'my image url', 'mycustomfield' => '123' }
    )
  )
)

You can also add a message on the channel when updating it. It's quite common for chat apps to show messages like: "Jack invited John to the channel", or "Kate changed the color of the channel to green".

Adding Members or Moderators

The backend SDKs also make it easy to add or remove members from a channel. The example below shows how to add and remove members:

Models = GetStream::Generated::Models

client.chat.update_channel('<channel-type>', '<channel-id>',
  Models::UpdateChannelRequest.new(
    add_members: [
      Models::ChannelMemberRequest.new(user_id: 'thierry'),
      Models::ChannelMemberRequest.new(user_id: 'josh'),
    ]
  )
)
client.chat.update_channel('<channel-type>', '<channel-id>',
  Models::UpdateChannelRequest.new(remove_members: ['tommaso'])
)

client.chat.update_channel('<channel-type>', '<channel-id>',
  Models::UpdateChannelRequest.new(add_moderators: ['thierry'])
)
client.chat.update_channel('<channel-type>', '<channel-id>',
  Models::UpdateChannelRequest.new(demote_moderators: ['thierry'])
)

Sending Messages

It's quite common that certain actions in your application trigger a message to be sent. If a new user joins an app some chat apps will notify you that your contact joined the app. The example below shows how to send a message from the backend. It's the same syntax as you use client side, but specifying which user is sending the message is required:

Models = GetStream::Generated::Models

client.chat.send_message('<channel-type>', '<channel-id>',
  Models::SendMessageRequest.new(
    message: Models::MessageRequest.new(
      text: '@Josh I told them I was pesca-pescatarian. Which is one who eats solely fish who eat other fish.',
      mentioned_users: [josh_id],
      user_id: john_id,
      attachments: [
        Models::Attachment.new(
          type: 'image',
          asset_url: 'https://bit.ly/2K74TaG',
          thumb_url: 'https://bit.ly/2Uumxti',
          custom: { 'myCustomField' => 123 }
        )
      ],
      custom: { 'anotherCustomField' => 234 }
    )
  )
)

Changing Application Settings

Some application settings should only be changed using the back end for security reasons:

API Changes

A breaking change is a change that may require you to make changes to your application in order to avoid disruption to your integration. Stream will never introduce a breaking change without notifying its customers and giving them plenty of time to make the appropriate changes on their end. The following are a few examples of changes we consider breaking:

  • Changes to existing permission definitions.

  • Removal of an allowed parameter, request field or response field.

  • Addition of a required parameter or request field without default values.

  • Changes to the intended functionality of an endpoint. For example, if a DELETE request previously used to soft delete the resource but now hard deletes the resource.

  • Introduction of a new validation.

A non-breaking change is a change that you can adapt to at your own discretion and pace without disruption. Ensure that your application is designed to be able to handle the following types of non-breaking changes without prior notice from Stream:

  • Addition of new endpoints.

  • Addition of new methods to existing endpoints.

  • Addition of new fields in the following scenarios:

  • New fields in responses.

  • New optional request fields or parameters.

  • New required request fields that have default values.

  • Addition of a new value returned for an existing text field.

  • Changes to the order of fields returned within a response.

  • Addition of an optional request header.

  • Removal of redundant request header.

  • Changes to the length of data returned within a field.

  • Changes to the overall response size.

  • Changes to error messages. We do not recommend parsing error messages to perform business logic. Instead, you should only rely on HTTP response codes and error codes.

  • Fixes to HTTP response codes and error codes from incorrect code to correct code.

  • Prefix your custom data properties, we could introduce new features that might clash with custom property names you are using, by prefixing them you avoid this problem.

Previous
Getting Started
Next
Architecture & Benchmark