Ok guys i was thinking about this question and didnt find anything related or that could clarify my mind about this. Its not an issue that im facing right now, its more curiosity and maybe it could help someone someday.
Whats the best way or best practice to create a reactjs application? Integrated with rails? Or with a separated rails api and separated reactjs?
I would say separate them. If you ever wanted to rebuild your API with Node.js or Python for example, it will make it much easier than trying to rip out all of your Rails code, and Vice Versa– If you wanted to keep your Rails API and build out a new front-end with Angular it makes it easier.
Another thing to keep in mind is scalability. When your front-end code is separate from your back-end code, you can scale up your backend independently, which would ultimately save you money. This is more applicable to large scale applications though.
Also deployment. If you need to make updates to your API, you shouldn't have to re-deploy all of your front end code as well.
Related
I have been learning rails for over 4-5 months.I would say i am intermediate(ish) on rails.Past week, i got interested in angular2.Since it is written in TypeScript, it was little diffrent for me.Can rails do what angular2 can do? I mean single page app things? Should i invest the time to learn it, or just move along with rails? And if i leave angular2, can i still make single page rails apps?
I know this might not be the place for this question, but i haven't got an answer from quora for past 4 days.This question really bothering me mentally and psyhically. It is bothering my mind, and preventing me to learn anything at all.Please help.
Angular is a client side app only.
Rails is a server side app.
Rails would be the more complete package as it can accomplish everything Angular can in it's own way.
There's no definitive answer for this but it really just comes down to what your project's requirements are.
Angular is great for font-end single page client side apps.
Rails is great for server side, database ORM etc.
With that being said there's nothing stopping you from using both in one app. It's a little too broad to cover here.
I've been using Ruby on Rails since a little more than one year now and I've always do it in a casual way, I mean, everything in one place (front & back), using the standard .html.erb file populated by the associated controller method.
Otherwise, today in our project, I have the need to separate the front and the back end for multiples reasons (code maintainability / clarity, better architecture, more reactivity, etc...).
I've done plenty of researches, watch some conferences (1, 2, 3), but didn't find my solution yet. It looks like to be a question that comes often, but what is the best practice/tools to separate the backend and the frontend of a Ruby on Rails app?
I don't feel we need (yet) a huge JS framework like React/EmberJS/Angular/etc...
First I was thinking about something like Middleman/Jekyll and make the communication via JSON and API calls, but it seems like that it's not a good solution for dynamic website.
So is there a frontend framework that works well with a Rails API and which is easily maintainable and upgradable (add feature/extension to it like gems)?
Thanks for your insights.
A friend of mine wrote this great article/tutorial on Rails as a backend API.
http://blog.launchacademy.com/the-basics-of-building-an-api-in-ruby-on-rails/
As well as this tutorial on Rails/Ember.js
https://github.com/diegodesouza/Project-Planner-EmberJS
You can get an idea of how it's done and implement your preferred front end framework.
Hope it sheds some light on this question.
I have a similar setup as one of the commenters on the question.
I'm using Rails mainly for just the project structure, to define some page layouts, and for ActiveRecord.
I then have my JSON APIs defined using the Grape API framework.
I have a SPA, written on AngularJS that lives in the public/ folder. It doubles as my mobile app, made possible by phonegap. If my Angular app didn't double as my mobile app, I could've possibly just used the asset pipeline to serve up the SPA. To compensate for that, I have a separate build task written in Grunt to minify/uglify my JS/CSS assets before I deploy them out to production.
I also use Comfortable Mexican Sofa for my static content pages.
It took some trial and error to get things right, but overall I find that this setup serves me pretty well.
I need to build a web service, for a mobile game, to manage the states of multiplayer games. I need a database and an RESTful API to access it. I'm very familiar with Ruby On Rails and was thinking of using that since I can throw together the DB and API pretty quickly. However, since RoR is a framework for building web pages and I'm not actually building any web pages, it naturally seems like the wrong technology to use even though it would work. As such, I'm considering using Ruby on Sinatra, but I've never used it before and I'll have to kill some time learning it. For you Ruby gurus, is there an advantage to using Sinatra or a disadvantage to using RoR for what I'm trying to accomplish?
Thanks so much in advance for your wisdom!
You know Rails, you don't know Sinatra. Personally I prefer the latter for things like building APIs, but there's nothing stopping you from doing it in Rails, and there's nothing intrinsically wrong with it either. Unless you want to see this as a learning opportunity for getting into Sinatra, I'd say stick with Rails. Here's some links that might be useful btw:
Building APIs With Rails
Building a Platform API on Rails
It probably depends on your API. If you need more than just a bunch of routes then you will have to come up with your own solutions (authentication, ...).
If all you need is some RESTfulness without the added weight, Sinatra is great. All you need to know is what happens in what route and you're fine. See the Sinatra Readme which has all the information to get started.
I'm going to be collaborating with a Python developer on a web
application. I'm going to be building a part of it in Ruby and he is
going to build another part of it using Django. I don't know much about
Django.
My plan for integrating the two parts is to simply map a certain URL
path prefix (say, any request that begins with /services) to the Python
code, while leaving Rails to process other requests.
The Python and Ruby parts of the app will share and make updates to the
same MySQL datastore.
My questions:
What do people think generally of this sort of integration strategy?
Is there a better alternative (short of writing it all in one language)?
What's the best way to share sensitive session data (i.e. a logged in
user's id) across the two parts of the app?
As I see it you can't use Django's auth, you can't use Django's ORM, you can't use Django's admin, you can't use Django's sessions - all you are left with is URL mapping to views and the template system. I'd not use Django, but a simpler Python framework. Time your Python programmer expanded his world...
One possible way that should be pretty clean is to decide which one of the apps is the "main" one and have the other one communicate with it over a well-defined API, rather than directly interacting with the underlying database.
If you're doing it right, you're already building your Rails application with a RESTful API. The Django app could act as a REST client to it.
I'm sure it could work the other way around too (with the rest-client gem, for instance).
That way, things like validations and other core business logic are enforced in one place, rather than two.
A project, product, whatever you call it, needs a leader.
This is the first proof that you don't have one. Someone should decide either you're doing ruby or python. I prefer ruby myself, but I understand those who prefer python.
I think starting a product asking yourself those kind of questions is a BAD start.
If your colleague only knows prototype, and you only know JQuery, are you going to mix the technologies too? Same for DB? And for testing frameworks?
This is a never ending arguing subject. One should decide, IMHO, if you want so;ething good to happen. I work with a lot of teams, as a consultant, Agile teams, very mature teams for some of them, and that's the kind of stuff they avoid at all cost.
Except if one of you is going to work on some specific part of the project, which REALLY needs one or other of the technologies, but still think the other one is best for the rest of the application.
I think, for example, at a batch computing. You have ALL your web app in ror or django, and you have a script, called by CRON or whatever, computing huge amounts of data outside the web app, filling a DB or whatever.
My2Cts.
I have an existing project written in Ruby on Rails. It is sort of backend solution for the upcoming major addition to the project. What I mean is it currently serves for the admins and it already has loads of features and actual Rails files in there.
Now I am planning to add the new "Public" facing part of the App in Rails and I am wondering what could be the best solutions. I could think of the two following possible ones but I would really appreciate if anyone who had experienced this could put me in the right direction.
Create a new Public facing Web App using the same resources the backend Web App was using - any pros and cons?
Simply add the new features to the existing backend Web App - any pros and cons? (I am sure this option will make the App files grow quite large, but should I care? or not?
I have only done small Web Apps in Rails before and this is my first large one. Please, anyone, your answers will be much appreciated.
Thanks.
You already have a lot of business logic in the models, so starting a new application would mean duplicating that logic, which is a maintenance nightmare.
I would simply add the public facing parts on to your existing project. I wouldn't worry about the application getting big. I've worked on a very large rails application and it works fine. (177 tables/models, 23+ controllers, etc...)
Just make sure you create a good way to separate the internal parts from the external ones, by adding a field to the User model to indicate if they are internal or external, and then as part of the authentication, limiting access to the internal parts.