I’m struggling getting my head around writing a server for a mobile app. The app is quite simple and would manly rely on geographic data and some other basic stuff liker users etc. nothing special about that.
What I just can’t find an answer to is what I should use when it comes to a Web-API for server/client communication and what relational database system I should use.
I’d just need somebody to draw me a picture about how a server looks like and what options there are (just a few) for the main parts of it. I am not an unexperienced programmer – just one who has never written a server for a mobile App.
5
what I should use when it comes to a Web-API for server/client communication
- Use a REST-style API over HTTP(S) (e.g.
/customer/<key>,/product/<key) - Use application/json as the content format
- Use a user/apikey or better OAuth2 authorization scheme
- Don’t fall for the WS*/XML variant with all their proclaimed advantages like security contexts or well structured documents. YAGNI
I found this guide useful.
what relational database system I should use
Depends on your specific use case, and your web framework. Typical options:
a. NoSQL like MongoDB, CouchDB – provide JSON APIs out of the box. If you don’t need any server logic other than data persistence & query, maybe a good choice
b. SQL like MySQL, PostgreSQL – the internet workhorses. Only makes sense in combination with a webframework. My preference: Python-based Flask (somewhat hard to grow with) or Django (somewhat harder to get started, easy to grow with) – depending on your language of choice there are many more to choose from.
c. Commercial BaaS (backend as a service), e.g. Parse or many others
I’d just need somebody to draw me a picture about how a server looks like
I have ample and positive experience with the following stack:
-
App: Phonegap/Cordova as the cross-platform framework, requirejs and backbonejs to modularize apps
-
Server: Django with django-tastypie as the REST API, based on MySQL and in parts MongoDB for file and document storage.
-
Asynchronous processing is handled by Celery over RabbitMQ.
In this case the server implements the data model as Python classes, which are mapped by Django’s ORM to the DB backend (pluggable backends, so the actual DB is of litte concern). The models and/or additional modules contain the business logic, which is agnostic to whether it is used by a remote client or in server-side view code.
The REST API sits on top of these models, and is provided by several tastypie-based resources that in most cases map 1:1 to the models, in other cases they provide some intermediate processing logic such as when there are multiple models involved to satisfy a query.
3
There are a lot of tutorial type articles on the web around node.js which was the new hotness for writing applications for the other new hotness of mobile development. In the ones I read they all seemed to want to use a NoSQL DB such as mongodb.
But the concept is the same – you write a server in whatever language you like, that exposes a networked interface to the clients that connect over the internet – so it makes sense to write your server as a web server that exposes a REST interface. The server then stores data in a database, whether its a relational one like MySQL or something new like MongoDB doesn’t really matter.
So its very simple: client -> webserver -> DB.