Absolutely, my name is Al Tsang, I’m CTO and one of the Co-Founders of a company called StrongLoop and we are here presenting at QCon. At StrongLoop we develop Node.js based solutions, we contribute to Node.js core itself, build solutions on top of Node starting with OpenSource frameworks and libraries, we eat our dog food by utilizing those frameworks and libraries to develop commercially viable products.
Charles: Ok, so Node.js was primarily invented for writing web servers and obviously other use cases have been found for it over time. Giving your focus on web API’s, are there any particular advantages that JavaScript has as a language, as opposed to say something like Java for doing REST coding
Absolutely, we believe that a sort of unique locked language both on server side as well as the front end is just the CUSP or beginning of what we are realizing as a full stack solution, which in turn develops into an evolution of who we’re talking about as a developer. So a developer who is familiarized already with the client developments for the initiatives that’s been driven say by Mobile or IoT, now has the power by using that same language and its constructs to develop server side solutions that they have a prayer or a chance that actually be able to navigate, extend, and one day just write on their own, given that its JavaScript on the backend, and extending this parallel one level further, we believe that there this is also this notion of what we call it Isomorphic JavaScript, so blurring the lines between what actually is executed on the server versus the client based on conditions, based on the conditions say in Mobile where you may not have connectivity but you want to do validations on the client or it’s more efficient to do certain operations on the client versus the server. So we really believe that Node levels the playing field by allowing the JavaScript developer to go full stack, to do the front-end development, think about the API’s that they would have otherwise consumed and using frameworks like ours and Node in general to be able to virtualize and mock those API’s very quickly through a JSON REST interface.
2. We are seeing I guess the emergence of an API economy, what do you think is driving that?
It’s a very good question, I believe there are a couple of key enablers there, drivers there. Number one I think the number of sheer clients is paramount and increasing. So every person now has a mobile device of incredible power, of incredibly connectivity and their interaction is more frequent, it’s more personal. And the sheer number of apps and productivity on these mobile devices is growing and we are also seeing the very beginnings of the Internet of Things, where devices, say embedded devices that are in your thermostat or in an industrial setting on a piece of heavy machinery or heavy industry, is sending and needing to get back that data through a RESTful API or some form of API to the backend. So the sheer number of clients is multiplying and increasing and the folks who traditionally are having those websites, for example, that are based on bricks and mortar are looking and seeing, at being able to economize on the functionality that they have amassed on the backend and being able to harness that whether that be through a developer community, whether that be tighter integration with partners or in general capitalize on all that business function beyond the walls of the firewall, beyond the walls of the corporation.
Absolutely, absolutely we’re seeing that out in the field. We see sort of the so called, SOA initiatives of yesteryear where you’ve trying to tie in services, whether those services be Java, C++, Python, you name it, are getting to some level of success of having them unified and normalized, but then an extra hurdle of needing to manage those services in their externalized form, so being able to mediate between different content types - SOAP versus JSON for example - being able to surface the protocols and the RESTful API’s for example to devices that can only handle a certain subset of their payload that would have otherwise just been the raw service behind the firewall. And managing these two pieces has been a bear, and what we are seeing is the API Gateway is running out of head room, where there is a nice GUI sort of driven interface, very XML driven, it’s very easy to use but you run out of the head room in terms of it needing to be scriptable, being extensible, and what better language to do that [than] with JavaScript where you can roll your own policies, define your own metics that you would like to do within the Gateway and not having those to be proprietary as well, so for example in the Node ecosystem there is a metrics library to already incur the number of hits for an API on the HTTP level. Wy not just integrate that into your stack and then worry about all the business logic as to what you want to do for a use case of, say, rate limitation. And we see Node as being the glue on the backend as well as the perfect thing to buffer and externalize those services to those multiple myriads of clients that we talked about earlier.
Sure, it’s not just StrongLoop but I think is in general the community, us as good community members, propagating the interest of wanting to move Node forward which was name of the, what do you call it, movement that we assigned to it. The idea is that Node needs to still evolve like any other good technology. We as a vendor with commercial interest around Node, we have to dedicate to being able to support our customers, who rely on Node as a core technology and in order to do so we need to evolve Node, fix it, patch it, add in features that we are hearing out from our customers in the community as well and I believe things just got to a head where folks have been waiting for, for example the latest release, V12, which StrongLoop has contributed the top 5 out of 10 contributors almost half of what was there for version 12, and wanting to evolve it and move it forward. And the other thing is bringing up the question of the governance, so how are decisions made? When do releases actually happen, by which process do we follow and say that Node is baked in and ready to be released. I think there needed to be more transparency and Node forward was an answer as to bringing these questions surfaced by the community, and companies like ourselves as well and bringing this to a higher level order saying “how can we do this better in service of the folks who actually use Node”, and not just have Node as an asset within their company for example.
I believe so, but I believe is a also a response to not just the correlation of Node forward but just the community feedback as well, saying that this is what we want, this is the type of transparency and decision making governance that Node deserves and it’s also what’s going to lead to the credibility of Node, pardon the pun,moving forward, needs when corporate decision makers for example look at Node as a technology saying: “By who and how does this evolve, is there enough representation, is there transparency as far as policies on decision making, what is the release cadence by which I can expect changes to Node as well”.
6. And are you still planning to work on a fork or is the advisory board kind of enough?
I believe that there has been no decision made, I believe we are still in the throws of understanding what that advisory board means and I think we will take in to interest what the community wants, what other vendors or partners like ourselves need sort of long term wise and see what’s the best outcome is that we can reach what this proposal, but I believe it is definitely a step in the right direction.