Breaking MVC in “Big” Projects

I hate talking about a topic that is extensively discussed on the Internet, but I have some thoughts.

I worked on a mid-size project as a full time software engineer. My tasks was on the backend part, though I had to implement a raw “views” for each task so it will be crystal clear for the frontend developer to implement it in a nicer way.

I had to do this always — as I’m not good at frontend development, and the other developers were great at it. Oh, Stop here. We are woking separately, on the same project. You can see.

I was working mainly on the architecture, database scheme and models, business logic/rules. The other developers’ main tasks were on working with views as well as some logic.

If you lookup on the definition of MVC on the wikipedia you will notice that any changes on the Model or Controller layer will affect on the View layer, so frontend developer should be aware of every change made to the models and the controllers.

Not having an API in 2012 is like not having a website in 1998.
— @brentgrinna

Later, I decided to move forward and build an API to serve the application we were building -because we had a future plans to have a pubic API-. We thought this would break the MVC as an alien component has entered our stack, but still -as you can guess-, our API was being served as the controllers.

We were using Rails. Most of the views were converted to be Javascript templates. We had lots of decorations and serializers. The application was fully served by calling the API and returning JSON data — I can remember that the only feature that wasn’t served via JSON is managing users: sign up, sign in, edit profile, etc.

The end points of our application were two: the API, the Javascript application. Our focus was dispersed as organizing this was going wild. So I decided to separate the application as our tasks were mostly separated and to have flat layers, one for providing data (API = models + controllers) and the other for presenting it (Javascript application).

Breaking MVC!

I can easily pull out the frontend components to a new “Static” project, but mainly, since I loved Rails’ Assets Pipeline, I managed to have the frontend in Rails.

1. We moved the API to a new Ruby application along with the models and logics.
2. We set new jobs for the current Rails application that we loved mostly in Rails: Database Migrations (Django implemented lately) and serving static pages with Assets Pipeline and tons of gems that help with the UI.

Each application had its tests that are running separately as well.

In the coming years, HTML5 is going to lead the standards of the web development and with the awareness of using JS frameworks, we can understand the separation in the data and presentation layers already.

This complete separation of layers is made possible due to the fact it is simply impossible for code to leak between the layers due to the different implementation or different languages used in each application. This means I could easily change and use numerous front end views while the backend remains the same. Likewise we could change the back end from Ruby to another language. Providing the endpoints and request/responses match, and the same for the front end, it will still be functional. This full separation of concerns is what MVC frameworks have not succeeded to achieve.