New Tool-Building APIs for Force.com
New Tool-Building APIs for Force.com
Join the DZone community and get the full member experience.Join For Free
Insight into the right steps to take for migrating workloads to public cloud and successfully reducing cost as a result. Read the Guide.
With the CloudForce 2012 tour in London and the CloudStock developer sessions that accompany it on the horizon, we'll be hosting a series of interviews with a few cool developers over the next week. First up is Taggart Matthiesen, who has worked on both consultation and implementation in the software/application space for 12 years. Most recently, he's been responsible for Apex Code, "The World's First On-Demand Programming Langauge," as well as Force.com Developer Tools for the last year and a half. Here's what he had to say about his upcoming session at CloudStock, as well as his work on Apex and the Force.com platform.
DZone: What will your session at CloudStock be about?
Taggart Matthiesen: My session is entitled "Intro to Force.com". It's less of an intro and more of an exploratory session discussing macro changes in application development platforms and diving into some of our key technologies within force.com. My goal is for every attendee to leave with the following points of education: 1) direction of application development platforms, 2) fundamentals of force.com, and 3) general understanding of how to leverage our declarative and programmatic toolsets to deliver social enterprise applications.
DZone: How do you usually describe Apex and the Force.com platform with analogies for the Java programmer, since the two languages are similar?
Taggart Matthiesen: Similar, yes – but Apex is a convenience language. It's domain specific. There are a number of utilities within the language which simplify application development. We've built tightly coupled async services, email services, and REST services. We have our own optimized query language and visibility/sharing model. We have bulk transactions. And we have tight integration with our declarative tools. If I create a new entity, it's exposed as a first class object in Apex.
DZone: Under the covers, do Apex and the Force.com platform provide a lot of built-in optimizations for coding applications that run in the cloud? What are some specific optimizations ensured by Salesforce's development tools that developers can use in their own applications to make them run more efficiently on cloud infrastructure?
Taggart Matthiesen: Three years ago our customers had authored roughly 1 million lines of Apex. Last year we passed the 1 billion lines of Apex and early this year we passed the 2 billion mark. The adoption has been staggering and we've kept a strong focus on our performance and scalability. Apex is fundamentally optimized for our runtime. Our query language is optimized as is our DML. Our bulk trigger logic helps customers optimize for large data movements and our language utilities provide optimized hooks for our developers. We also enforce transactional limits – making sure customers don't write non-performant code. These limits are effectively guidelines for building optimized logic on our platform. These limits also provide gauges to help customers understand when to leverage our synchronous vs. asynchronous services.
DZone: Can you comment on the significance of your upcoming public tooling API for Apex (Force.com) and give some examples of community tools that developers have been interested in making?
Taggart Matthiesen: We've always had a strong API message from a platform perspective. And we've build a number of powerful SOAP and REST APIs – allowing customers to build sophisticated integrations with salesforce.com. But we never exposed any true APIs around tooling. We delivered a Metadata API, but not an optimized API around tooling. This limited our customers from building rich development tools. Customers had to rely on our web-based tools or Eclipse plugin as the single tools for programmatic development. For the last year we've been building out a new tooling API specifically geared for external tool consumption. The community has been limited, but we've seen people build fully-blown IDEs, schema editors, and team development tools. Once we release this tooling API – these customers, developers, and partners can refactor their tools to take full advantage of our new API. We are also planning to rewrite our current Eclipse plugin and open source it – giving it back to the community. And we are building our own web IDE – and it will act as the reference implementation for these APIs. Clearly I'm excited and I hope others will soon share my excitement.
DZone: Is there anything else you wanted to talk about?
Taggart Matthiesen: Do you have another 5 hours? Honestly, the salesforce.com platform has really matured over the past year or so. It's amazing what you can develop on our platform. Mobile apps – social apps – enterprise apps – consumer facing sites – and our toolset and technology breadth makes it intuitive and fun. Yes fun, or so I think. I really hope I get a chance to interact with new developers and walk them through these technologies. It's amazing. Okay I'll stop now.
For more details about the session and the conference, go to the CloudForce information page.
Opinions expressed by DZone contributors are their own.