I'm starting a new side project in order to learn some new technologies and I have several doubts about the architecture I should use. My idea is developing an app both for web and for mobile (Android app mainly), so I think I need to implement the following:
REST API service (with django-rest-framework).
Web application (with django).
Android app.
After researching over stack overflow and Internet I have found 3 main "architectures" for the web part (server-rendering, client-rendering, and an hybrid model). In first place my idea was using the client-rendering model (with backbone or angular for the web client). However, I have seen that the hybrid model is a better choice.
So here are my doubts:
1) Could I use django for server-rendering the web application pages?
2) Does Django web app "use" the API or the API is implemented using the same "library" as the django web?
3) Could/should I use a client framework (angular, backbone) for the web client (being server-rendered) ?
Thanks in advance, and sorry about my short knowledge about django, etc.. This side project is just for that, to improve my knowledge about all this stuff.
I don't use Django but I am currently using Angular with Flask as my REST backend. I think the hybrid approach is useful if your app benefits from caching rendered content. An example would be something like a blogging site where you may store Markdown but render HTML and thus the content is largely unchanging. If this content is shared across many users it can be very beneficial to generate once on the server and serve it to many clients.
However if your reasoning is that because mobiles are relatively under-powered server-side rendering will improve the render time, this does not necessarily hold true. Serving the JSON data model will typically result in less network traffic (obviously dependent on browser caching) which is important for mobile client responsiveness.
For my own part I prefer to render on the client and keep the server-side rendering to some very minimal templates. I find this results in a much better REST API that I can then use to provide external developer access or plug in other client UIs. My client code lives on the client side in Angular, my REST interface is clean, and security is always uppermost in my mind because I have to assume that the client code is potentially hostile.
That said I can see a use for server-side rendering even with Angular. For content that is fairly static it would be great to generate this server side, cache it, and then ngInclude it.
Related
I am developing an android application which needs a backend to process login and store data remotely on a server. I have previously worked with a BaaS service "Parse" for android. but since this is my final year project for my university I need to develop a backend from scratch, I have never worked with web services. I need some guidance on how to approach this and which framework will be the best to work with.
Thanks in advance.
If I understand you correctly you want to build a server application that allows you query data from your android app?
I'm not an expert on this since i just started coding myself, but I did do some research and it seems to be a very viable option to implement a RESTful API on the server side. The wiki article is pretty specific about how it works.
If you can use PHP the slim framework allows you to get a scrappy prototype RESTful API up in less then an hour if you familiar with the server configuration. It seems to be sophisticated enough to drive small and medium sized projects (maybe even big projects; I can't tell to be honest.)
On the start page you can see an example that allows you to query for a "hello, world" string from the API with less then 50 lines of code.
http://www.slimframework.com/
Where the example returns a "hello world" string you would perform database queries using PHP and return your results as json objects to your client.
The benefits of this are that you can use this Backend for different clients: Android, iOS or even your own browser-based web application.
This also makes it easy replace / port the backend once requirements change since it's very easy to implement the same API using other technologies and languages that fit the requirements better.
I know this is a bit off topic, but I really needed some help regarding this.
I am new to Python. I'm trying to build my next project (a dictionary web app which will have both iOS and android app as well) for myself in Python. I've done some research and listed out some promising frameworks.
django
pylons (pyramid + repoze.bfg)
tornado
CherryPy
pyjamas
flask
web.py
etc
But while django is great, it was originally built for newspaper like sites project building. Im stuck with choice making for dictionary like web application which will have to provide RESTful web service api for mobile request handling.
So anyone can you please help in pointing out which framework is the best choice for this type of web app. I think I should go with django. Or should I go with native python coding? Any suggestions will be great.
Django's strength is in it's ORM, huge documentation, and the thousands of reusable applications. The problem with those reusable apps is that the majority is written following Django's MVC design, and as you need a web service, and not a website or web application, most of those apps will be almost useless for you.
On the other hand, there is Django-REST-Framework, extending Django itself, which is pretty good, and it's declarative API feels as if it was part of Django itself. For simple cases just a couple lines of code could produce you a complete CRUD API following REST conventions, generating beautiful URLs, out-of-the box support for multiple authentication mechanisms, etc. but it could be an overkill to pick Django just because of that, especially if you do not wish to use it's ORM.
Flask on the other hand is pretty lightweight, and it's not an MVC-only framework, so in combination with Flask-RESTful, I think it would be an ideal tool for writing REST services.
So a conclusion would be that Django provides the best out-of-the-box experience, but Flask's simplicity and size is too compelling to ignore it.
Go with Django, ignore its entire templating system(used to generate web pages) and use Django-Tastypie for REST service. Easy to learn and set-up is instant.
I am involved in developing application for mobile sensors, data from these sensors is to be collected using Android/iOS mobile apps. We want the end users to be able to view this data from desktops also. This data is uploaded to be uploaded to our own database(s) from the mobile apps. I have done this development of the prototypes using native applications (iOS/Android) and implemented web services using Django 1.6 with SQL database. This was just for prototype.
We are at stage where we really need to make this into real product with paying customers, so we are in position to revisit our technology stack question. So I am looking for suggestions.
Currently I am thinking of using Play Framework on the server side. I really haven't seen anything compelling that can provide Native app like feel so we will have to keep developing mobile apps using native libraries. We will interface with our web services using REST API. My concern with Play framework is it doesn't seem to have lot of plugins similar to django, but its early days hoping that situation will improve.
Is this right approach we are very small team ( 4 people, we can hire 2 more probably). Given this is this right technology path I am choosing anything I should be looking at?
I have looked at Parse library but doesn't seem to offer too much data flexibility, geared towards more social media aspects.
We will be using StromPath for user management, any other choices I should be looking at for user management?
We really don't want to do a lot of MVC programming on client side, so on desktop app we will keep it simple jQuery/Javascript & html
-Sam
With jQuery mobile you can assure the look and feel like in a native app. The library it self does media queries and stretch or shrink the content accordingly. So in terms of UI you will not face any problem providing native app like look and feel to the users. For client/server communication I recommend normal ajax functionality so you can dynamically add content.
When working with JQM there are certain rules that you will have to obey.
I am using Backbone.js to build a 'hybrid' web app, which will be served as a native app using Phonegap. One thing I need is offline support for a large amount of data, and so we are considering using native code to synchronise the offline data with the server, and just transfer the bits of data we need to the web app when necessary. (An alternative approach we considered was using the Phonegap storage plugin but this is backed by WebSQL which seems to have a 5MB quota, which is too small for what we need).
As the app is based on Backbone.js, which expects a RESTful API as its backend, we are toying with the idea of embedding a RoutingHTTPServer into the native layer - essentially this allows us to embed a local web server in the app, so that the web layer can request data using standard RESTful calls to the local server. The beauty here is that the Backbone app doesn't know any different - the workflow is entirely the same as requesting data from a remote server.
I was wondering if there is an equivalent of RoutingHTTPServer for Android? I have seen projects like iJetty, but ideally I would like something which gives the REST-API bit out of the box too (like RoutingHTTPServer does). Would something like Spark work on Android?
Try MiniWeb Java Embedded Webserver. It is built for Android, super easy to setup JSON REST requests and open source.
I am having a browser-oriented web app build on Rails (3.1). I want to make some features of the web app available on mobile devices, too.
Besides...
1.) Building native apps for each vendor of devices and interacting with my rails web app using JSON/XML, ...
I am thinking about reusing as much as business logic already implemented in my rails app by reusing controllers/models and add some new views targeted to mobile devices (in terms of screen size and the like...).
With this approach, I see two alternatives:
2.) Let the end user access the part of the rails app targeted to mobile devices in the mobile browser.
3.) Set up a native mobile app wrapper, e.g. using PhoneGap, and refer to the same part of the rails app used for 2.).
The advantage of 3.) is that I can reuse business logic of my rails web app and having a "phantom" native app for mobile devices at the same time. (I used the term "phantom" because besides the wrapper, it's not really native, this approach actually just mimics a native app.)
Question 1: Are there any other alternatives besides 1.) to 3.) ?
Regarding 3.)
Question 2: Does Apple accept this kind of apps (which fetch large portions remotely) to be uploaded to the app store?
-> I would be surprised if it is so, because it would allow one to change large parts of the app without the notice of Apple.
Question 3: From an architectural/technical point of view, is it recommended to remotely fetch prerenderd html/js to be executed in a "phantom" native mobile app build on top of e.g. PhoneGap?
-> Wouldn't it be better to set up an independent client app within the native mobile app (maybe using backbone.js), keeping all html, css, js locally within the mobile app, and communicate with the backend using JSON/XML or whatever?
I think this is a good question and I've recently come across similar difficulties. I've ended up using (Q3) vaadin with touchkit. Fine if you're doing free but a bit expensive if you're doing commercial (although then you can probably afford it). I realise this doesn't relate to rails but still, I'm assuming the main point of the question was should I build native apps which use web services / middleware or go for pure web apps.
RE (Q2), during my trawl of this current technology, I did read a few articles suggesting that apple are not allowing the web app style. As in, app which simply masks browser window loading remote web app. Essentially, I think where apple are concerned, you'd need to have the functionality tied down to what they agreed to. This doesn't really affect web apps though as you can surely just access them directly from the browser.
RE (Q1), the only alternatives I can see would be different middleware (e.g. MQ, SOAP etc).