Should I call this method client-side or server-side?

With the amount of freedom and flexibility Stream provides in regards to usage, it can often evoke discussions of higher level architectural patterns that are better addressed near the beginning of your application’s life cycle. If you’ve been diligently reading our documentation, you may have noticed that many of our methods (feeds or chat) can be invoked either client-side or server-side. Which pattern is better is not so black & white, however, there is a key consideration that will make this decision much more obvious. I’ll provide a couple common scenarios that our clients encounter that lend themselves well to a more server-side driven approach.

Firstly, let’s discuss from a high level perspective when it’s more appropriate to call certain methods server-side rather than client-side. This will largely be up to you and perhaps the patterns that you already have in place, however, the one major factor here is whether or not you need to do any sort of extra analysis, processing, permissions checks, etc... A good example of this, oriented around our feeds API, is moderation. Unlike our chat product, we don’t have a robust set of moderation tools available out of the box. However, this can be easily implemented by relying on a more server-side approach. For instance, instead of interacting with our API directly from your client when posting an activity, you could create an endpoint where you process the contents of all activities and if they meet your moderation criteria, use one of our server-side SDK’s to then post to the corresponding feed.

Another example in this same vein, but regarding chat, is extra permission levels. A common question we receive from clients is something along the lines of: “I only want users who are friends to be able to chat, is that possible?”. Our chat API does not have the concept of “friends”, so this facility will likely be handled elsewhere (stored in your database or as metadata on the user object), but this is a great reason to take a server-side approach to channel creation. Like the feeds example, instead of interacting with our API client-side, you would create an endpoint that first checks if two users are friends before instantiating a channel between them using one of our server-side SDK’s.

These are just a couple examples of when interacting with our API server-side is more advantageous. Of course, there are many other reasons for doing so but the underlying principle remains largely the same. Whenever you need any sort of additional analysis prior to making a request, It's worth considering passing this workload to your server.