I am a VFP-software developer in the Netherlands. I want to extend my desktop client-server App (VFP 9 with SQL Server database, integrated geo) with mobile apps. My customers work with their own database (local or hosted by some hostingcompany of their choice).

I will be responsible for building the webservice. Another company will build the apps. They work with ‘Meteor’ or other tooling. The apps will be used to present data of the SQL Server database to the user and to modify data.

My desktop App contains the business-logic. In the past, I have allready built a COM-server (with the same business-logic as the desktop app) to give access to some tables of the database for some other application (.Net).

I have seen the demo-video on your website about ww Web Connection and IIS Express. I would like your advice on ‘best practice’:

Is ww Web Connection the best option for me to create the webservice? (Only requests by apps, no user-interaction)?

Is it better to move the logic of the COM-server to the ww Web Connection project and stop using the COM-server?

Or is it better to use ww Web Connection to only translate the commands and let the COM-server handle them?

When the business-logic changes, I have to update the webservice of my customers, which sometimes runs on a server of a hosting company of their choice. What is the easiest way for me and my customers?

Can I automate the installation process?

Do you charge an additional fee when the webservice (exe) runs on a machine of my customer?

With Web Connection you are creating a FoxPro application - the server is just a FoxPro application. For a deployed application the applicaiton will run as a COM server, during development you run as a standalone application in the FoxPro IDE that you can easily debug. The application is self contained and other than IIS you don't need anything else.

Hosting

In order to deploy the application you need to have an IIS server to host it on. Either an in house server or I otherwise I'd recommend renting a cheap Virtual Machine like Vultr, or a (more expensive) Azure or Amazon Web Services. You do need control of the server, so shared ISP hosting is doable but not really recommended as it's often difficult to set up. These days a dedicated VM or running as a subsite on an existing in-house managed server is the way to go.

To update code you'll have to recompile and redeploy the executable. We have remote update features built into Web Connection that allow you to do in-place updates as well as configuration scripts that can be run to get a server configured.

The alternative is you build a .NET service of some sort and either use OleDb to access the data you need directly (ie. rewwrite your business logic) or you use FoxPro COM objects in .NET. The latter is a bit of a pain as you can't easily debug and manage errors etc., but it can be done if you're patient :-). There are number of issues you have to deal with though like STA threading in anything outside of ASPX and a few other issues. You can find more info on that in some of my White Papers.

If you're building something fairly simple I would definitely consider OleDb and just doing it all on the .NET end. But if you have complex logic you need to run in Fox, then Web Connection is probably the better choice.

Licensing

Licensing for Web Connection if you choose that route works like this: A dev license includes a license for a single developer (you) and one physical server deployment. Any additional developers or physical machines require additional licenses. If you have a single customer then the single dev license is probably all you need.

Thanks for your reply. Your instructions, walk throughs and whitepapers are very clear. I enjoyed reading them.
I still have a few questions:

Deployment:
You replied: "For a deployed application the application will run as a COM server..." and "To update code you'll have to recompile and redeploy the executable. We have remote update features built into Web Connection that allow you to do in-place updates..."
Question: Does the in-place update mean that the service won't be available for a while?

Licensing:
I am still trying to figure out how many licences I need. I have about 20 customers, each having their own server with their own database and their own desktop-application on it. I have my own company and I'm the only developer. On my machine I have a developer-copy of the database.
You replied: "If you have a single customer then the single dev license is probably all you need."
Question: Do I need 1 or 21 licenses of ww Web Connection?

You replied: "In case you don't know it, you can build a responsive Web app. out of your desktop VFP app. using FoxInCloud V 2.24 (WW Web-Connect based)."
On https://www.meulenkamp.nl/contract-administratie-systeem-ca3/ you can see some images of my current desktop app. It is a big VFP-app (based on Visual MaxFrame Professional) with an integrated web-based GIS-viewer (sorry for the Dutch-language-only on my website, but the images will give you an idea, I think). The data is stored in MS SQL Server. The GIS-viewer runs in an OLE-control (Active X). The app is not scalable (only for desktop-screens), has no touch support (only mouse and keyboard).

