- Mobile app development
- Building rich data applications
- The internet of things
- REST API services layers
- NoSQL versus SQL
- DreamFactory use cases
- Upcoming features in DreamFactory
- And why everyone is moving to REST and JSON
This is part of an ongoing series of interviews we're doing to highlight some of the great applications in the Bitnami library and the people and teams behind them.
Erica Brescia: Hi, this is Erica Brescia, one of the founders of Bitnami. And I’m here with Bill Appleton, CEO and founder of DreamFactory. Bill, thanks for joining me today.
Bill Appleton: Thank you.
EB: So just to start out, can you tell us a little bit about DreamFactory for users that aren’t familiar with it, and then we can talk a little bit about your background and why you started DreamFactory.
BA: Sure. DreamFactory is an open source software package for mobile application developers, and we make it really easy to hook up to back-end databases and other services and storage medium and then expose all of that information as a REST API, which is really critical for HTML5 mobile or Native mobile. And you can also use it for a wide variety of other things like the internet of things, basically anywhere you need to connect a database to a REST service.
EB: And what led you to build DreamFactory?
BA: Well I started building service-based applications almost 15 years ago, back when Dave Winer first invented XML-RPC in the late ‘90s, the early 2000’s, and recognized it was just a really fabulous way for a client application to get data from a remote data source. And so the first couple things I built were really on the very earliest services from places like XMethods and things like that. And then later it really gained momentum — this idea that a client application could call a service anywhere else in the world and do this across usually just across HTTP posts. So you know basically anywhere you could have an internet HTML application you could instead write a rich client application that called services. And it really picked up steam. You know and then Microsoft and IBM came out with a SOAP standard, and through one of the big service platforms to come out after that one of the first was Salesforce, and then many different service platforms came out. And so that's really how the company got started. In about 2005, talking with Salesforce, they were telling us about the AppExchange, and so we applied this technology to building the rich applications on top of Salesforce's architecture. And that really started - I built the first AppExchange app Dream Team, and that really started a lot of interest in that product, and we started picking up a lot of customers, people who were signing up for it.
And I realized that we were gonna have to take on some funding or it was just gonna be kind of a ridiculous situation of not being able to take care of these customers. And so we got funded by NEA in 2006 and became one of the leading app exchange publishers. But I guess about 2011 it became clear that this technology that we had pioneered building service-based client applications was going to become really important for mobile app dev, and that in many ways the whole concept of HTML websites was not going to work on mobile and the new world of the internet. And so the other thing going on was that we were getting customers who really wanted us to build them service platforms for various different purposes. And I remember the first one we built we thought well we'll get started with – you know we'll just go get the best open source service platform and we'll start with that as a starting point. And we were really shocked to find out that there wasn't one. And we looked and looked and there wasn't any open source service platform that would put a great REST API on a database and allow you to build a rich application.
BA: And so we set about to build one, and that's kind of you know the phase two of our company that really got started back in 2011.
EB: And you've mentioned open source here several times. What made you decide to build your product as an open source product as opposed to something closed source?
BA: That's a great question, and you know today if you look at the service platforms that are available, and I'm thinking of products that are somewhat similar like Parse or Kinvey or StackMob. They've released those products as you know platform as a service that they're going to host those applications for developers. And that's maybe fine for consumer products, but we're really from the enterprise side of things. And we just recognize that it had to be an open source product that people could install on their own infrastructure, because the enterprise has all kinds of reasons why they – you know how they have to provision an app, how they have to roll it out, how they have to maintain it, back it up and support it. And you know not to mention security being just a huge issue where it's just not gonna work for us to try to host you know the world's enterprise mobile applications; you know I just don't think that's gonna be possible. But with an open source product they could install that on their own infrastructure. They could manage it, and it really was a great possibility. So that's the direction we went there.
EB: Okay. And you're based on I used to say a LAMP Stack, but there are so many interchangeable databases and things now; I guess it's not necessarily a LAMP Stack anymore, but certainly DreamFactory has developed in PHP. Can you share any of the thought or the reasoning for using PHP over maybe some of the other available languages?
BA: Yeah, absolutely. We did think about this a lot, and you know for one thing we looked at Java, and that was definitely a possibility, although I have some questions about you know how open Java is anymore.
EB: That makes a lot of sense, particularly when you have an open source product and you want people to be able to engage with the product itself and perhaps extend and even customize it. You want it to be in a language that they're comfortable not only running but working with.
BA: Yeah, I really agree. And that's actually – we have some interesting new features coming up that really help people do that, so that's another important consideration for an open source product.
EB: Cool. Any features that you can share with us?
EB: Wow. I know you have other features to talk about and I definitely want to hear about them, but you know as someone who is not a mobile developer just listening to that, it sounds like you must dramatically reduce the amount of time and effort required to build very data-rich mobile apps. Am I understanding that correctly?
BA: That's a big part of our goal. And it's an exciting paradigm shift really, because in the website-building world, people work on the middleware tier, really server engineers, bringing all these data sources together to build a webpage that they send down to the browser, that you know is a fairly dumb device. It just renders the page.
BA: In the new mobile paradigm shift, all of those server assets are baked, and they're just exposed through the REST API. And so what happens is that a single engineer or a small team can just build the client user experience and call the services and build incredible applications with a much smaller group of people involved. And so that is totally the development model we're trying to enable. And you hit on it exactly; you just go hook up the asset on the back that you need with the admin console, and then you just go to the client. The SDK already has the glue to use that thing, and you just think about the user experience and the graphic design and how you want to build that client. And it's really a game-changing difference.
EB: Very cool. Yeah, I can just imagine you know from someone in an enterprise IT department or development group who's already so strapped for resources and time but has this audience of employees or customers, as I guess they think of them, who are demanding you know mobile apps and access to their company data and the tools that they need to do their job on mobile devices. This has to be incredibly helpful for them.
BA: It is. And those guys need to be able to leverage the existing databases that they have, their existing data sources, and through Active Directory leverage the same roles and permissions that they're already using for their web apps or their internet and then deliver that exact same data with the same permissions to the client. And then the client application is going to have to change. You know they don't want a website anymore where they click get a page, click get another page, and they're delivering a giant HTML packet down to the client. Now they've got a smart client and they're communicating with very agile JSON packets, which are gonna be 20 times smaller than the corresponding HTML. And it’s really a game-changing different way that they can use their old data with a new app.
EB: Yeah. And all the you know LDAP support and OAuth and things like that have to be incredibly helpful too. I hadn’t really thought about the need and the ability to hook up to all of these existing systems to control who has access to what as well. So that’s very cool. So I know I took us a little bit off course there, 'cause I really find that interesting. But what are some of the other features that you have coming up?
BA: So another really big issue is server-side scripting and server-side events. So if you think about a REST API where you’ve added a couple of databases, a couple storage systems, a couple external systems, and you’ve now controlling authentication, which users can see which pieces of data and everything like that. It’s like a tree of data sources that come through the REST, through the URL command, you know the string of URL parameters that lead you to the REST asset. And so with server-side events, you can receive a message whenever any one of those nodes in the REST tree is being used. So for example, every time somebody gets an account record, you can get a message. And then with server-side scripting, you can change what happens on any of those nodes. So for example, if an account is created where the value of the account’s more than a million dollars or something like that, you can receive an e-mail. Or when a user changes an object, you can create another object that remembers what happened. Or when a particular type of action happens, something’s created, something’s deleted, you can send an event to the client.
EB: It sounds like it. And do you have any target release date for that feature?
BA: It’ll be in the next two months. It won’t be this month, but I think a month from now we’ll probably be ready. So we’re putting the final touches on it, but have to do a lot of testing to make sure that it’s secure and that it’s gonna be easy for people to use. We’ve been working on it for a long time, and we really want to do a great job of that and make it really easy for people to change the things they need to change on the server side but to do it in a rational way so it doesn’t kind of take us back down the road of lots of complex server-side software.
EB: That makes sense. And are there any other features that you’d like to share with us right now?
BA: Sure. There’s one other really good one. For both SQL and no-SQL data sources, we let you from the admin console put a filter on them. And so what this lets you do is, for example, you could set up a certain user role to receive a certain object but only if some condition on the object is met. So like this role can only see accounts that are less than $1,000.00. Or on this role they can only update objects that they created. So very simple use cases like that we’ll be able to implement with no code at all, just by typing in a couple things into the admin console and configuring the back end. And that handles a really large number of security and other use cases around user roles.
EB: Yeah, I could see how that could be a huge time saver and deliver a lot of additional value to people in the enterprise who have those kinds of requirements. You mentioned no-SQL versus traditional SQL databases there and earlier in our conversation. I think you’re kind of in an interesting position because you’re a services platform and you have the ability to hook together all kinds of different services and support all kinds of different services. So you must be seeing some interesting trends there. I mean what are you seeing around the move from traditional SQL databases to no-SQL databases?
BA: That’s a great question. I want to make two points. One is on the back end there is enormous variety. If you look at you know DynamoDB, MongoDB, CouchDB, they’re really different. But on the front end of our REST API, we treat all no-SQL databases with a single interface. We do the same for SQL, so on the back end everything from Postgres to MySQL, DB2, whatever, but on the front end they all have the same REST interface through DreamFactory. Same with file storage; wildly different on the back, all the same on the front. And so what happens is this means you can switch out back-end services without recompiling the client application, and it stops lock-in to any particular service. And so it’s just an interesting attribute of a service platform that has this mediation layer. And then it really provides you an interesting look at the difference between no-SQL and SQL. And no-SQL, developers really like it because of the document-oriented nature of the data.
So you might have an account with a related list of contacts or related list of leads or whatever, opportunities say, and that might be a no-SQL document. But the interesting thing is is that our SQL interface supports related objects in the query, and they’re delivered as subparts of the document. And so we really blur the line between the difference of no-SQL and SQL, because you can use your SQL database and we'll dynamically deliver structured documents of the arrays and the sub-elements that you’ve requested. And then you can make changes to those as if it was a no-SQL document and then push it back and we'll figure out all the changes, re-parent any differences that you’ve made, create any new children objects, and it’s just kind of automatic. So it’s interesting to see all of this develop and all of these data sources and how people like to use them.
EB: Yeah, especially when they’re all coming along so quickly. And as you said, they’re all different, right. They all have their advantages and disadvantages, and being able to switch out the database without recompiling the client-side app has to be huge for developers who want to try or feel the need to move from one technology to another. It gives them a lot more flexibility and like you said no lock-in.
BA: Absolutely. So if you need to go from Amazon to Azure. You know need to go from on-premises to the cloud. You need to go from dev to test to production, you can do that on DreamFactory services platform with no changes to the client, just by setting up the back-end configuration differently. So it’s interesting to see how that enables some new things.
EB: Yeah. So you know you’ve touched on a few different examples of how people can use specific features in DreamFactory. Can you talk about some interesting use cases or apps that you’ve seen built with DreamFactory, even if you can’t mention the names?
BA: Sure. Since we launched in November, we’ve been out really about six months, and there’s just been really rapid adoption of the product. And we’ve seen some really great use cases coming to the floor. With HTML5 we have good support for both Angular and Sencha, and so that’s a really vibrant community. And so we’ve had some great you know one-page rich apps written that are on various app stores and do all kinds of different things for you know database access or collaborative use of data. We’ve had a couple people write conventional websites on top of DreamFactory, which actually works just fine and may be the model of the future, quite frankly, as things move to services, something to think about. We’ve had a number of people write Native mobile apps on android and iOS, and some of those are really beautiful and you can you know use all of those services just in the same way. They are from Native mobile; there’s no barrier at all there. And you know really for Native mobile, they can’t use HTML, so they’ve got to do something different. And everyone’s moving to REST and JSON as the way to provide collaboration in that situation.
EB: That is very cool. I hadn’t thought about that use case before, and I don’t know if you had when you first started out either. But it makes a lot of sense, particularly like you said as everybody’s trying to move to more of a services model and partners are looking for and demanding access in some cases to that type of data to strengthen their partnerships with companies.
BA: Yeah, absolutely.
EB: Or I should say I guess build on top of their platforms. So you know you’re really the only open source platform like this, at least that I’m aware of, so it might be very new to a lot of people, just the concept in general. And I’d love it if you could talk a little bit about how people can get started with DSP. I mean obviously they can get it from Bitnami, which is great. But once they have DSP up and running, you know what would you tell them to do to get started? What resources are available to them?
BA: That’s a great question. So we do have a free hosted edition on our website, which is there for dev and test. We are not trying to host the world’s mobile applications. We really depend on Bitnami for people to go get the software package, and then they can install it on Azure, on Amazon, on VMware. And then Bitnami also has some great paid hosting options. You’ve even got a one-hour free trial. You can also put it on your desktop, so it’s just really versatile how you can get it. Once you do, you just go to that URL where you installed it and you’ll get our admin console. And that’s an HTML5 application that just uses our own services. And since the first person logged in will be an administrator, they have a lot of additional capabilities that they need to create users, create roles, create services, and to create schema and all of that stuff. But you don’t really need to – you know you could just use the UI for that and set up your back end. And then really the developer’s job is to write the front end, and that’s where the SDK’s come into play. And then that’s really – you know we will host HTML5 files on the platform, and of course for native developers they need to go get you know Xcode or Visual Studio or Eclipse to write their client application.
But it’s easy to understand. It really all comes down to what is the REST API that’s been exposed, and so you know every time you hook up a new database, four things happen. It’s added to the REST API. You have hard documentation generated. You have an interactive console to play with the API from the admin console, and you get that client SDK for whichever platform you’re on, and you just start making the calls. So that’s really how someone would proceed. You could also come to our website, dreamfactory.com, and especially the developer’s menu has all kinds of examples, SDK’s, and downloads, including the Bitnami package downloads, available to, hopefully, one-stop shopping with documentation to make it easy for developers to get engaged.
EB: Okay. And you also have a pretty generous one-month free support offering for people who register on your website, correct?
BA: We do. So yeah, when you install you can start your one month of free support. You can always – even if you don’t, you can always e-mail us with a support question and get started. For customers who need a commercial license and paid support, we have that available as well, and that’s on our website.
EB: Okay. And do you also provide any kind of development services for people who need help with building their app?
BA: We do. We have professional support, you know professional services for people who need help building something. Most of that is gonna be – our role really is to be sure that REST API is there. We do provide some good examples and you know for the client side, and so hopefully that’ll be enough to get most developers into building their first app.
EB: Great. Well this has been really helpful. I think we’ve covered a lot of ground. Is there anything else that you’d like to share with Bitnami users before we wrap things up?
BA: Hmm. No. Just we’re big fans of Bitnami. You guys have really helped us. You know it’s not just distribution and also packaging. You’ve really got a great infrastructure as a service marketplace, and people like it. It really reduces the friction, and that’s what we’re trying to do is make it easy for people to get in and use our products. So thanks, Bitnami. And we’ve got an exciting year planned, and we got a lot of new features coming out that are really being driven by the community. It’s a really exciting product, and I think it’s incredibly forward looking and yet a practical thing to get started with today.
EB: Yeah, absolutely. And thank you for taking the time to talk a little bit about DreamFactory with our users. You know it’s something that I think initially is a little difficult for people to get their heads around. But hopefully this interview and hearing you talk a little bit more about what you can do with DreamFactory will help more people decide to give it a try, because it is really powerful and a really cool product that we’re excited to have on Bitnami. And one note just for Bitnami listeners, we are working really closely with DreamFactory to make sure that we always have the latest and best release available on Bitnami. So as soon as these new features come out, we will make sure that we have the package available on Bitnami. And if you register when you download DreamFactory, we’ll make sure that we let you know when those new releases are available too. So with that, thank you so much, Bill, for your time. I truly appreciate it. And we look forward to all the great stuff that’s to come from DreamFactory this year.
BA: Thanks, Erica.
try DreamFactory for free.