ASCII gif via Google search for “Dancing Computers”
Choreographers design and build Choreos, the 1200+ scalable, modular, ready-to-run processes and utilities that comprise the Temboo Library. Effectively, Choreos connect the web, hooking into web services, and executing complex steps in the Cloud.
There’s a lot that goes into creating these powerful Choreos. Our Choreographer-in-Chief, Aaron, offers some insight into the process and what these mighty building blocks can do:
Are Choreos written / designed / built?
Yeah, there can be a good amount of design that goes into Choreo building. It’s really a lot like planning and writing code in other languages. Of course, building them with Twyla [Temboo’s experimental visual programming language] and working in a GUI is different…
But, Twyla can be really convenient for a lot of tasks. For example, parsing XML within Choreos can often be quicker and simpler than the way we handle that in a standard coding language. Also, there are a lot of cases where XML or JSON needs to be transformed (or mapped) to another schema. Mapping API responses to simpler or completely different schemas is one of my favorite tricks to do in Twyla.
The Temboo Expression language has a ton of handy functions: for example, you can convert a JSON string into items within a folder structure. This can offer useful ways of inspecting deeply nested JSON responses.
I guess the last and most important thing might be that Twyla has a step called the Launch Choreo step. This is where Choreos become very powerful. We use the Launch step to chain Library Choreos together to build larger workflows. So essentially, the Library contains over a thousand of these pre-coded API operations that can just be chained together in one or more “parent” Choreos.
How would you say Choreos work or connect together?
Choreos can work together in two ways: You can call multiple Choreos in your code using the SDK (and pass in input values and parse outputs). Or, you can chain Choreos together using the Launch Choreo Step in Twyla.
What’s considered a complex process for a Choreo?
We’ve built a lot Choreos with Twyla that perform pretty complex scripting tasks: Choreos that do very complex mappings for doing large data imports from various web services to database endpoints; complex Choreos for polling/processing items in a document queue; Choreos that crawl tree structures to push web content to internal web services, etc.
Would you give me an example of a Choreo in use?
Last week, we built a documentation helper Choreo that basically cuts our documentation time in half. It generates template documentation (.tdoc) files for all folders and Choreos in a newly completed bundle that we make. The helper Choreo accesses the Temboo REST API and gets info about Choreo variables, descriptions, etc, and passes this info into .tdoc templates. It cuts down on a lot of repetition that we were doing.
While that’s pretty great for us at Temboo, the general takeaway is Choreos can recursively crawl a tree structure, use freemarker language to do fancy things with templates, and are very customizable.
How do you decide on what specific Choreos to build for an API?
In some cases, we include all methods of an API. In other cases, we pick and choose which methods might be the most commonly used by developers. We try to include Choreos that offer extended functionality whenever possible, and we’d like to focus on this more and more in future.
What are some of the developer aspects you consider when you include APIs in the Library?
We try to think about several factors when including APIs in the library. We definitely try to include commonly used APIs as much as we can. APIs that are quirky or challenging for various reasons are also good candidates because we can add value by wrapping them in a standardized/RESTful way. Or, if we just come across a new API that returns compelling data that can used for interesting apps, we may include that one as well.
Do you ever encounter goofy things w/ APIs? If so, how do you deal with them?
Yeah, we see odd things all the time. In general, we have an opportunity to make things more RESTful if we come across something strange. Some of the SOAP APIs are examples of where we might wrap an API method so that the user isn’t worrying about some odd SOAP request XML and can execute a Choreo using a set of simple serialized inputs instead.
