IW: How do people use Servoy? Why do they like it?
JA: Most of our customers are ISVs. One of the things they like is that they can generate a SaaS Web application and an on-premises native client application from the same code base.
Another issue is multitenant applications. Most environments require you to know what you're doing with multitenant, and there's a lot you need to do yourself with cross-tenant security. Servoy has all of that built in.
SaaS applications usually use a browser. If you think back to the days of client-server applications, we had the right ideas, but there were problems with two-tier deployment when we moved the applications to the Internet because you had the client talking directly to the database, which was hard because of blocked firewall ports and proxies set up to maintain security. Servoy does N-tier correctly, which eases the deployment problems. We even have an HTTP tunnel we can use that completely eliminates proxy and firewall issues, and recently we have optimized the tunnel performance. We used to be about as fast as Terminal Services or Citrix; now we've decreased the roundtrip time and added compression, so we're faster on the same hardware. ISVs appreciate this.
IW: You've been getting some FileMaker developers to upscale to Servoy. What makes them give up their easy-to-use tools?
JA: FileMaker has some good ideas, but the Web implementation is not scalable. They've got a single-threaded engine, which damages scalability, and some of the desktop functions don't work on the Web. What I tell FileMaker developers is "When FileMaker switches its Web site to run on FileMaker, then it'll be a good product." At Servoy, we dog-food our product on all of our own Web sites.
We're also different from PHP and ASP.Net. Out of the box, we have stateful Web applications, where PHP and ASP.Net are stateless. We only use the browser for display and the user interface; you can think of it as heavy AJAX, with everything going through the server and optimized incremental UI changes coming back to the browser. That makes the application lightweight, secure, and debuggable. We think that in the longer term, most players will go to that model.
In the same vein, we optimize what's going to the database. Think about a screen with 40 data entry fields that update multiple tables and possibly multiple databases. Most systems would have to update all of the fields in all of the tables; Servoy can pick out just the changed fields and send the smallest possible updates. That results in a much lower load on the database.
IW: Thank you.