My boss asked me to develop for him a price quotes desktop software (he doesn't want a website), he wants to give the price list and the users of this software would write the prices according to the boss prices, all the bosses prices would be stored on local DB.

I thought about the following idea: to develop two desktop apps, one for the boss and another one for the users (salesman).

    user1+localDB <--------- Boss's management app +localDB -----> user2+localDB 
                                                |
                                                |
                                                |
                                                v
                                            user2+localDB 

What's the best way to communicate between the apps? HTTP? the salesmen would be on the field on remote places, therefore I can't use LAN, I will be happy to hear bits of advice and maybe other ideas about the architecture or other.

  • 1
    What does he mean by the term "website", and why doesn't he want one? – Dan Pichelman Nov 2 at 15:41
  • It depends a big lot of the operating system. You could consider using toolkits like Qt – Basile Starynkevitch Nov 2 at 20:08
up vote 2 down vote accepted

the salesmen would be on the field on remote places, therefore I can't use LAN

Either the salesmen use a VPN to get access to a server on your LAN, or you need an internet-facing server.

In any case, you need a server. This might physically be a desktop machine, however, the server will require additional administration to be reachable: a stable IP address and probably a domain name. It should also not be turned off while people need to connect. For that reason – and because it would be a risky security architecture –, the server should not be identical with the desktop device of your boss.

Given that you already need a server, building a web app would be the simplest thing you can do, unless you already have experience and infrastructure for a different stack in place (e.g. if you are experienced with Access, you might be able to wrangle a working prototype out of that). Another contraindication for a web app would be if the salesmen will not have an internet connection while they use the app. Then, a desktop app with a local database would indeed be necessary. (Technically, progressive web apps can also provide this, but probably require more development effort.)

Even when the system's clients are desktop apps, you should probably implement a server using a REST API – not because this is particularly good, but simply because HTTP is well understood and has great tooling. Additionally, the security implications of REST APIs are fairly well understood, compared to RPC mechanisms.

  • Those last 2 sentences are key. Any place something like this may be used, even the strangest "internet" connection at a hotel, cafe, etc. will be able to handle DNS and HTTPS on the standard ports. And that might be all that they handle, by design or incompetence. – ivanivan Nov 3 at 19:02

Don't overcomplicate it -- One application that enables both your boss and the salespersons to work from will be just fine. For the architecture, just dedicate one section of the application for your boss and another section for the salesperson.

Example, when the application launches you can bring up a log in scree, and depending on who logs in a certain screen will be shown: dashboard and command control for your boss and another screen will be, perhaps with the functionality needed by the sales person will be displayed.

And yes, a server will be the best in this case so I will have to agree with @amon. There are many online solutions outhere can can host your server and databases starting at $10 a month.

  • Great approach too! – Malwarey Nov 2 at 22:10

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.