I am about to develop my first mobile app with the same function of a website I have developed in rails. So I have a few questions:
My plan is to create an API to the website and build the app using that API to my website. In your experience is that a good solution?
Whats the best option, use a cross-platform framework like http://rhomobile.com/ ? something like rubymotion for iOS and try to find another framework for android? or actually just do it on the given SDK?
Should I not even worry about developing a website and go straight ahead with the app leaving the API idea behind?
I am about to develop my first mobile app with the same function of a
website I have developed in rails. So I have a few questions:
1. My plan is to create an API to the website and build the app using that
API to my website. In your experience is that a good solution?
Yes, but you should not need a separate API, you can use the same
routes but with .json to return a json value for the app.
2. Whats the best option, use a cross-platform framework like
http://rhomobile.com/ ? something like rubymotion for iOS and try to find
another framework for android? or actually just do it on the given SDK?
Don't know about cross platform support, I have only done android, using the SDK
3. Should I not even worry about developing a website and go straight ahead
with the app leaving the API idea behind?
I thought you said you already have developed the website so I don't
understand the question.
4. Any other suggestions?
There is an alternative that may be a quick route to getting something
working, which is to embed the website in an app. It will not give as
good a user experience as an fully fledged app of course.
> Hey guys,
>
> I am about to develop my first mobile app with the same function of a
> website I have developed in rails. So I have a few questions:
>
> 1. My plan is to create an API to the website and build the app using
that
> API to my website. In your experience is that a good solution?
Yes, but you should not need a separate API, you can use the same
routes but with .json to return a json value for the app.
Yea thats true and makes totally sense. Thanks
>
> 2. Whats the best option, use a cross-platform framework like
> http://rhomobile.com/ ? something like rubymotion for iOS and try to
find
> another framework for android? or actually just do it on the given SDK?
Don't know about cross platform support, I have only done android, using
the SDK
>
> 3. Should I not even worry about developing a website and go straight
ahead
> with the app leaving the API idea behind?
I thought you said you already have developed the website so I don't
understand the question.
Well It's more like a question for the future. If I need a app to start
with, is it a good practice to still do the website and use the common API
or to just develop the app?
We have had good success with PhoneGap (also known as Cordova). However, you will need to write a client app that is written in a framework like Backbone, Angular, Ember. I don’t know much about RHOMobile but maybe it is a competitor to PhoneGap/Cordova?
As far as back-end, I actually do recommend you create a versioned API that operates at distinct route from your main web-based app. There are good reasons to do this – specifically, a versioned API will operate at a url like /api/v1/. This will mean that in the future if you want to change the output of the API, you can do so by creating a new API version number (/api/v2) and still have your old mobile clients use the old API (which you generally leave-in-place to support older clients rather than replace)
Another good reason to create a versioned API instead of using existing Rails endpoints is that it actually forces you to move your domain logic out of your controllers. You controllers-- both your Rails controller and the API controllers – should be really, really lean and never contain any domain logic (business logic). If you have a lot of IF statements in your controllers, you probably have too much domain logic in the controllers. Writing more controllers, although it does have an added cost of more controllers to maintain, actually can help you abstract the domain logic into context objects or model objects where they belong. This is because if you have two controllers with repeated code in them it becomes very obvious that that repeated code is domain logic and should be encapsulated into either a model, service object, or DCI object. Doing it this way is a little more work but in the long run you end up with better product.
Also, ActiveModel serializers (https://github.com/rails-api/active_model_serializers) have come a long way in the last year or so, and now do some really fancy stuff like root element control, arrays, embedded associations, and side-loading data. If you aren’t familiar with what these are, learn them before getting started as they will affect the architecture of your API.
You will almost always find that as your mobile app and web app grow you will require changes to the API. This is why a versioned API enable you to not worry about crippling old mobile clients and move new clients onto the new versioned endpoints.
It may be temping to just to “re-use” the existing Rails controllers – and may in fact be the way to go if your app is small – but in a large app this gets very messy very quickly.
Also if you are “re-using” the existing Rails controller because those controllers contain domain logic, then you should refactor your domain logic out of the controllers and into domain objects. Building more controllers actually encourages you to do this, which in the end creates a cleaner architecture (although I would caveat that it may be more work up-front).
Thanks for your input. I have done API's before in rails and I understand
and follow the advices on using a versioned API. I think what Collin was
trying to say is in the beginning to get the app development going I should
be using the common API, and after build a version API.
I also agree on using the domain/model objects and more controllers as that
helps to modularize code.
My biggest doubts maintain on which technologies should I use to build my
app on. I will have a look at Cordova, thanks Jason for the input
In retrospect I think it is probably best to use a versioned api from
the beginning in the app, but initially you can just route this
through to existing actions in the rails app in order to get things
started, if that is appropriate (by adding the versioned routes to
routes.rb).
