For the first time I'm creating a quite complex Rails app.
I'd like to know what's the best way to organize that app by folders. Until now, I'd do everything under one app (all the models, controllers, etC) but reading some open source code I realize that they put everything under different apps.
Like for example Spree Commerce. They have a general folder and inside that they have different apps (API, core, admin, etc). How is that done and is that the best way to do it?
I'd like to get pointed to the best way to do it (a book, blog, anything) so I can understand how I can architect my app for future maintenance.
thank you
As an aside I think the title of your question is a little confusing. Rails, by using convention over configuration, defines 'how to organise a Rails app'. I think your question is rather about how to architect your application as opposed to anything Rails-specific. Maybe tweak the title?
That aside, without knowing any more detail about your project it's a tricky question to answer, but I'll give it a go.
All applications should start off simple, if you believe (like I do) that you should start by building the simplest thing that could possibly work. Given this, since you're using Rails, then in all likelihood the simplest thing would be to structure your app as a vanilla Rails 3 application. This will probably (I say 'probably' because I don't know any specifics about the app) allow you to get a beta version of your app up and running pretty quickly without worrying about complexities which at this stage in the development of your project are not a problem.
If you need to create an XML or JSON-based API then Rails makes this really easy using the standard framework, which will allow you to spend more time thinking about the API design than how to code it, and it's the API design which is the most important thing to get right in the first instance.
Similarly, your Admin site can be part of the same app just in a different namespace. If you find later down the line that you want it as a separate app, you can do this (maybe you could use the awesome API you designed to facilitate this), but why bother designing it with this added complexity (and hence extended development time) in the first place if you don't have a good reason for doing so?
Once you have your app up and running and people are starting to use it, you start to get a picture of where the bottlenecks are and where the design could be improved. At this stage, if there's a need, you can start to move parts of the app to scalable solutions, such as running your API as a standalone service, introducing caching, changing data stores and other improvements and optimisations.
Even if your app is as wildly successful (and I hope it is!) then re-architecting your application whist continuing to run the existing service is still entirely possible, as Twitter have proved. Just stick to Knuth's statement and you'll be alright.
Regarding reading material, that's a tricky one. For me a lot of the XP and agile development classics taught me a huge amount about how to approach program and app design. I'd also check this StackOverflow topic for book inspiration.
Good luck!
Spree uses Rails' Railties (Rails::Engines). Railties are introduced in Rails 3 to make it more modular and easy to extend. Rails 3 itself is a collection of Railties (ActiveSupport, ActiveModel, ActiveRecord, etc.).
If you are developing a complex app I would suggest spending some time planing its' architecture. Designing a complex app without any initial planning would definitely end with a maintenance nightmare down the road. It also introduces a huge learning curve for the new team members, slow down your new feature introduction and of course, frustration.
Anyway, don't over optimize, but don't forget to design your architecture for your needs.
IMHO, I will create very complex projects as one app. I have reason to believe that Spree and Radiant build under seperate apps so that under the pretense of their open source communities, contributors can contribute code easily without tampering with the core data, and the core workings of the application.
Otherwise, you should be alright just building it as one app. Just keep it neat.
Here is what have kept me sane for several years of RoR development:
I use Rails Engines, but keep them in same codebase as the main app. Here is good starter for modular Rails app:
https://github.com/shageman/the_next_big_thing
Wherever I can I try to reduce coupling and use composition to make things easily testable, reusable and maintainable. This helps to eventually extract module or engine as separate gem. Composition is done by routes (mounting), directory overlaying (assets), dependency injection or configuration.
If I don't need to re-use an engine I put it in the same code base as the main app which is single deployment unit. Thanks to that I don't need to switch between projects in my IDE. While in development environment any changes to the engine code are instantly picked up by Rails reload mechanism.
Related
soliciting advice about upgrading (or re-writing?) a legacy app. It's a single page webapp with lots of dynamically generated windows and forms, roughly comprised of
13,000 lines in .rb files
11,000 lines in .erb files
25,000 lines of javascript (not including large 3rd party libraries that bring this to nearer 60000 lines)
This acts as a UI for end users of our system, which also has a number of core business services (mostly written in Java, with a small amount of Node.js) and a fairly sizeable MySQL database (>200GB). Some of these services push AJAX to the client browser for real-time updates.
Reasons for upgrade
It's ruby 1.8.7, rails 2.3.15. Most of the core code dates from 2009. This makes it both insecure and hard to maintain (think "predates the existence of gemfiles".)
The app has been maintained by Java devs for most of its life, as most of the company's devs have been hired as Java devs to work on all the other services that perform business logic. It's probably safe to assume that this has lead to lots of hacks from people who didn't want to break anything, and certainly lots will not be done in a "rails way".
The javascript is also a bit of a mess. It's got a knot of frameworks (the original Angular is used sporadically; jquery and prototype are both fighting over the $ symbol in different places.) There are files that are 7000 lines long.
the css styling has been upgraded since 2009(!) but is starting to look a little tired. We'd like to implement a bootstrap theme that will look sharp without too much front-end skill, but right now the code that renders all of our pop-up windows, sidebars etc breaks badly if we try and add bootstrap.
It would be nice to modernise our push servers, replacing them with websockets.
Context
There are 3 of us on the dev team- this is my first job, and I've only been here since January. Of the other two, one has only been here about 4 months longer than me, and it's his first dev job too. The other guy is the only one who has ever spoken to someone who spoke to someone from the original team.
Oh, and of course we have little or no test coverage.
Options
When I was hired (as a Java developer), I was told that we were looking to replace the website with one based on Spring MVC. This effort is partially underway, having been attacked in drips and drabs over a couple of years. Because different devs who never met have attacked it as if it's their own brand new project, the same problems are solved in different ways in different places. They've tried some flashy techniques such as custom annotations that I find hard to follow, but as far as I can tell don't fully work. The most senior of us estimates it would take our team a year's dedicated full-time work to finish it (which is not a realistic business proposition, based on how many requests for new features we get from customers).
I'm inclined to upgrade the website rather than spin out a new one. This is partly because I can see the sense in that post. Another reason is that we're all employed as jack-of-all trade full stack developers (doubling as DBAs, sysadmins, etc...). We've got no particular expertise in UI design, and the UI for our present interface, although dated, is pretty user-friendly; it feels like a blank canvas would throw that structure out, and play to our weaknesses. Upgrading ruby/rails would also make any features we add during the upgrade much easier to add to the new site.
Apparently some experienced ruby devs who are friends with my boss have advised him informally it'd be so much work to bring the website up to date that it would be comparable to a complete re-write, which was the motivation for the spring project. This would have the advantage of only having to think about Java + javascript, and not trying to hire people who know both Java and ruby well.
Conventional wisdom seems to be upgrade rails in stages. I'm not sure how well this would work for us, for 2 reasons. For one thing, there 3 major versions for us to upgrade, which might have significant changes between them. More importantly, the code needs some TLC anyway with refactoring and the creation of a test suite.
I'm inclined to follow the following strategy:
Invest some developer time in training, to get a sense of the relevant best practises and the "rails ways" of doing things, rather than the "good enough to hack" knowledge most of us have now.
fire up a new rails 5.1 project on ruby 2.4.0
Configure active record to use our old database
Copy across the javascript from the public folder of the existing project in to the relevant parts of the asset pipeline and save that headache for "phase 2".
Sort out a gemfile with updated versions of our dependencies (for example, mysql gem has been replaced by a mysql2 gem.) Installing rubocop seems like a good idea at this point.
Copy files across from old to new project one at a time. Read the code, figure out what it's doing, write the relevant tests, fix where they break. Use the ruby API and rails upgrade guides to update the syntax. Refactor until rubocop is appeased.
Once we've reproduced the functionality of the existing site, write a new stackoverflow post on how to sort out the javascript ;)
This certainly sounds like a lot of work, but seems less likely to produce a buggy mess than trying to reproduce our existing functionality from scratch in a different language. So...
Questions
Does this strategy seem sensible? Is this a case where the re-write is really a better option? Is tackling the JS separately the best call, or is it better to restructure it as we're examining the calls to it from the views? Or should we really upgrade -> 3.0, 3.1, ... 5.0, 5.1?
We've altered the database manually, adding new tables, new fields and whatnot directly rather than using .rails generate. 'Rails magic' seems to make this work at present, but should we anticipate problems in step 3?
Is there any logical order in which to approach the migration of ruby? As there's major changes to the routing, which is the central entry point of the application, it seems sensible to start there, followed by authentication, then the main page, and then add functions one at a time.
Part of the problem is "not knowing what we don't know" about the rails way of doing things. Apart from the canonical Ruby/Rails tutorials (Hartl, Ruby Monk, Ruby Koans, Kehoe's rails book), is there any essential reading we should be aware of before trying to take on such a large job? I'm especially thinking about things that may not be immediately obvious, like proper use of helper functions, module structure, etc.
Any other advice, comments, prayers, ... welcome!
I have a large rails application with 3 separate 'components'.
One is a mostly static WWW site, one is a shopping cart based on Spree, and one is a reward-program based on Instagram's API.
Currently they are all one giant Rails 4.0 application. As this app has grown over time, I have it harder to make distinctions between components. I want to modularize the app to keep these 3 components separate.
Is there a preferred way to do this "SOA" sort of architecture? or would it be better to turn each 'component' of the app into their own mountable engine? Or is there an even better strategy?
I have been looking at Spree's core, and how they have each component as an engine, and load them in the top level, and I'm thinking this may be the best route.
I don't have any experience with Ruby or Rails, but based on my experience you will need to ask/answer the below question and then decide how you want to proceed forward.
Who's going to be developing the code base and who'll be maintaining it?
If it's just you who's wearing all the hats, you may not want to have the overhead of implementing SOA (web-services to be specific). That said, you should definitely have a 'Contract' between each of these components or modules (however you refer to them). That way your modules/components can evolve independently and changes made to one to make the logic better doesn't necessarily mandate changes to the other components.
If it's you and a couple of other developers, I'd still say that you may not want to take the WS route yet.
If it's different teams that are developing and maintaining these components, then you are taking about an application at enterprise level and then you will start seeing the benefits of SOA (based on WS).
Cheers,
K
I have been involved with several ruby on rails projects in the past, but I joined in those projects with a completely built rails app, complete with spec tests, factories, models, views, controllers and some custom libraries. I did hundreds of commits to fix assigned tickets in those projects, and I know the Rails MVC architecture well.
But now is the time that I need to create a Rails app from scratch, on my own, and despite my rails experience, I don't have the confidence to start.
My biggest problem is, how to decide the controllers that I will create, what is the purpose of the controllers that I create, the entire design of the web app, there's so many things that is running on my head right now, and I just couldn't sort it out.
Does anyone has the same situation, or have encountered the same problem before like me?
When starting a new application, I usually sketch out (on paper) a really high-level overview of what I think the core models of the app are going to be, and how they relate to one another. Obviously these will likely change as your application evolves during the development process, but it's a good place to start.
Then, from that pool, I identify the model which is most 'core' to the application's purpose - and I start by generating that with rails g model ModelName. For example: I was recently working on a hotel directory and started with the Hotel model.
Then I apply some pretty basic TDD methodologies and start writing the spec for the unit test for that model, run the tests, build, write more spec, refactor, etc. As bits fall into place, do a commit and move on. That way, if you go down a wrong path, it's easy to get back to a healthy spot again and you don't have to worry (as much) about making mistakes.
I usually find that by starting with the unit tests for the core models, the rest of your application will naturally evolve out. Once you decide to move onto functional and integration tests you should have a really clear idea about how all the pieces fit together and how your users should 'flow' through your application. This should naturally lead you to develop controllers that fit your different user's scenarios.
Above all, practicing is the best way to get used to starting from scratch. Build some basic apps with really clear outcomes, like a blog or simple scheduling tool. It will help you get used to the process so when you move onto bigger or more abstract applications - you'll be more adept at getting off the ground.
I would start with a tutorial that has you put a small system together from scratch like this:
http://guides.rubyonrails.org/getting_started.html
If you already have everything set up, you can skip to 3.2
Also, make sure you're using version control software and branch/revert often if you don't like the direction it's going (I recommend a distributed version control system like git as they often have better branching/merging)
Breaking a large rails app into smaller apps?
Modularizing Rails applications
Best practice for structuring a 'large' Rails app
I have a quick question on modularization in a large Ruby on Rails App.
Setup:
I am building a core app that stores information about people. I also have several 'modules' that use that information in very different ways. (e.g. one could display information about the people, another could figure out connections and commonalities between them, etc).
The question:
How do I modularize this app efficiently?
Potential Answers:
Since the modules share models and views with the core app (and eachother) it makes sense for me to combine them into one app. However, as the app grows this will obviously lead to problems. This to me suggests either Namespacing the controllers and models "How to organize controller in moderately large Rails application?" or using engines "Modularizing Rails applications".
Since the modules are in active development it is very helpful to use rails generators on them, which seems to make using Engines a pain in the butt. It also seems that while engines are fully supported from a Rails point of view, they still seem rather hacky with regard to lack of generator support and database migrations. Does anyone have experience with developing engines successfully? It seems like engines would be a great solution if you had a working app and wanted to port it into a plugin (i.e. copy paste code) but if you are actively developing it (changing models etc) it would be difficult.
The last thing I have seen around is using multiple apps and one database. This way seems like a royal pain with migrations and keeping models straight etc etc. But I thought I would get thoughts on that as well.
Rails engines seem to be the correct solution for you. I have used engines when I worked with Refinery CMS, which is built on top of Rails Engines.
The following are some nice links which talks about Rails Engines:
http://www.themodestrubyist.com/2010/03/01/rails-3-plugins---part-1---the-big-picture/
http://www.themodestrubyist.com/2010/03/05/rails-3-plugins---part-2---writing-an-engine/
http://www.themodestrubyist.com/2010/03/16/rails-3-plugins---part-3---rake-tasks-generators-initializers-oh-my/
http://www.themodestrubyist.com/2010/03/22/rails-3-plugins---part-4---more-on-generators/
I wouldn't use engines. Engines are meant to be used to share functionality between apps. What you want to do is not to share functionality but to organise it.
In order to organise your code you can do a lot of things.
Use namespaces.
Keep your controllers thin.
Keep your models thin (Yes, your models; see next bullet point)
Use the Data Context Interaction (DCI) pattern.
Use a widget framework like Apotomo, or Cells.
Write tests, so you can refactor.
Consider a Service Oriented Architecture(Consider Hypermedia API design) if your app's responsability grows too much.
Andrzej has very good articles about DCI.
http://andrzejonsoftware.blogspot.com/2011/08/dci-patterns-how-to-write-dci-contexts.html
One application, one database.
Share the models between the modules.
Namespace your controllers and views.
Test.
You can also use Rack Middleware to handle specific tasks.
For the bulk of your application, Engines seem like the best solution – it's something I'm looking at doing too. Looks like you can define generators in the Engine easily enough.
Depending on the structure of the data, and access patterns, it might be useful to separate the app into multiple apps, and possibly, additionally, provide data access by (RESTful) APIs.
In my experience, this allows for the best structures when your application(s) grow from middle to large size, and forces you to think about structures and separation of concern. Scaling up is also usually easier.
Just curious: I have to do a mini-CMS that allows users to add "pages" using a template. Each of the produced pages has/is an entry form and a "received" page.
I can visualize this in Rails pretty easily, but I'm wondering if there's any advantage to using a CMS like Refinery. Thoughts?
I was supprised to see Phil Arndt's answer voted down - I guess that it's hard to gain trust if you're involved in the product you discuss.
As for your question: sure you can build that site yourself, and most likely it will be simpler and will cost you less time than diving into the RefineryCMS documentation.
However most likely this site will evolve, your client will come up with more requirements, and it'll become harder to keep up with the complexity of the project.
Further more, you'll get more similar questions from other clients. Similar, but not identical, an you'll have to start from scratch every time.
A cms framework such as Refinery becomes an interesting choice at that moment. A framework gives you bigger building blocks than the Rails framework itself, so you can build faster. You won't have to reinvent the wheel for every customer request, since it will often be similar to what other people have built and shared (the "engines" in the case of Refinery). So the time you invest to learn to use the framework will pay off.
So in your case, even if you've already implemented your mini-cms, I'd consider redoing it in refinery or another framework CMS before you end up building your own CMS in which you'll have to duplicate all of the work already done for other CMSes...
One advantage to Refinery is that it has a very active (and growing) community of developers with an increasing number of 'engines' built to handle custom requirements. Also, by using an open source solution you have the opportunity to join in by providing patches for anything you think could be improved.
Another new advantage to Refinery is that it can hook straight into an existing application by following the very few steps in the integration guide.
Of course, this is all in addition to the fact that it aught to save you a lot of time as this use case has been carefully thought out over years of development with over 105 contributors and a large number of websites running smoothly in production.
Cheers,
Phil