The Code Behind Project Butterfly and a Word About Flexibility

I’m sure some of you are interested in knowing a bit more about the insides of Project Butterfly. Some users have asked me how do we keep up the fast release rate. This post will try to answer both questions by providing background details of the technology behind the project with emphasis on how the system might be extended in the future.

Beginning at the top – the first thing a user sees when entering the system using the Try Now button is one of our sample drawings. The drawing is streamed to the client directly from the cloud (Amazon S3), and then rendered by the user’s computer. This is made possible by the data structures used by butterfly which are specially designed to stream vector data from the cloud service directly to the client front end. There are different types of online CAD editing tools in the market where in most cases, the user views server rendered images that are streamed to the client. In Butterfly, the rendering is done by the user’s computer (like it does when you use AutoCAD or other CAD software), allowing for a smoother navigation experience and client side editing.

When uploading a drawing, the system uses RealDWG to prepare the drawing for streaming. RealDWG provides exact information of the DWG file, which is an important part in the process of calculating the streaming method. The drawing is then stored securely on Amazon S3. Meeting user demands for DXF support a couple a weeks ago was rather smooth thanks to the flexibility of the  streaming module.

This architecture also answers a lot of scalability issues as it requires almost no server-side processing for the purpose of editing a file. In fact, the only server-side processing performed when opening a drawing is security related – making sure the drawing is delivered only to authenticated users that have access to the drawing.

We chose Adobe Flash as the client runtime environment. We can write a lot about Flash issues we had to overcame: memory usage, performance and so on, but that’s a topic for a different post. Flash is deployed on 99% of internet connected computers, allowing Butterfly to run on almost any Internet-connected machine. It was surprising to see a remarkable amount of Linux users logging in to the system. Although we’re currently pleased with our choice of Flash, it is worth mentioning that the dependency between Butterfly and Flash is intentionally modest.

The Flash application is built out of decoupled modules which are streamed to the client as the application loads. Different modules interact through a set of interfaces designed to provide support for manipulating and editing the drawing model. We recently used these interfaces to create the new Match Properties tool that was published a couple of weeks ago. The ribbon component has an interface that allows adding new buttons and tabs onto it, making adding a new feature to the UI a simple task. The underlying idea is to enable integration of 3^rd party enhancements and tools in the future, as we also have the ability to load modules while the application is running.

The Project Butterfly development team is always on the look for new technologies and new features to develop especially those coming from users feedbacks. Keeping our code flexible and extensible makes it easier deploying these features.

Jonathan Seroussi