I am developing 2 apps for 2 separate clients, and a 3rd for myself. All 3 apps will have an address book, emailing, and user authentication. Finally, I want the apps to be created "modular" so that I can add (or remove) modules as they are needed.
I have watched the Mountable Engines Railscast and it looks like what I need, yet I am still unclear on the following:
How do you develop each engine module (user authentication, emailing, address book) separately without a common base application?
How do you develop the address book module when it requires user authentication, which is a separate module altogether?
I'm guessing that you develop the user authentication first, and include that in the dummy app of the engine module, but I'm getting confused with the namespacing of the engine.
It might be useful to note that I come from a C# background and I am new to web-development.
People have already written authentication and emailing plugins. For most apps, the only work left to be done for those modules is customization.
You might want to write a engine to share some of the customizations and to share some of the address book functionality. In in that case, you can consider developing an example app which has as little custom code as possible to clearly define the address book api.
Related
I'm goint to create a RESTfull service app is made of Rails5 with API mode.
I also need an admin app that provides web views for managing users and contents.
These two apps will share codes each other.
I know a way of creating the API mode app.
$ rails new apiapp --api
How do I create the other project?
The way I would implement this kind of functionality is like so:
RAIL API for your model, database, validation and relationships logic.
Client side MVC for Admin app with RESTful calls. For this I would use Backbone Marionette.
this is the cleanest, least code repetition implementation I can think of, which follows industry standards.
this is as per the software mantra 'consume your own dog food' - if you create an api, use its interface to do your stuff. this way you test and improve it as you go.
If you want RAILS only on both ends, you would be better off implementing your ADMIN and your API as one app, for least code repetition. Create an API controller name space for all your exterior calls, and code normal rails for your admin views and stuff. this way your database and model validation and relationship logic is shared, but controllers and route namespaces are not.
Toodles.
You build the other project as a normal rails project. The thing to understand about Rails 5 api mode is that you cannot have normal html stuff as part of it. The entire rendering pipeline (assets and such) is missing. Rails 5 api mode is fast because big parts of the environment are just plain gone.
What you want to do is have 2 projects:
admin
api
And figure out a way to share your model logic across them.
If you use devise for authentication this is particularly tricky since devise adds things into your user model that you cannot have in an api project. Here's how I got around it:
If Rails.application.class.parent_name == "admin"
# devise crap goes here
end
How exactly you easily share a directory of models across 2 git repos? I have no good answer. I have a rake task which sync's things manually by copying them from the canonical source to the destination but that's a hack.
So I am starting out on company project that will have several components:
At first...
Job list
Client profile creation and management
User administration and access (login, signup, roles, etc)
later...
Messaging
Schedule
Basic reporting
way later...
Deeper analysis and bi
I'm wondering if it makes sense for each bullet item to be its own rails project, self contained and modular (if that is indeed the case); or if it's just best for it to be in the same app. I could envision a situation where each module could operate so independently of each other that it wouldn't need the rest (except for the user funcionality) and another situation where all modules would be used together.
It seems like to me that many tasks can be handled with a lighter framework like Sinatra (and then situated physically under the rails app). It also seems like it would be a lot of overhead to have several rails apps running on a server. But I am not totally aware of all the pluses and minuses to operating each scenario.
I know this is kind of a general question that is bound to get a lot of "it depends" kind of responses (and rightfully so) I was looking for opinions/examples of how you setup this kind/your kind of project in rails. I am a quasi noob so be gentle.
Thanks in advance!
Generally speaking I would consider a website to be a suitable target for a Rails app. Each part of the app can have its own namespaces within the app, so the app has some structure internally, but they should all be one application. Consider things like sessions, where you want a user to login and use whatever features of the site you want. You want those sessions in one application without a user having to login to different sections.
Saying that, if there is complex or extended functionality that isn't part of the MVC architecture (say talking to an external API, data-mining etc), then you could offset that to a separate project and a include it as a Gem in your application. You would still have one main Rails application that includes those Gems.
You might also want to bundle together a section of your project into a reusable Rails engine that can be loaded into multiple projects. For example, Devise handles user login and management. It is a Rails engine, bundled as a Gem, that you include in your project.
Another example from Meducation (one of my sites). I'm in the process of extracting our email tracking system out into its own Rails engine as I feel its functionality sits alongside Meducation and is not a core part of it. I can then use it in other projects as well.
In your specific example, I think your requirements fit fine in one Rails application.
My team has been developing a bunch of modules in a monolithic Rails app for internal use. The modules are for example leave request, staff info, tasks/todo etc. Each module has its own purpose but somehow is linked to common information such as staff profile and user authentication. Each module has a developer assigned and they commit code to the same Rails app. Currently, it's super hard to maintain the code and scale. Now, I'm doing my research to decompose the app into small distributed apps and make them an ecosystem. Here are the concept I'm looking for:
There should be a master app that maintain the views of other client apps. Better yet, it acts as a platform for other client apps to plug in to it. Staff logs in to this master app to access client app.
Master app should render views of client app using AJAX or other ways (not decided).
Although, I want to decompose the apps, but each app should still be able to query resources/data such as staff profile from other client app in the ecosystem.
Actually, I have not decided about the interaction of each app. Thinking to us RESTful (not decided).
It should support development environment where each developer can develop each app independently. Hence, maintaining their own code in their own git repository. This is probably the main purpose of decomposing the app in the first place.
I'm reading Service-Oriented Design with Ruby on Rails book, but it seems like they focus on decomposing an app into small different services, whereas I want to have small different apps. Just wondering if there's any other ways to do.
Sorry for a long question and asking too much. Just want to know if you have been in the same situation and can guide me to some articles, communities, books so that I can continue more on my research.
Ah the joys of refactoring. It can be a tricky dance trying to structure an application into logical groups so that parts can be decoupled.
I would strongly suggest looking into Engines, with the Engines vs Mountable being very informative. This allows you to build a mini Rails app (aka an Engine) that can be packaged as gem. The custom Engine gems are bundled into a Rails app, providing a complete set of configurable functionality (models, controllers, views, etc).
The usefulness of Service-Oriented Architecture depends a lot on what kind of data you are pushing and pulling around. That being said, Rails is really wired for RESTful, so you get a lot of bang for the buck with that route.
I have to built a social networking site on Ruby on Rails. The features in the site may change from time to time; so we will need to add/remove features with ease. Moreover, we may be building another social networking site. Due to these reasons, we are thinking to build a basic framework for social networking sites in RoR with the feature to install or uninstall extensions to the framework.
I worked previously in Joomla! CMS and its architecture for adding/removing extensions is kind of what I am looking at. In a Joomla! installation there is usually an admin side from which you can add/remove/customize extensions.
I am new to RoR and finding it little difficult to decide how to do this. Any help will be appreciated.
UPDATE 2015: this was answered in 2009 a lot has changed
Plug-ins have been superseded by Gems and Engines
For all the information you need on Engines:
http://guides.rubyonrails.org/engines.html
Engines are a fantastic way of building encapsulated and reusable code for your rails apps.
Original Answer for Reference
On the development side Rails Engines and/or plugins is probably what you are looking for.
Rails Engines are small subsets of an
application that can be dropped into
any of your Rails applications and
handle common parts of the application
from scratch.
Say for example your social networking application has a wiki, blog, chatroom etc. You would more than likely want to create a wiki engine, blog engine and chatroom engine.
Engines allows you to re-use such functionality within different applications so you do not have to repeat yourself.
Take a look at: http://rails-engines.org/
Some support for ‘engine’ plugins has
been merged into the Rails core
codebase in Rails 2.3.
I would also recommend taking a look at some public projects say on github and see how people have used engines.
Take a look at some engines:
Wiki-Engine
Skinny-Blog-Engine
Other useful links for reading
Tips for writing Engines
Rails Engines, Railscast by Ryan Bates
The Russian Doll Pattern (PDF)
In functionality terms you could still have an admin area that could activate certain features ie. your blog or wiki by allowing users access to such areas with a permissions/roles system.
ACL9
role_requirement
restful-authentication
If you want to build a CMS which supports some kind of extensions like in Wordpress or Joomla then you will have to either build it and provide guidlines or at least look into how you would upload/install Engines/Plugins from a user perspective.
Not sure on the security implications of this
Redmine has put this kind of functionality into their awesome application. You may want to dig around the source code for tips and clues
Finally Adva_CMS has basically adopted this approach and have created a number of Engines for their CMS application
HTH
Engines are still a pretty solid way to go, the new location to get info on those is located here: http://guides.rubyonrails.org/engines.html
But what you need is really more application specific. A lot of applications develop these things organically over time. They start out by hand crafting a few of these and then they re-factor them periodically until they find patterns that align with software design patterns and then they develop a plugin framework.
Are you going to expose your interface to end users? To third party developers? What parts of the application are controlled by these plugins? Is it just the presentation tier? Does it affect the data model? Consider the fact that when you publish any kind of external interface, you're developing contracts that you need to honor.
You might check out these design patterns: http://en.wikipedia.org/wiki/Software_design_pattern. They will help you figure out how to manage your development process. If you're just working on plugins for internal use, then what's the real purpose of them? What makes them different than modules?
I have thi intranet I developped back then with PHP.
I handles multiple apps and tools (blog, link sharing, file sharing, events, clendar...), and a big user autenthication system for logging in and authorisation management.
I'd like to start re-building it with Rails.
I don't want to build one big app.
I'd like to build the site as multiple smaller apps, sharing a few common ressources like the user administration system, templates, layouts and navigation...
Rails Engine provide a way to embed an app into another.
I guess I could have a "main" app, embedding all other apps.
But I don't feel it's the right way (I may be wrong) if I have 10-15 different apps.
How would you do it ?
Thanks.
We've created applications that are split into 2 - the user facing site and an admin site. We just made 2 separate sites that have the same db and models and their own views and controllers.
This works pretty well and gives us the freedom to treat each site differently in terms of security and deployment.
I don't have any experience in going farther than that.
Check out ActiveResource - it is designed to allow you to use RESTful webservices as if they were ActiveRecord objects.
I'm working on a project now with a bunch of separate sub-apps that are pure web services (no UI). There's one "main" application that has all the UI and handles login/authentication, and then accesses the others via ActiveResource.
You can share the models between projects adding
config.autoload_paths << Dir["SHARED_MODEL_PATH/app/models/*"]
to your application.rb config file.
Or you can check the tutorials about ActiveResource such as:
http://andywaite.com/2010/12/22/activeresource-layered-rails-app
http://wholemeal.co.nz/blog/2010/03/08/active-resource-associations-and-nested-resources/
http://ofps.oreilly.com/titles/9780596521424/activeresource_id59243.html