Q&A: Apigee Edge & Node.js
Our recent webcast entitled “Apigee Edge and Node.js” generated a lot of interest and discussion. Combined with Apigee Edge, node.js, the popular framework that runs natively on the Apigee platform and enables multi-channel apps and APIs, opens up a wealth of new possibilities.
We didn’t have time to answer all the questions generated by the webcast, so here they are now. Thanks to all of you who participated!
I plan to use node.js and Apigee Edge to load a few dozen more vendors like FitBit.com. Can you address how easy this might be?
This is one of our core product functionalities. Many of our customers use our platform to aggregate their data with third-party API data like this. There are lots of public materials about it, and you can click here to view an existing recorded demo of our product. We can also set up a demo for you; you can request one at the demo page linked above. Or try it out yourself with our Apigee developer plan by visiting /about/pricing/apigee-edge-pricing-features.
Companies like DreamFactory.com expose a REST API to perform CRUD operations using auto-generation of CRUD functionality. Do you now or will you in the future provide such functionality?
The addition of node.js helps by building this kind of functionality in our platform, using node.js modules in a very flexible way. We may consider more tooling support in future.
Can you explain the difference between sharing data via APIs versus web services?
APIs are indeed “web services” in that they are programmable services invoked over the Internet using HTTP. However, a proper “API” usually includes some way for a developer to learn about the service (via docs, or some sort of developer portal), and a way for the developer to sign up via self-service, rather than attending meetings and making phone calls.
In addition, APIs are designed for use on the Internet, as opposed to on a private network, so they typically include some sort of security mechanism (often OAuth), some mechanisms that restrict the number of API calls a client is allowed to make, and additional mechanisms to protect against threats and gather analytics on the traffic.
Could I use Apigee as a sort of middle-tier proxy server to forward REST API requests to my third-party vendors like Fitbit.com and Fatsecret.com then forward the responses to my customers at the client tier?
Certainly. Many of our customers use our platform to aggregate their data with third-party API data like this. You can try it out yourself with our Apigee Developer plan; sign up here: http://apigee.com/about/plans.
Besides JSON, do you also support classic XML payloads?
Yes. We support XML and JSON both natively. Many of our policies and other platform features specifically handle XML payloads.
Do you consider yourselves to be a node.js REST API dev platform like Cloud9.com, or are you positioning yourselves in some other space? If so what is the difference?
Our platform is a great one to use if you are either developing a brand-new API in node.js, or creating an API out of existing parts—and we are continuing to invest in our platform for this use case. On the other hand, there are plenty of platforms out there which are optimized for hosting web pages.
For creating a new API, using Apigee gives you the benefit of a platform that solves hard problems that are unique to the API world, such as quota enforcement, threat detection, and OAuth support. In addition, we have the ability to gather detailed analytics on the API traffic and present them in a way that is “native” to API developers (as opposed to web app analytics, which are really only designed for web apps).
For creating an API out of existing parts, you can also use the additional features of Apigee Edge that allow you to create a proxy for an existing API (either using a graphical UI, by editing configuration files, or by writing node.js code), apply the policies like we described above, and gather great analytics.
Does OAuth 2.0 have major performance improvements over OAuth 1.0 and does it do a better job at security?
The difference is not so much about the performance, but in how flexible the framework is. OAuth 2.0 is a standard, extensible way to create authorization mechanisms, whereas OAuth 1.0 only really supported one thing.
OAuth 1.0 addressed a much smaller subset of these problems, and only supported one token type (secret keys encrypted using an HMAC) and only one way to get tokens (web browser redirect).
OAuth 2.0 normally uses bearer tokens (random values that are passed via TLS/SSL as an HTTP header), but these can be acquired in many ways, including a web browser redirect and a username/password check. The spec committee is working on additional ways of getting tokens, such as through signed JSON web tokens (JWT).
What would be the typical round-trip time involved in making a GET method request to FitBit.com using OAuth 1.0 (and either JSON or XML) with either Apigee.com's implementation of the FitBit platform versus FitBit's implementation of Apigee's REST API at the dev.fitbit.com Explore API's interface? Platform for platform, how much faster is JSON versus XML? Or is that just another big myth about speed improvements of JSON?
The round-trip time depends more on Internet latency than anything else. For instance, to get from a mobile device to FitBit and back through a proxy running in Apigee, your API call travels from the device to Apigee, then to FitBit, then back through Apigee. Depending on where FitBit’s servers are located, that may be anything from 50 to 100 milliseconds slower (an average latency across the U.S.) to almost the same.
Furthermore, the proxy in Apigee can do things like cache common responses, remove unused bits of the response, and combine multiple API calls to the FitBit API into a single API call from the device. This means that an API running on Apigee may well be faster.
As for XML versus JSON, the real difference is in the ability for a client app, such as a mobile app, to parse the data. Programmers have a much easier time consuming JSON than XML, because the data model is much simpler and identical, or nearly identical, to most programming languages. Parsing XML, on the other hand, requires a bunch of specialized knowledge.
In some cases, parsing XML uses more CPU on the client, but it’s not necessarily a big difference. Similarly, XML is “more verbose,” but once you compress it, XML and JSON end up being very similar since in the end they typically contain the same information.
Does this mean I can build an API on Edge using node that is a prototype (with, for example, hard-coded data) and later implement it on my back end?
Certainly. One of the creative uses of node.js support in our platform is to mock your API to follow a very agile model of development. There are many node.js modules that can generate mock APIs from different API definitions.
What would I need Volos for an Edge account? I would be better off using the built-in Edge policies for each of these things, right?
It depends. Many developers, including a majority of enterprise customers, love our policy model due to ease of use and simplicity for common API platform-related tasks. But there are a set of developers who love to code—in a language they know or love.
For those developers, Volos is a way to leverage Apigee’s API platform, but in their own way. Volos also allows developers to avoid vendor lock-in, as they can run their node.js app with Volos node modules in any other node container, though it won’t be able to take advantage of Apigee platform benefits.
Can node.js be run natively? I might be wrong, but from my Play/Scala experience with Trireme/Rhino, it's kind of slow. Even with Play 2.3, TypeSafe is adding an option to run node.js natively. Thoughts?
The only TypeSafe component that I have used so far is their integration with the Scala Build Tool (sbt), which works fine and is easy to integrate, but it exposes Java’s weakness, which is startup time. In a web server, such as our integration within Apigee, Trireme is running the same code over and over and it is much closer to native node.js performance.
With that said, Trireme is never going to be as fast for very CPU-intensive tasks like node.js on V8. However, most of the use cases that we see are not CPU-intensive and can handle hundreds or thousands of API calls per second using Trireme.
Can you walk us through a real-world example of where node.js with Apigee is used?
We’ll share two use cases from early adopters of node.js functionality in our platform.
Built an app backend on top of Solr and cloud-data sources to be used by online services. Node.js was used to programmatically orchestrate different back-end services to create a consolidated response, which then exposed an API to their partners and internal employees.
Built an API logic layer on top of CRM data for field employees and partners. Initially, they were considering a different node.js platform for developing the app logic layer exposed directly to their employee application, and were also considering Apigee Edge for exposure layer for the partners. But when they realized they would miss out on consolidated analytics, experience a lack of reuse for other internal applications, and be required to maintain two separate systems, then they considered Apigee Edge as the consolidated platform for app logic and an exposure layer.
Does communication between a NoSQL DB backend and a mobile app happen via REST protocol? Assuming that API uses REST for communication?
Yes. Our NoSQL backend services are directly exposed through a REST interface. Many NoSQL systems already have it.
Can't we have mobile apps talk directly to a DB, like other web apps do?
I don’t think so.
(Longer answer: In theory, sure, but in practice it’s a bad idea. For one, native database protocols aren’t optimized to save network bandwidth and the app won’t be very fast. More importantly, exposing a database directly to the internet has resulted in many, many security bugs over the history of the Internet—having something in the middle is much more secure.)
Do you supplement, complement, or replace Azure Cloud Web Services?
We believe that our platform is a great one to use if you are either developing a new API in node.js, or creating an API out of existing parts—and we are continuing to invest in our platform for this use case. On the other hand, there are plenty of platforms including Azure Cloud out there which are optimized for hosting node.js web applications.
With Apigee App Services, is there a way to update an entity's property at a certain time, specified by the user in-app? (I'm using Apigee with my js/HTML5 PhoneGap app)
There’s currently no scheduler service available with Apigee Edge, but it’s certainly possible to update entities in the Apigee Edge BaaS via requests made by either the app or from proxies running on Edge itself.
I'm not too familiar with your tech stack (still learning) but can I write CoffeeScript instead of js with this new node.js capability?
Sure. We don’t do this internally but we know that a number of people have tried.
Is there a free developer option to develop apps on Apigee Edge to prepare for commercial launch?
Yes. You can use the full Apigee platform with our Apigee developer plan. Sign up at /about/pricing/apigee-edge-pricing-features.
Do you have any reference node.js applications to give out some best practices?
We have few node.js sample applications available through our GitHub repository.