Spreading API Collections From My Personal Workspaces Across Multiple Workspaces
As a Postman user for a number of years I have several hundred random collections littering my personal workspace. I had noticed that workspaces emerged a while back, but really hadn’t ever put much thought into how I organize my collections. As the number of collections grows I’m noticing performance issues within Postman, and general chaos because I work primarily fro within my personal workspace. Pushing me to step back and think more holistically in how I create, store, organize, and share my API collections within the Postman platform and beyond using AWS S3 and GitHub. Forcing a little organization and structure on how I move APIs forward across thier own API life cycle trajectory.
First, when working in my personal workspace there were performance issues using Postman. There were just too many Postman collections in there to be efficient. This further slowed me down when it comes to finding the collections I needed. Having to look purely alphabetically for collections that could have any sort of naming conventions applied to them took way too much time. This reality has pushed me to think about the different bucket in which I operate and get work done proved to be helpful, helping me create a handful of workspaces for me to organize my API collections into, rather than just operating from a single workspace filled with hundreds of APIs I have imported over the years.
My frist task was to just delete things that was clearly junk. Then I looked at all my collections via the Postman API to see if there was any last modified or run date—sadly there isn’t. I will have to think about way in which I can track the evolution and usage of my Postman collections so that I can consider automating the cleanup of collections, or at least archiving of them based upon them being modified or not. Once I cleaned up a little bit I was able to see the forest for the trees and I begin organizing my collections by domain and project relevance, putting collections into teams for accessing when I’m working on specific projects and area of my operations (ie. apievangelist.com vs algorotoscope.work). Helping me not stumble over work on other projects, while I’m focused in a specific area of my work.
As I was organizing my collections I began to see new ways in which I could be organizing them. So I began creating workspaces based upon resource area and topics, allowing me to put image API collections into an images workspaces, and video API collections into video workspaces. Sometimes a collection would need to be in multiple workspaces depending on the type of resources it offered up, or how I was using the API in my work. An additional layer of separation between workspaces is based upon them being in my personal workspace, or my team workspace. I only have one team account for my API Evangelist efforts, but I am looking to expand on this team effort by bringing in more help when it comes to profiling APIs and producing useful Postman collections.
There is still a lot of work left to do when it comes to organizing my Postman collections, but I managed to alleviate the load on my personal workspace. I notice some efficiency gains in the application as well as just my general workflow. I am also learning to have multiple Postman workspaces open in multiple windows, helping me more efficiently navigate the workspaces, share collections and environments, and assemble new Postman collections from the capabilities that exist in the many reference API collections I have. Spreading my API collections that exist in my personal workspace across multiple personal and team workspaces has shifted how I work, and has helped me be more thoughtful in what collections I keep around, and how I put them to work as part of my regular work—streamlining how I work with APIs and manage my integrations and orchestration across hundreds of different APIs.