Is it in your opinion meaningful or even possible to turn it into a cloud based app with FoxInCloud?
If it is, do I need ww Web Connection to make it work? How many licenses do I need (both FIC and WC). I'm the only developer, about 20 customers who mostly choose to have their own servers. Can you paint the picture a little bit for me?
FI: How is the performance compared to desktop apps?

As long as you want to expose some of your app on the Web, you can do it either by (re)writing HTML/CSS/JS and back-end logic or by re-using all or part of your app code through FoxInCloud.

Technically, the only question is around your integrated web-based GIS-viewer; as it's web-based it can probably be included in a FoxInCloud-generated form as in this example. The rest I've seen will work on the Web with FoxInCloud, responsive, even the 7-page pageframe and the multiple grids.

You can 'adapt' a subset of your app, existing forms and/or new forms focused on the functionalities you need to expose. If you have good class libraries (and you probably have), you can put together more simple forms if you feel like it.

Any web app is slower than the corresponding desktop app, not only because of the Internet time (back and forth), but also because the server needs to maintain the user's state on each request (save, and restore if another user has chimed in between). Our live tutorial shows detailed response time on a bunch of different forms, more or less complex, this should give you an idea. Please note that our current server is 4-year old (CPU E5-2630), server times would be cut by half on a recent config.

The real question is how Web apps compare to one another, and FoxInCloud has always been pretty competitive in that area, and provides a lot of optimization insight

If you think that your clients will ask you more and more web-based stuff without willing to pay for the corresponding developments, and/or maintaining a double code base (desktop and web) could become heavy for you, then FoxInCloud is probably a good choice for you. Some of FoxInCloud clients have deployed a FoxInCloud Application for over 60 client companies; they use standard tools provided by FoxInCloud to batch update all these servers.

You'll need to learn how to adapt existing code and write adapted code (the 'FoxInCloud' way), which is pretty well illustrated by the source code visible in the FoxInCloud Live Tutorial; you'll need almost no HTML/CSS/JS knowledge, all you'll have to do is in VFP.

Note that FoxInCloud is not a VFP dead-end as it generates HTML/CSS/JS elements that you wire to different event handler addressing different back-ends; our mission is to provide to the VFP community tool that help them:

If I can be of any assistance in evaluating or implementing the adaptation of your app to FoxInCloud please let me know. We have extensive experience in FoxInCloud adaptations, and the product operates and performs exactly as advertised.

Hmmm... I'm confused. Evert weren't you asking about building a Web service to externally access data on the site remotely? IOW, I thought you were asking about creating non UI data service. For that scenario FoxInCloud is not really the right call as it is essentially a UI framework to let you run FoxPro forms on the Web.

As to your questions:

Is it in your opinion meaningful or even possible to turn it into a cloud based app with FoxInCloud? If it is, do I need ww Web Connection to make it work?

Thierry and Tuvia can answer questions about FoxInCloud. If you're trying to build a brower based Web application then FoxInCloud is certainly an option. But if you're building a service based application then plain Web Connection is all you really need.

FoxInCloud runs ontop of Web Connection so yes you need Web Connection to run it and all the licensing that applies with Web Connection. FoxInCloud has its own pricing on top of that and can provide the bundling.

Licensing

As mentioned licensing works per physical machine. A dev license is a single license for a developer and one go-live license. Any additional machines require a license as well. However we do have license packs that are discounted heavily over individual license pricing.

How many licenses do I need (both FIC and WC). I'm the only developer, about 20 customers who mostly choose to have their own servers. Can you paint the picture a little bit for me? FI: How is the performance compared to desktop apps?

So for you you'd need a developer license + the 25 license pack for the Web Connection end of things. I'm not sure about the FoxInCloud pricing you need to check with them on that.