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
Related
I'm dealing with a rails application which is growing too big. It takes long time to start and lots of memory. We are having performance issues. Tests are very slow. Managing the codebase, debugging and introducing new futures becoming harder everyday. We are thinking to split the application into smaller components (Rails engines or different Rails apps) where all components will share a single database.
Considering such scenario we will need to share the models, maybe some libs, tests, and some gems, etc... It doesn't sound right for me!
Is there any pattern can be applied?
There are some great suggestions here about to to split up a Rails code base however I think that before you apply any of then you need to stop and seriously consider how you got into this position. All of these solutions introduce new complexities and challenges. They might be worthwhile trade offs but only if you make sure they also solve a problem you have today.
Take each of the pain points you listed (startup time is slow, memory use if high, performance is poor, rest performance is poor, development speed is slow) and run a "5 whys" exercise on them. Why are these things happening. Why did the app get into this state.
Most importantly before you commit to any plan for splitting up a large app consider if the app should be large in the first place. If your app is more complex than your product demands then switching to an equally complex cluster of services is not an improvement.
More concretely I would recommend against shared database access between apps/services/whatever. A shared database has a shared schema which becomes fragile. It also leads to tightly coupled services which lack the separation of concerns you need to see any improvement in your pace of development. Just as splitting one massive class into several tightly coupled files does not improve it nor does splitting one app into coupled services.
If you must maintain a large app you need to isolate separate concerns. In order to do so you need to break the dependencies between them. Based on the efforts I have seen to repair Rails monoliths you'll have better success creating clean interface within your existing app an then splitting out components than if you split the app apart and then hope the resulting pieces can be improved independently.
Yes, there are several ways to do it:
Micro services Erin Swenson-Healey has a nice post for rails.
Hexagonal Architecture GoRuCo 2012 Hexagonal Rails by Matt Wynne and Refactoring with Hexagonal Rails
Rails Engines Approach. Dealing with Rails Application Complexity - A Report from MWRC
Use other framework more suitable for high complexity and more PORO oriented. http://lotusrb.org/
Also see Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin
Read "Practical Object Oriented Design in Ruby" by Sandi Metz. Also, watch every presentation and talk by her on the internet. Youtube is a great place to start. She's a great speaker. Rails is written in Ruby and Ruby is an object oriented language which brings with it massive benefits. But grokking the object oriented part takes a little work. Sandi will get you there.
I consider myself a well trained WordPress template developer, and i recently started to read books and documents about web app frameworks, particularly Django and Ruby on Rails. I didn't know any of the two languages, but i have no problems to learn another one or two. I really don't get the real benefits of using a framework, because i feel very confident about the power of WordPress. So, can anyone tell me the real benefits of using a framework? For example, Pinterest is made using Django, but i think that i can achieve the same results with a WordPress template using Javascript and CSS3. Can anyone tell me the differences/benefits of using a framework in that particular case?
You can achieve the same frontend with Wordpress, but what you will not be able to achieve is the speed and scale - and most importantly, maintainability - of an application based on a more application-oriented architecture.
Wordpress is highly flexible, but it's also slow, and needs an awful lot of TLC to be able to operate at any kind of significant scale. Its design allows for very flexible runtime modification of behavior, but this is also a bit of a Pandora's Box, since it means that code can end up running all over the place for any given page, which makes maintenance a nightmare.
Wordpress is extremely good at being a CMS, but once you start to push it outside of those bounds, you get into trouble, and find yourself having to write your own more abstract framework that runs inside of the context of Wordpress to be able to fulfill your application's needs.
That said, if you have an application that you can build in the context of Wordpress, I'd say go for it! Wordpress can be a wonderful tool for building a proof-of-concept or MVP. If it gets you up and running, then it may be the right choice over writing a full application. However, just be aware that you're going to hit some brick walls as your product design matures and your audience grows, unless your application fits within a rather narrow set of design requirements, so long-term, you may find yourself having to move to a custom application.
Credentials: I've spent the last couple of years maintaining a Wordpress install that served over 25 million monthly uniques, and we had to get very clever to keep it running. We've since replaced it with a Rails application that serves pages somewhere on the order of 10x-30x faster, and is significantly more extensible as an application, allowing us to start exploring application potential that we really couldn't get with Wordpress.
I once made the decision while working in some start-up to choose WordPress for an advanced e-commerce, community-driven marketplace.
It was an awful decision
This is how I was feeling:
At the beginning, it was looking good - you have an amazing community, plugins for everything etc. But sooner than later I hit the wall - at it's root - WordPress is a blogging platform!
Every piece of content technically is a post.
It's really hard to create advanced item relationships
Functionalities are not consistent. Some functions work one way, while others that seems to be very similar work in a different way. Sometimes you need some weird hacks to achieve task that seem to be simple. It makes you read the docs very often to see how a function that you're using for the 1000th time is working. (However, to be honest, I need to say that the WordPress documentation is great!)
The WordPress community is doing a great job, but compared to any regular Framework there is one main difference - Frameworks are just frameworks - they're a set of tools and those tools are there to help you do your project. WordPress already is trying to be something that you might then change.
I'll never again use WordPress for anything that needs some organised, custom functionality.
I'm actually quite impressed with what people has created with wordpress - so if you want to, it is possible and good luck!
It however often feels like buying a truck and rebuilding it to be a house. There are better ways to build a house.
I want to offer a dissenting opinion, even though I upvoted the top answer.
Is Rails really special?
Rails was created by David Hansson who extracted it from Basecamp, software that's replicated in a free Wordpress plugin, WP Project Manager. I think that's a pretty good indicator that Rails developers are underestimating PHP and Wordpress.
MVC and WP
True, it doesn't follow an MVC pattern. But if you use hooks, separate logic (in plugins) from views (in templates), then you'll have good code separation. (Also hint: custom post types are like models.)
Framework vs Application
As you can see, Wordpress can be treated like an application or a framework. It is an application, with all the components you'd expect to find in a framework. Right out of the box you have security, authentication, and extendibility. And it's meant to be extended.
Scaling
WP powers 18% of the internet's websites, including TechCrunch, Smashing Magazine, and (parts of) CNN. Seems there are ways to make WP scale. Disclaimer: I have no experience working on megasites like these, so I'm offering mere conjecture.
WP Future
The current abition of the WP community is to shift WP from a CMS to a framework. I think it's a natural progression considering that all the pieces are in place. And the Wordpress community is going strong.
Not really an answer, but a hint:
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
As if you can replace it completely... I think it is mostly a matter of logic flow. It depends how much imperative (Ruby on Rails) vs. descriptive (WordPress) programming you intend to do.
I don't think wordpress can replace rails, because wordpress have limited set of API and support as you compare it with RoR. Though wordpress is powerful tool for blogging application, but the same effect can be achieved with rails using gems like,
Radiant CMS,
Refinery CMS,
Locomotive.
Adding the power like ttd that can be done vary easily with rails is very difficult with wordpress.
Same with authentication and authorization mechanism like devise and cancan. There is no easy option to do the same with wordpress.
Rails make the programmer's life easier. For whole web app I will always prefer to go with the rails.
Wordpress cannot replace X framework, but the two can certainly complement each other.
For example a WP front end serving up CMS content with an attractive theme is pretty hard to beat; proxy to a back end server for custom content and voila, best of both worlds. Otherwise, WP will inevitably fall short of meeting every requirement and you'll find yourself going down the square-peg-round-hole rabbit hole, a painful place indeed; that's where X framework comes in, filling in the WP gaps.
The notion that WP does not scale may have some truth to it, but for the general case, the 95%, it will handle whatever you throw at it, particularly with WP Cache or other caching plugin thrown into the mix.
Some may say, well, you can build WP with Django or RoR! Heh, heh, you first ;-)
FWIW, I avoid dynamic language frameworks in favor of their statically/strongly typed counterparts. Use WP for the bling, and static X framework for the speed/scalability/safety. Of course, that's a matter of preference, clearly some prefer runtime flexibility over compile time safety. I'm fully in the latter camp these days...
In the simplest term,, I always want to put it like this...
You can use a framework to make WordPress it self and better
But you can't use WordPress to make a framework
Wordpress is a great CMS any way
Pros
1. We can easily set up a website using free themes and plugins
2. There are numerous number of plugins to extend our website functionality
3. Excellent Community support
4. The CMS uses PHP and MySQL, somewhat easy to lean
Cons
1. Updating plugins and themes regularly.
2. Slow
3. Malicious files can be easily injected.
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
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.