Backend – part of software that don’t interact with user directly. In this article we want you to read about backend development on Ruby on Rails – part 1
Sometimes it’s hard to understand the difference between backend and frontend in web applications.
If we are talking about mobile application then things became clear enough.
The frontend – part of application user interacts with directly on his mobile device. Backend is opposite to that – it is a server-side part of application. User can’t even imagine what processes runs on background, how application interacts with database, process logic, calculates overall values and so on.
As a backend developers we are mostly worried about things like speed optimization, structure, security etc.
Usually frontend interacts with backend using API – application programming interface. In our case it is a set of protocols and routines that allow frontend application to perform low level logic backend tasks.
Last years the most popular approach is to use RESTful API – it is an architectural style that describes all components as resources and actions with them while focuses on their roles. This approach has its own pros and cons, but the main reason of using it remains standardizing and simplifying.
Why we use Ruby on Rails for mobile backend? Because it has many benefits:
- RoR allow us to develop mobile backend much faster because it already have good skeleton for implementation different types of tasks;
- great collection of open source code available within the Rails community; many common tasks are already implemented in optimal way and supporting during all product life;
- all Rails projects has the same structure and coding practices which means new developers can easy support their existing code, also they can move to another projects without having to spend many days for diving into unfamiliar code;
- Ruby on Rails has great testing tools. Using TDD and BDD principles is a common practice among RoR-developers and it helps to write high-quality code.
- Ruby code is often self-documenting, this means that we don’t need to spend time for writing separate documentation.
- Customer doesn’t have to pay for program components because most of RoR-libraries are open source and free.
Ruby on Rails is good for both highload and simple cases.
We have VYDA project with 100.000 registered users and very high trafic. It successfully working and grow using RoR. Also we have Box at Work project which serving 5-10 peoples per day which main priorities are reliability and consistency.
For both projects Ruby on Rails – is a great choise and we never disappointed in it.
We have small teams of strong developers on each project which communicate between each other in case of some questions or unusual situations. We have developers here in Ukraine, also we communicate with Polish developers which are worked on VYDA project.
We use different tools for effective communication:
- HipChat is for quickly questions and small discussions;
- GitHub issues is for detail problem/task description and task scheduling;
- We use mail for business correspondence and big tasks discussion;
- Sometimes we organize skype-calls instead of email for discussions, also we have everyday skype-calls for checking status and progress of all tasks;
Our team is not using all Scrum technics during development, only few of them. It’s enough for predictable and stable result and it fits our needs. As I said earlier we use GitHub (and GitFlow) for storing our repositories and collective work on them. Each developer runs rpsec and cucumber tests locally before pushing his code to GitHub. After pushing Jenkins automatically runs the same tests on server to verify everything is ok and changes don’t break anything.
Every developer should test his own changes locally before pushing them to remove repository. First of all, new functionality should be covered with tests to prove code performs well. When new code gets to remote repository and approved by Jenkins it reviewed with other developers to eliminate bugs which was invisible for author of code. If everything is ok new code gets merged and goes to staging server where it can be tested by QA. If bugs will be found during testing QA opens issues on GitHub with detail information about bug.
That’s all for Part One. In Part Two you’ll read about popular gems we use on projects, interesting technics to improve backend performance etc.