Skip to content

Instantly share code, notes, and snippets.

@sam-parsons
Last active October 3, 2019 15:45
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save sam-parsons/6ee4da167d442c6ad9b66625f7bbde56 to your computer and use it in GitHub Desktop.
Save sam-parsons/6ee4da167d442c6ad9b66625f7bbde56 to your computer and use it in GitHub Desktop.

Ever tried to use Websockets or SSEs in Postman? We feel your pain.

If you are reading this, chances are you have used the Postman API tool to help you create a backend for your application or test what kind of data you can get back from an existing endpoint. For these cases, Postman works really great - and some of its competitors also do those things very well - Insomnia, Apigee, Postwoman, just to name a few. But what happens when you want to make an app with bidirectional communication between the clients and servers? Go ahead, try figure out to use WebSockets with Postman. We will wait.

Maybe you have or haven't tried this, but a quick look to this Github issue will reveal you aren't alone drowning in the thirst for a way to test yours or somebody else's WebSockets API. This is why Swell exists. Swell is not only another RESTful API testing tool, but most importantly, it exists to solve problems of testing streaming APIs. You can effectively develop your own WebSockets backend or mock how your client would interact with an existing one with the use of Swell.

So that's great, but what about streaming communications over HTTP? I encourage you to try and hit an SSE endpoint and see what happens with Postman - you'll run into the same problem you did with WebSockets. Once again, you are not alone - many have voiced their opinion about this, leaving a void in the environment. By selecting a small checkbox on Swell, you will have access to a stream of data from an SSE endpoint with a single request. Problem solved.

Swell has went through a couple iterations recently, and its latest version has great support for the next wave of streaming communications - GraphQL subscriptions. It's 2020 (pretty much) and people use WebSockets to make GraphQL subscriptions and because Swell already had support for WS protocol, adding GQL subscriptions was a no brainer. In the end, if you are testing your client against a GraphQL subscription API built in 2015 over HTTP, try to use Postman, let them know how you feel - but if you want to develop an industry standard subscription backend, use Swell to make sure you are building a robust, error-free environment.

If you are mocking up or testing against a Pokemon or Star Wars REST API, feel free to use Postman, it works great and has a lot of features. But if you want to develop real-time experiences for your users, consider using Swell to fill in the gaps Postman can't. If you have any feature requests - or maybe you found an easter egg - head over to issues page and let us know. And if you need something right now, pull the lever on a PR.

Thanks, Swell Team

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment