I am new to both Django and Rails. I am thinking of developing an Web 2.0 style application and is planning to expose Restful services, which my UI tier would call to make CRUD operations (Something similar to ADO.NET Data services)
I am yet to decide on the platforms and is looking for some advice on which one to side develop on?
I am currently thinking of Ruby on Rails or Django.
The benefit of using DJango / Python is that I can move to google AppEngine in future with some code changes, but on the down side I hear DJango is not RESTful.
I am also new to both Ruby and Python. So, what would be your advice on which platform to use?
Well if you want to couple the view and controller with REST then you are right that django is not RESTful, because with django you would have to (de)serialize django objects and manipulate that by yourself in the front end using your favourite javascript framework. Saying that, if your only concern is to send and receive data RESTfully without caring how to do it, then django should be sufficient for you since you've already got your heart for it.
Django is fine for REST applications. Rails claims to provide some functionality to that makes REST easier, but it is largely inaccurate - things like human-readable URIs don't really matter to REST. Rails auto-generates POST/GET/DELETE/PUT stuff for you, but it's just as easy to do in Django too - and it really doesn't have much to do with REST, either, it's just proper HTTP usage.
REST is a general type of architecture, it has very clear constraints, but there is no one, single way to do a REST application. This is a good discussion by the architect of REST, Roy Fielding, on some common misconceptions: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
I recommend Python and Django, but not for REST-related reasons. (Better documentation, a saner API with Django, less nasty monkey patching and black magic, less coupling, etc)
A RESTful interface is used for building distributed applications. Does your UI tier and services tier really need to be physically separated? Seems overkill to me.
Related
I have a running java application which has some APIs, but none of them follow the REST standards. You need to use separate APIs(some are XML/JSON based and others are SMTP based) to achieve CRUS operations.
I really love the MVC architecture and the strict RESTfullness of ROR, so I am thinking to write a API only ROR service using rails-api gem. Is it recommended to write wrappers like this over the existing APIs to provide better REST APIs?
Note: The existing APIs are very old and I don't want to rewrite them from scratch.
Whether or not it's "recommended" depends on your needs, your timeframe, the ROI, etc. There's nothing wrong with writing a RESTful layer over existing APIs, if that's what you're really asking.
I prefer a "regular" API over one that has multiple access methods, irregular access patterns, etc. If I have the time and resources, putting a layer of abstraction over complexity is almost always valuable.
I started in the web development world with PHP, and then Rails in the recent few years. Since then I've been doing all my web projects in Rails.
Recently there seems to be a movement towards making Rails as a pure RESTful backend service and using frontend framework such as Backbone.js for all frontend interaction. I'm wondering what's you guys' take on it? Will this be the eventual future?
As well, besides Backbone.js, what are some other alternatives for frontend framework for this purpose?
Also assuming that I will want to support both a desktop version and a mobile version of my app, would this be a proper route to take? So I'll have a single backend service with different frontend services? This way I don't need to manage all the views on Rails' side?
Thanks!
For Client-side frameworks, this article has a list of 20 of them with pro's and con's:
http://net.tutsplus.com/articles/web-roundups/20-javascript-frameworks-worth-checking-out/
Here's the list:
Backbone.js
Knockout.js
Asana luna
Cappucino
Sproutcore
BatmanJS
corMVC
TrimJunction
pureMVC
jamal
choco
sammyjs
extJS
agilityJS
eyeballs
activejs
spinejs
qooxdoo
These are roughly all about creating client-side, ajax-based, javascript MVC frameworks.
If you're looking to start somewhere, then I recommend thinking about Client-Side Templates (...ates...ates...ates) (just the "V") to support a service-oriented architecture (many clients are supported by service-endpoints you create).
It's a new technique that involves modularizing your client-side code, bringing MVC to the client, and let business-logic live in the platform. A lot of Software-as-a-Service applications are leveraging them, and with the increasing sophisticated of javascript libraries and frameworks, as well as browser capabilities with HTML5, CSS3, etc. there's going to be an increasing sophistication in client-side presentation.
So learn it.
What are the benefits?
To paraphrase Linked In: for leveraging browser-caching, de-coupling your front-end client-side presentation, asynchronous load, progressive rendering (for some frameworks), performance, ajax-interaction, and more.
Several great frameworks include:
mustache
dust.js
handlebars
Google Closure Templates
Nun
Mu
kite
I highly recommend looking at Linked In's move away from JSP towards Client-Side Templates and why they choose dust.js in Linked In's front-end client-side templates throwdown for a comparison. They go into much greater detail, and research, as to why they changed their stack to support this (it involved using 3 server-side technologies), as well as their comparisons of all the frameworks they could find.
I did something like this a few years ago in .net. Is was not via proper .NET MVC and didn't use the new JS frameworks, but the principle was the same; server code returns JSON to javascript which builds the page and interactions etc.
The result was a lovely responsive website, but, maintenance was a nightmare. Be very careful to keep your JS code well organised.
Personally, I find it easier to maintain server code (in any language) than javascript so I wouldn't go down that route again.
(IMHO)
Fran
It is my opinion that contemporary web applications are moving towards this model of having RESTful back-end and all the view interactions coded in front-end. These free video tutorials from Joe Zim:
http://www.joezimjs.com/javascript/introduction-to-backbone-js-part-1-models-video-tutorial/
helped me understand backbone and how it can simplify templating and view renders.
I'm looking at building a simple login-based iOS application that needs secure access to create, read, updated and delete data from a MySQL database - with certain actions available to specific users based on roles.
I've done some research and it looks like I need to build a RESTful Web service which provides Web Services which the iPhone app calls to access the data.
I have very little experience of web services development, are there any books/tutorials that are worth checking out? Is it worth looking at a web framework, rather than start from sractch?
I've done some basic web development in PHP/Python so would prefer to build in that I think..given that hosting it would be relatively cheap..
Have done some basic C#/Java; would it be worth looking at these instead? I tried creating a simple ASMX webservice but most of the examples cite using a MSSQL server, not sure if that is the way to go though.
Use a framework. No point reinventing the wheel and giving yourself a headache. A good PHP based solution would be to use Drupal to build the backend using the Services module to provide data via webservices. Drupal is so flexible and so popular now, that you can get a lot of what you want done without any code at all.
Roughly:
Install Drupal 7 on a webserver according to the instructions
Install the Services module
Design the entities that will make up your MySQL database
Tell the services module how you want to expose things
Some examples of API calls are here.
A case study of someone else who has used Drupal as the backend for iPhone/Android is here.
You will have a learning curve to get your head round Drupal, but you'll have one anyway to get your head around webservices and the benefits you gain from having everything else Drupal offers are enormous, e.g.
The difficult bits are already done for you, so the amount of code will be massively reduced, if you even need any at all
Using Drupal's hugely flexible entities system, you can design a flexible and extensible mysql database scheme using the web based UI, which will be ready to work with any of Drupal's other modules, so you can expand add features with minimal effort in the future
There's an enormous community of people who can help you and the forums on drupal.org are very active
You would have a great UI for users, in case you ever need to give them access to their data through a normal website interface. Drupal has loads of pre-built themes (I recommend Omega) which look awesome and again, little to no code is needed to get a whole site ready made along with HTML5, standards compliance etc.
Drupal provides you with ready-made modules to provide access control via roles, as well as everything else you can imagine e.g. managing a mailing list for your users, providing you with usage statistics, admin interface for user and role management etc.
Drupal use is exploding globally and there's a serious skills shortage, so you'd be even more employable :)
First, it's not compulsory that you use a REST web service. It's just that WS si more or less standard for web-based applications.
I'm not really familiar with PHP, but in python you have django-piston. On the IOS side you have restkit to pair the server with.
What I could say from my experience is that writing a prototype in django is quite easy and you can definitely use this to develop your app.
I was wondering this for quite a while and haven't really found an answer for this yet.
Why would you use Backbone.js exaclty inside a Rails application? Is it to extend functionality, have a more MVC pattern for your JS, build better API's...?
At the moment I can't see a reason why you would want to use it for something, because I don't think I understand the concept of Backbone.js
The big advantage of rails is that you have one platform and one language that you use that will handle the server-code and can generate the client-code (using the views).
Undoubtedly this theoretical advantage quickly starts slipping once you want to improve your user-experience with javascript and jquery. So actually you still have to learn two languages.
But still: all your models, business-rules, ... is handled on the server-side in Ruby. This also means that the server always has to be reachable.
What a javacript/client MVC (like Backbone.js, Sproutcore, ...) can offer you is a more native application feel. A single web-page application, like e.g. Gmail.
Depending on your requirements there are some very valid use-cases for such a platform. E.g. in places or devices with low connectivity it could be very useful (with HTML5) to have a web-application that does not need to be "online" all the time. It could save data and edits to the local storage and sync back to the server/database when the device is back online.
But, there is a big disadvantage when developing client MVC applications in combination with Rails: you will have to do some double development (it is the same when you are using flex/silverlight). Your models will need to be defined both on the server and on the client. I can imagine that some improvements could be made, like on the client MVC you are actually using presenter-classes, which on the server-side could be stored in different models/tables. But still there will be duplication of logic, models, ...
So that's why I think that for most applications, at the moment, it is not wise to switch to some client MVC framework. It will be a lot more work.
But when you do need the look and feel of a real native application, or a one-page-web application, then a javascript client MVC framework is the way to go. And if you do need a client MVC framework, I would propose Sproutcore.
To simply ajaxify your current rails application (reduces load-time of every single page), take a look at pjax-rails.
(better late than never - hope this is useful to someone)
The description on backbonejs's website seems like a lot of words thrown together without much meaning. There is a big hype around it but what's all the fuss about?
The premise behind backbone is that modern day, single page web apps (think gmail) quickly become a very complex interaction between syncing dom elements, UI events and the backend. You could easily find yourself storing data within the dom elements, and then having to somehow extract the data again to update the database. If you don't structure your code very carefully, you'll quickly end up with spaghetti code full of complex bindings, or code without backbone.
Using backbone's models, collections and views gives you a well thought out structure to work within, allowing you to build large apps without being overwhelmed by their complexity. What's more, it ties in beautifully with a restful backend.
Any thoughts on using Flex to build an RIA for administering a complex rails app?
We are starting to find it difficult using ajax to keep our admin section intuitive and easy for users to work with.
You've got RoR guys working on this program and you've managed to develop a complex rails app that has enough subtleties that the admin section is difficult to use.
The answer to this problem is not to use a different programming language to create a whole nother kinda app to do the admin.
It will help more to get assistance in simplifying and organizing your admin section. Work through some paper sketches to get a better idea of how to present this complexity and maybe reveal complexity as you go along.
Complexity is handled often by using wizards or revealing suboptions as you go along. Spend some time with your users and watch them do their tasks.
With more details I could edit this answer with more specifics.
Try investigating this book:
Flex is certainly worth considering in your scenario. Generally, Flex is more mature development platform than AJAX is so if your server-side data are exposed via some reasonable interface (web services, REST-full services etc.), building a Flex front-end would make sense.
It really depends on your needs - Flex vs. AJAX is an interesting topic on its own.
If you want to use XML for communication then there isn't much you need to do on the rails side. But if you want to use an AMF gateway you will want to checkout RubyAMF.
But I agree with MattK if you just want to redesign your admin section it's not worth adding in Flex. I think you just need to do some usability testing, take that feedback and refractor your interface.
I would only consider using Flex in your situation if you already have Flex developers or if you could outsource that part of your project. The Flex modules simply call web services (written in Ruby or whatever) so there is a very nice separation between the two parts of your project. Since the interface between the two parts is an easily-mockable web service, outsourcing works well. There should be plenty of web shops local to you who could handle the work. An admin site should take only two to three weeks to develop in Flex if the developers are knowledgeable.