In the process of building a SPA, we opted for a combination of Rails API and Ember-cli.
From what we understand, the architecture of the app will be the following:
Rails API will run the back-end of the app, as an API
Ember-cli will run the front-end of the app, as a front-end MV* framework
Data will be served by Rails API to Ember-cli with JSON
What does not seem really clear though, is what should be the development workflow?
In other words, should we:
Build the back-end (rails models, etc), then build the front-end and finally connect both?
Build everything at the same time, but one feature at a time?
Go with another option?
I would recommend building both at the same time, in separate apps (that way you can test your API as an actual API rather than just a backend), but in close proximity to one another. This way you can make sure both play nicely with each other and you're getting the results you actually need, plus if something that you do on one causes an error on the other the bug will become immediately apparent.
Let me know if this answers your question enough, I can clarify/ give additional examples from here if you'd like.
Related
Iam a novice in rails and trying to write my first React frontend. I have read enough to know that there are different methods to use React with rails. I decided to split frontend and backend, and use rails in API mode. I cannot find good sources explaining what I need on my server to get rails and react going, and why. I read so far about npm, node.js, Heroku and so on, but i lack the knowledge to decide what to pick and i dont understand the interactions yet.
Does someone know a good tutorial, some sources or keywords to point me to a direction?
If you want to use Rails just in API mode with React on frontend then you can separate those apps completely.
I.e. use Rails/Puma server for API and have a separate server (Nginx/Apache/Node.js) to serve the frontend React app and other static assets.
For using react as your client-side application and rails for the server-side you need two different applications. As Rails is MVC I suggest you use just ruby and Sinatra server.
In this situation be careful about the cross-origin errors you have to enable it while using two agents.
Take a look at this.
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.
We have a Rails app that acts HTTP API only. On the client side, Ember.js is currently used. We are not overly impressed by Ember and really like the approach Meteor.js takes. So we'd like to exchange the client side with Meteor.js and communicate with the Rails server via websockets that speak the Data Distribution Protocol (DDP), so we can keep using the models, mailers and controllers in Rails. Implementing server side of DDP should be easy.
However, we're unsure how to make Rails talk websockets. We found Reel, which seems to make it easy to accept websocket requests in a standalone environment. Reel seems great as we'd like to implement the DDP on top of the Celluloid stack anyway. But what about running Reel in the Rails environment? Would we need "rails runner" for that? And we'd like to keep using the existing controllers to dispatch incoming requests (like, to add/change/remove resources). Is that even possible without having the request coming through Rack?
Any input is appreciated.
It's a bit late, but I've implemented DDP in Ruby, you can check it out here:
https://github.com/d-snp/ruby-ddp-server
It includes an implementation of EJSON as well. It's built on top of celluloid-websocket, and can be ran simply as a rack app.
I've made an integration with RethinkDB that can be used as a reference to build your own collections implementation.
https://github.com/d-snp/ruby-ddp-server-rethinkdb
I've also made a sample chat application that can be found here:
https://github.com/d-snp/celluloid-rethinkdb-chat
It's something that I have been longing to do as well, to integrate old "legacy" Rails code. Here is the best way I have found:
Since you would not be using any of Rails router/controller/views, but just the ability to read data and push it to the client, I recommend you use Rails to create JSON apis to the database, and deploy the code, then in Meteor you can consume the data via the http package, this would happen on the server at a regular interval and populate the MongoDB with the normalized data you need, then it would serve the browser client.
I am working on such an application that will keep a normalized version of the data in Mongo, and a relational version of the data in mySql (through Rails) this way I can preserve the legacy Rails functionality that I dont want to rewrite in JS, and get the benefit of Meteor for the one page that I need it most.
I have built two rails apps that need to communicate and send files between each other. For example one rails app would send a request to view a table in the other apps' database. The other app would then render json of that table and send it back. I would also like one app to send a text file stored in its public directory to the other app's public directory.
I have never done anything like this so I don't even know where to begin. Any help would be appreciated. Thanks!
You requirement is common for almost all the web apps irrespective of rails, Communicating with each other is required by most modern web apps. But there is a small understanding that you need to get hold on,
Web sites should not directly access each others internal data (such as tables), (even if they are build by the same language (in this case Rails) by the same developer),
That is where the web-services comes in to play, So you should expose your data through web services so that not only rails application can consume that, but also any app that knows how to consume a web service will get benefit.
Coming back to your question with Rails, rails supports REST web services out of the box, So do some googling about web services, REST web services with rails
HTH
As a starting point, look at ActiveResource.
Railscast
docs
Message queuing systems such as RabbitMQ may be used to communicate things internally between different apps such as a "mailer" app and a main "hub" application.
Alternatively, you can use a shared connection to something like redis stick things onto a "queue" in one app and read them for processing from the other.
In recent Rails versions, it is rather easy to develop API only applications. In the Rails core master, there was even a special application type for these apps briefly (until it got yanked again). But it is still available as a plugin and probably one day becomes actually part of Rails core again. See http://blog.wyeworks.com/2012/4/20/rails-for-api-applications-rails-api-released for more information.
To actually develop and maintain the API of the backend service and make sure both backend and frontend have the same understanding of the resources, you can use ROAR which is great way to build great APIs.
Generally, you should fully define your backend application with an API. Trying to be clever and to skip some of the design steps will only bring you headaches in the long run...
Check out Morpheus. It lets you create RESTful services and use familiar ActiveRecord syntax in the client.
I have a Rails application that right now is pretty standard: Heroku/PostgreSQL backend, users go directly to my site to update data, there's no mobile app or anything. We're going to start licensing out the tech to other companies, so that different versions of the interface live on company1.mywebsite.com, company2.mywebsite.com, etc, where all of these interfaces share the same database.
I want some advice on how to go about building this. Do I create a separate Rails app for company1, company2, etc (with a lot of redundant code) and then set up each of them with API keys to query my master app, using its RESTful routes?
Any tutorials to point me to would be great as well.
I recommend you the book Service Oriented Design with Ruby and Rails, by Paul Dix. It has a lot of info about the kind of system that you want to build.
To answer your question:
Build an API server. It serves a JSON – for example – RESTful interface.
api.mydomain/client1/users.json
Build a frontend server. It consume the API service – using typhoeus for example – and serves the final pages. It uses a subdomain or domain name for identification of different clients.
client1.mydomain/users
We have a similar "platform".
What we did:
build a master API app (REST + Push)
build a core plugin for rails which has all the shared code
build a separate rails app for each client which has all the client specific code
We are using this setup for 3 years now and I'm pretty happy with it.