Planning the development of this platform took around a month. During that time, different ideas popped on our mind, different approaches, and by the time we started the development, we were sure of our choices and that the path was right.
What is GetByBus consisted of?
I will write a little more about the architecture of the system and the development tools used on this project in the end of this article, and now we will present the final product with lots of photos of course 🙂
The system is consisted of 4 mayor modules:
- centralized routes search and tickets purchasing
- routes and companies management admin interface
- SEO optimized content on multiple client web sites
- Services architecture built for heavy load and multi client environment
We will explain each of those in the following paragraphs and then talk a little about architecture and technologies used.
Centralized routes search and tickets purchasing
This module is the main getbybus.com. It is the main front interface of the platform. Users can login with their email or g+ account, the can search for different routes, and they can purchase tickets. Tickets can be single, return or open return.
Users can choose their passenger group (adult, children, pensioner etc.), they can earn discounts if traveling with the same company. They can view their purchase history, and use online credit card payment to purchase new tickets.
Routes and companies management admin interface
This module features a multi user permission based interface for different levels of platform administrators and bus companies. Almost any aspect of the system is configurable and different user groups can see / access different kinds of management, reports, receive notifications etc.
Some stuff you can do: manage and geotag stations, manage companies, manage ticket types, manage passenger groups, manage route allotments, route allowances, add prices, clone routes, add operational and not operational days, manage tickets, manage ticket passengers, manage languages, currencies, domains, countries, export most of the stuff stated etc.
The system automatically sends all sorts of notifications (like “your allotment is close to full, increase it?”, “your bus is departing soon”…) handles all sorts of checks (“you can’t lock that route for sales, some prices might be entered wrong”…) calculates all sorts of exports (“passengers of a route”, “tickets sold today”, “live ticket selling preview”, “all companies routes status”…).
This module was programmed with lots of care and is suitable for quick and pain free upgrades of any kind, just what you often miss in a big scalable admin interfaces.
SEO optimized content on multiple client web sites
Building a complex management and purchasing system doesn’t really make any sense if you don’t have anyone to sell the tickets to! Thats why the getbybus network features a distribution network of SEO optimized sites based on a simple wordpress CMS solution.
Users search for a bus route, land on our blog post about that specific destination, and that landing page is connected to the central getbybus system thus also displaying available routes with prices and BUY button. This display network features hundreds of thousands of visitors and assures that the getbybus platform has enough user flow to generate income and add new bus companies.
Services architecture built for heavy load and multi client environment
Services are the brains behind all the search and display logic in getbybus.com system. It provides an API that sends all the data to other modules. Central site, admin interface, display networks, all pull their data from the services. The services can also be easily integrated to other web sites that wish to become reseller partners. Thus said, it is obvious that this is the one point with the heaviest load. We implemented multiple levels of caching, and spent lots of time optimizing our db queries and parsing logic to bring even complex searches to just a few milliseconds.
The ideas behind architecture
While thinking about how to approach building such a bit system from scratch, we decided to build it as 4 completely code-non-dependant modules, which we wrote about above. This enables us to later on upgrade / refactor only parts of the system, not having to do it all at once. For example, we could simply discard the entire backend interface and use another technology to recode it. We could do the same for lets say service! Each module by itself, especially the admin interface is build in the manner that it is super easy to add new features, generate exports, enable permissions etc.
This kind of flexibility enables us to easily support any pathway the system takes in the future.
For each of the modules we chose the technologies depending on what suites the required needs the best:
- Central site – Symfony2 framework – we needed a stable framework with lots of additional modules and high level of security
- Admin interface – CodeIgniter + Laravel – we needed an easy and modular system with lots of options for check, exports, close to raw PHP, with not much framework overhead. We took whats best from each framework and made a great CI + Laravel system.
- Services – Custom services framework – since Profico focuses parts of its business as a company developing mobile apps, each of those apps needs a strong web services framework, and over the time we developed our own. The framework takes extra care about security and performances, which is the most important part for any services
- SEO display platform – WordPress + wordpress plugin connected to services – this part of the system is widely used thus we wanted to use something every webmaster or even a newbie is at home with, making a simple wordpress CMS the best solution.