Mobile App - Server Architecture
Asked Answered
F

2

5

I want to start a mobile application however I got some questions. I am confused about database connection layer. Should I construct my architecture 2 layered; 1st layer is mobile app (making the database connection in mobile app), 2nd layer is just database. Or 3 layered; 1st is mobile app, 2nd is server (which handles the connection between database and app), 3rd is database.

What are the pros and cons of these two architecture? Thanks in advance

Folk answered 6/2, 2012 at 18:46 Comment(0)
O
10

The only advantage of having the mobile app communicated directly with the database is that it might be faster to implement in the short run.

In the slightly longer run, three layers are a much better choice for several reasons:

  1. Flexibility - have the mobile app work against a service layer (for example, through some JSON APIs) that abstracts the database internals. This will make it much easier to make changes to your schema, even replace the entire data layer, without breaking the mobile clients. This is critical when you release new versions that involve changes to both your mobile app and your data layer, and have some apps out in the field that didn't update yet. A service layer will make support for multiple versions manageable. Working directly with the database would make it very nearly impossible.

  2. Security - managing user logins, permissions etc. is usually not as well supported in the DB as it is in a service layer.

  3. Scalability - should your app succeed and you'll need to scale the server side, a service layer would greatly increase your options (going back to no. 1 - flexibility).

  4. This should be enough to get you convinced, but I'm sure other replies will come up with more :)

Regarding your other questions - recommend a technology/architecture for the server, there are lots of viable options - Ruby, Python, PHP, Node. The "best" depends on what you're already familiar with.

Outrange answered 6/2, 2012 at 19:1 Comment(0)
W
1

In the first case you described, you're talking about a local database for a mobile device. Depending on requirements for your mobile app this could be sufficient. A simple case: a mobile-only "TODO" application. All the entries entered into such app can only be read from within the same app and they don't get synched to a central server (cloud).

Let's say "TODO" became on overnight success and you want to release "TODO 2.0" with an ability to sync 'todo' lists between different mediums: a web site, a desktop app and a mobile device. You will have to introduce a server in this picture that would store "TODO" database and facilitate an access to it. Your mobile app can create in-memory list of 'todo' items as it reads them form the server, OR it might still have the local database as a simple cache.

Wouldbe answered 6/2, 2012 at 19:4 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.