Once I had established a sort of proof of concept for my algorithmic rotoscope process, and was able to manually execute each step of the process from separating a video, and applying filters, to reassembling the video, I quickly refactored my prototype code to be API-first. I did this even before I built any sort of interface for executing and managing the process, as this would allow me to not just execute the process, it would also allow me to manage, extend, and scale as many algorithmic rotoscopes as I wanted.
I'm not particularly proud of the API design, and think it is something that will evolve and change, as I push forward what is possible with my algorithmic rotoscope. I'm learning a lot along the way, and my focus in having an API is not to open up access to 3rd parties, but to allow me to scale my process, and efficiently run using Amazon Web Services, Algorithmia, and a handful of other APIs. Currently, I have about 25 separate paths for my API, which allows me to accomplish every step of the algorithmic rotoscope process.
Currenlty my algorithmic rotoscope API runs on a single Amazon EC2 instance, which I am scaling vertically, meaning I just increase the size of the server instance when I want more to get done. However, having the entire process be API first, will allow me to easy scale horizontally, across multiple servers. This should allow me to isolate specific steps of the process, or several of them together, allowing me to scale the server separately for assembling and disassembling the videos--which can be pretty intensive.
Once I have some time I will publish an OpenAPI Spec for the API. I don't have any intention on opening up the API for 3rd party usage, but I may be open to deploying Amazon instances for wholesale use, and partner access, at some point in the future. I am not looking to do this as a full blown startup idea, but is something I'd like to evolve on the side for my own uses, and potentially as a service for select clients. I will keep adding paths to my algorithmic rotoscope API, but for now I'll work to document, and refine the existing paths I have, and tell the story of the API--you know, practice what I preach and all. Even if my API isn't fully public, there is no reason the documentation, story, and results can't be public.
