My general feeling is that this is a question which must have been answered but I am struggling to find resources for it. I know little about mobile app dev but my knowledge of web services is pretty good.

We are looking to expand our existing software suite to include a mobile app.

Each client has the software and databases installed on their own servers. The actual data is very client specific. The services will be developed internally & the app itself outsourced. Basically what needs to happen is:

  • We need to create web services hosted at each client to expose the information in the DB.
  • The mobile app needs to connect to a service which gives it the correct info based on the user.
  • New clients could buy into the app at any moment

So I've thought that we could possibly host a "routing" service, which means the app only connects to one service and it figures out where to go according to the user credentials. I think this could slow things down considerably, although it would be easier for the actual app dev. Since we own the service adding a new client would be easy.

The alternative is for the app to be able to figure out where to go based on the company and credentials the user enters.

Could I be missing other alternatives?

Can anyone help with resources or advice around this problem?

  • A single call to your routing service which figures out the base URL for user X should be www.clientx.com, wouldn't seem to add that much over head. Unless I'm missing something? The client could then even cache this URL end point locally on the client along with username and password if the user stays logged in. – Cormac Mulhall Aug 28 '15 at 16:08
  • Oh yeah of course, it wouldn't need to always go to routing service, just on login! I knew I was missing something thanks. What if the clients have different security around accessing the web service? – nicV Aug 31 '15 at 7:49
  • In that case you could have all the secure happen on your webservice, which contacts the clients web service on behalf of the client. This would be slower, as there is a middle man for each request. But this shouldn't add that much latency if you make sure your middleman webservice is nice and fast with a big pipe. – Cormac Mulhall Aug 31 '15 at 9:30
  • @CormacMulhall Hmm ok so there is definitely a trade off here that we would need to work around. I also think there will need to be some analysis of the clients security. I'm glad my initial idea wasn't too far off, first time working on something like this. – nicV Aug 31 '15 at 12:38
  • Generally security will trump network speed every time. The latter is easier, you just pay for a faster pipe. Where as if you have a broken security model that can be a pain to fix. Security matters if you have only 1 user, where as speed only becomes an issue with thousands of users (ie a good problem to have). I would get this working with the mobile app talking to your server, which in turn talks to the remote apis. You then have complete control on your server over how you authenticate the user, which remote apis you are aware of and how you authenticate with the remove apis. – Cormac Mulhall Aug 31 '15 at 13:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.