I was recently building an internal business database web app using Ruby on Rails 4 and Postgres. The plan was to make the app available to all our employees using Devise for authentication and hosting on Heroku.
Toward the end of development, a request was made to include some highly sensitive information in the app including social security numbers, etc. Thus, instead of heavily worrying about online security we are planning to make this app only run locally on one Mac and not have it available online. The app will only be used about 5 times a month by one person. Instead of requiring that person to launch a postgres server and a webserver via terminal (such as "rails server"), is there a way to package the entire Rails web app and database in to an application so it could be run similar to other OSX apps?
If anyone knows a PC solution instead, that is also a (less preferred) option.
At this point, we realize we should have developed a xcode app, but now that the development is mostly complete with some tricky UI, we would rather not have to recreate the functionality in xcode.
Though I haven't used it myself, what your describing sounds pretty close to what Rubymotion offers
Related
I've inherited a Rails 3.2 production environment which is 'humming' away nicely.
The client now wants another major piece of work doing but I want to do it in Rails 5. The web address would be the same for both the old site and the new project. The new project would be additional functionality which would be accessed via the old site.
Any one know of a way of keeping the old site running whilst I develop and deliver the new work via Rails 5? Eventually if this all works then I get the opportunity to migrate the old site to Rails 5. However for the moment I need to serve up both Rails 3.2 and Rails 5 from the same site.
It's possible to do what you describe with a reverse proxy, e.g. nginx, configured to serve from different web servers based on different paths on the same host. This answer has some details on how to do that. We would need to know how your website is hosted in order to give more details on exactly how to do that.
However, there are other concerns that come up when you start separating your apps which you may not have considered. For example, if your website allows users to log in, do you want them to still be logged in when they visit the new site? To do so transparently will require sharing the session cookie, which this post describes a bit (you'll need to use the same secret key for both apps, or use a remote session store like Memcached). I'm not sure if it'll work properly when shared between Rails 3.2 and 5, though.
As a final note, breaking up your monolithic app into a distributed system is never a decision to take lightly. It would likely end up being less work, and less overall architectural overhead, to simply invest the time in upgrading from 3.2 -> 4.0 -> 4.2 -> 5.0.
Personally I wouldn't touch that old app and its server, especially if the client is happy. Deploying the new app to a new server or a container service like heroku is something you should consider.
I feel like my question is partially answered through a number of other questions, but I just can't piece everything together for my case.
Basically, I'd like to build a fairly simple web app, but also be able to fairly easily build a mobile app for it down the line. From my research, the best practice would be to build a RESTful JSON API, and then use that API both for my web app and for my mobile app.
I've already gone ahead and developed authentication for my JSON API (using : http://lucatironi.net/tutorial/2015/08/23/rails_api_authentication_warden/) and I've got it up on Heroku. Now for my web app, I'm using HTTParty to consume that API, and I'm getting the JSON back all fine and dandy. However, I'm not quite so sure what to do with the database. My first thought was that maybe I need to access the API's database via it's own API calls, but that seems incredibly complex (just the thought of having to make functions for User.find_by_<every attribute> makes me scared). The other thought would be to have my web app use the API app's database. However, I can't find any info on how to do that if the app is on Heroku.
So basically, I'm wondering what the best way to go about this would be. Surely there is a standard out there that every big or small web app with an API uses. I'm really surprised that something so prevalent these days is hard to find good answers for. Or am I going about this all wrong? Any pointers would be greatly appreciated.
Databases are add-ons in Heroku parlance.
Use heroku addons to get a list of the add-ons for your apps.
$ heroku addons -a appname
Add-on Plan Price
──────────────────────────────────────── ───────── ─────
heroku-postgresql (relaxing-purely-8366) hobby-dev free
└─ as DATABASE
First you may want to remove the database attached to your front-end app:
heroku addons:destroy fat-samurai-1234
Then find the name of the database add-on attached to your API app and attach the add-on to your frontend app.
heroku addons:attach shining-sushi-1234 -a sushi.
https://devcenter.heroku.com/articles/managing-add-ons#creating-an-add-on
As to which approach is legitimate that's a matter of discussion. Many apps today use a single page architecture where the entire app is created on the front end - in javascript. So your app just consumes your REST api. Popular frameworks for this are Ember.js, Bootstrap and Angular.
The other approach would be to to create a classic server side app - while it's possible to create an app that would consume the REST api there is a significant overhead involved so it will be more performant to connect directly to the database.
I am running a site right now with a quite big MySQL database.
Now, I want to create an app. I will need to use obviously a database de to the fact my data are already there.
Thus,
1) Should I keep using the MySQL server and my iOS app will connect to this MySQL serve for getting data?
2) is there any problem if I use the MySQL server ? Security issues maybe?
3) if I have to change the MySQL server, what database infrastructure I need to build and work with?
I am totally newbie on iOS apps. And now I planning to face any issues my iOS app will have.
Since you are running a site with MySQL I think a lot of your questions have been answered. You already have seen how your MySQL database performs in a production environment. Unless you believe that your iOS user base is going to be much larger or perform very different functions you currently have valid performance benchmarks.
In terms of how it relates to the iOS app, you can build an API, or make calls to https pages on your website that will return the information required for your app. For information on how to do this, check out this AFNetworking tutorial.
In the end, there might be some reasons that your current database isn't the right choice for your app. But since the app won't be interacting directly with the database, you can change it out later and you will only have to integrate the database with the interface and not change the iOS app at all.
this is probably strange question but I wanted to make rails app that would function as regular desktop app.
I'm making regular web app, but I will have admin function where I manage clients. I'm not very confident with security of my app and I will be only one who uses it so I thought maybe I can use this part of code only on my windows machine.
I figured it out because I don't have SSL certificate and I wouldn't want to put something on web if i will be only one who uses it.
I also know that Rails is webframework, but is is only framework i know how to work with.
I'm developing a tool that will comprise a central website and a desktop application. I've only really done entirely online developent, or entirely offline/client-side development before and not really had to link the two. I could use some help in how to approach passing data to/from the online site & desktop app.
The desktop app needs to communicate & do some control of iTunes, so initially I'm building this in Cocoa on OSX & making use of the ScriptingBridge framework.
On the website side I'm thinking of using Ruby on Rails, with data stored in a mySQL database, as I'm fairly familiar & seems like a good match for the online job it has to do. (But open to other suggestions if there's a better approach!)
I'm struggling to find the best approach to easily transfer data between the Cocoa app & the online rails database - is there a simple way of having the Cocoa app access the online database directly, or is it typical to dump some XML onto the webserver and have the app read that?
Opening a RESTful API on your RoR system is as simple as you can get. Have your desktop app communicate with that API using JSON or XML.
Advantages to using JSON rather than XML: (1) extremely simple to manipulate in Rails (2) extremely simple to work with in Javascript, should the need arise to build a web client in addition to the desktop one.
It's a very bad idea to have the desktop app communicate directly with your remote database. Two main reasons:
Security. Such a setup just begs to be hacked. Some databases are "built for the web" (CouchDB comes to mind) and would be alright here, but MySQL isn't.
Flexibility. With desktop application in the field, making changes and distributing them to all clients is hard. Should the need arise to change your schema, the web application layer frequently allows you to keep the interface with the desktop clients stable.