I have an application that has some model and services. I need those entities from another app from another directory. How can I share them? I don't want to use public API or REST interface via the internet, but just call services in local. Can I configure it with Rack?
If you want to share the code then the rails way is to make they as gems and use them in your applications.
If you are using rails > 3 , best way is to do it via rails engines, Its easy to learn and more elegant.
But simplest and not recommended way is to have your methods as ruby modules/classes and use then in your each project (by having them in you lib directory or some were)
HTH
Related
I'm about to start a new project and I am unsure if using AngularJS for my front end would be a good idea not. I've read about people saying this isn't the smartest way of doing a project. And even if I did, Is there a way to get AngularJS to interact with the controllers? This question may be redundant but I am actually curious of how to effectively do this without it being a waste of time.
I've never completely done it, but I believe the way to go is to build a Rails api and then have a separate Angular project use said api. The api could also be used to build a mobile app. I think the Angular project would still need to be served from a Node.js server in production, but I don't think that would be a big deal.
This is what I used to learn how to build a Rails api: http://apionrails.icalialabs.com/book/chapter_one
You can do it within an existing project and share the models from it.
There are several different approaches to accomplish that. I tried about 5 different guides out there, the best I found (and I finally sticked to) was https://thinkster.io/angular-rails - This guide should help you build a basic CRUD app with angular connected to rails.
You use Rails as an JSON RESTful API which responds to Ajax-Requests (Get, Post, Put, Delete). Angular will handle the frontend stuff - sending those Ajax requests to the routes/methods defined in your rails controllers. So yes, of course your AngularJS app can interact with your rails controllers.
This also helped me to understand the setup in the beginning: Instead of the Rails View, you will be using AngularJS as your view:
I really love using angular with rails, because setting up the JSON responses (especially with Active Model Serializer Gem) is very easy and quickly done. i deffinitely can recommend it, and I have not encountered any unsolvable problems - so far.
Just go trough this guide I linked and you will see if this setup fits your needs.
The short answer is that your Rails application will have to present some kind of a public API for your AngularJS application to consume. Angular (and it's brethren, like React and Ember) runs client-side, on the browser, and it needs "something" to make AJAX calls against. That "something", i.e. your backend, can be Firebase, Parse, AWS Lambdas, Rails API, etc. Since you already have a Rails application, it probably makes the most sense to add some RESTful API endpoints that use the existing models (and possibly controllers) to consume/produce JSON payloads from/for the client.
Hypothetical question (at the moment!)
Suppose I have a great idea for an application. It acts on data which can be well-represented by tables in a relational database, using interlinked objects which represent those tables. It supports a well-defined API for interacting with (Creating, Reading, Updating, Deleting) those objects, and viewing information about them.
In short, it's a perfect fit for Rails... except it doesn't want to be a web-app. Perhaps it wants a Command Line interface; or an OS-native dialog-based interface; or perhaps it wants to present itself as a resource to other apps. Whatever - it just isn't designed to present itself over HTTP.
These questions suggest it's certainly possible, but both approach the problem from the point of view of adapting an existing web-app to have an additional, non-web, interface.
I'm interested in knowing what the best way to create such an app would be. Would you be best to rails new non_web_app, in order to get the skeleton built "for free", then write some "normal" Ruby code that requires config/environment - but then you have a lot of web-centric cruft that you don't need? Or would it be better to roll up your sleeves and build it from whole cloth, taking just the libraries you need and manually writing any required configuration?
If the latter, what exactly is needed to make a Rails app, but without the web bits?
If you want to access the Rails ORM to develop a CRUD non-web application, just include ActiveRecord in your own Ruby script; you will avoid using a lot of Rails modules you probably don't need (routing, template generator, ...) Here is an example of how to do it.
If you prefer to have the full Rails stack, do not run your Rails web app in an application server (WEBrick, Passenger, Mongrel, ...) to avoid any HTTP exposure, and interact with your application using tasks or the rails console.
I would avoid taking Rails too far off the rails. If I were doing this and felt that the gains of rails w/o the web stuff I'd do the following:
rails new non_web_app
and ignore the webbish cruft and use rails to generate models. In this way you get the tight, comfortable database behavior and can tie various gems in as you want to augment those models. I'd not bother implementing views, of course, and I'd consider implementing controllers in which the various render bits are removed and to use you instantiate an instance of the controller and call the action directly. This means the controller represents your API into your business logic still but the "views" it now "renders" are simply the return of the data output.
Then you could simply strip out the bits you do not need...the public directory, the view structure under app, config/routes.rb, etc. You'll need to test those changes incrementally and make sure that removing some now extraneous bit doesn't throw the Rails world into chaos.
Rails is for Web apps. That means HTTP. Now, you could package a Web app so that it runs on the desktop instead, or you could use ActiveRecord with a desktop application framework like Monkeybars.
I am developing a Rails application which will need frequent access to public APIs, and I am not sure what is best way to put external API (SOAP/WSDL) code in Rails application, what about model thingy, how we can manage that? Any ideas, comments?
The current contenders for "best" library for consuming External SOAP services seems to be either Savon or Handsoap. There is a comparison between the two here
I can't comment on handsoap as I haven't used it by I am happy with Savon which is working well for me.
In terms of Application structure then I would create a folder under lib for the interface named after the external entity and then store files under there using the namespacing features of rails.
So an example I have an external interface to a system called Sentinel. So I have RAILS_ROOT/lib/sentinel and then all classes within that folder are declared within a Sentinel module.
The first thing to do would be to see if there are any gems for the API's you want to interface with. Write a small wrapper class for the gem or just include it and use it where needed.
If you're looking to talk to a REST service, I would suggest the rest-client gem. If you want to do something completely custom you could make use of Jon Nunemaker's HTTParty. Nokogiri, an XML parser gem is useful for consuming XML-based services as well.
I have a couple of pre-existing applications which I need to run in "one" app. One is the application I want to use for authentication etc, whilst the other is another app that contains all of the business logic.
Both apps have pre-existing authentication, and both have fairly complex user models.
Is it possible to easily combine these so that if I log into one application and create a user, that same data is available in the other - or something similar?
What is the easiest way of doing this? Can a rails model extend a REST webservice?
You can use the new(ish) Engine feature to embed one app inside another. Your engine lives inside vendor/plugins, can have all of it's own routes and config setup just like a normal rails application but actually share the database. Makes combining applications really easy. We use it with git submodules to make management of complex applications seamless.
I'd use warden (or devise, which is built on it) for the authentication. Warden is rack-based, and can therefore be used in both apps aka single-sign-on.
In situation, when I need a webservice client, which will be used by some action controllers, how should it be implemented? As it will have some constant values (addres, parameters names) and session key, refreshed every 30 minutes, I guess model stored in database isn't the best solution. What is the best practice?
Built the web service consumer as a library and place it in your /lib directory.
I would also recommend HTTParty for very simple consumption of web services. You could easily build a library to handle the task, a simple class with a few methods and toss it in your /lib directory and be on your way.
Good luck!
Rails 1.x used to have "actionwebservices" builtin but it has been removed from Rails 2.x. The last time I did this was to build an SSO server implemented as classes using XML-RPC. The code is not public unfortunately (done internally for my employer) but was under 1k LOC incl. comments... Plain Ruby.
Now, I'd probably use a lightweight framework like Sinatra or an equivalent.