Blog Software Development TOP 3 products we've built in PHP – challenges and conclusions (PART I)TOP 3 products we've built in PHP – challenges and conclusions (PART I)
Our strong backend team works on large and complicated digital products, mainly in PHP / Symfony. As professional programmers, we love challenges – this is a part of our DNA we inherited from XSolve, the software house we’ve emerged from as Boldare. That’s why we decided to share our experiences with you and to show you what we’ve learnt through the most important PHP projects we’ve done so far.
Table of contents
Along with Mateusz, Paweł, Mariusz, and Sławek – our Senior PHP Developers – we’re setting out to create a series of posts discussing the biggest and most demanding projects. How were they constructed? What opportunities did they provide for us, developers? What knowledge did we gain thanks to them?
If you’ve already entered the “show-me-what-you-got” mode, here we go! Stay with us till the last sentence.
Tojjar – we made Etsy for the Middle East!
Recap
The first product we’d like to proudly present to you is Tojjar. The backend team working on it included Mariusz Bąk and Mateusz Rosiek, our Senior Software Developers, who both joined us almost 9 years ago.
Tojjar is an e-commerce platform operating in Saudi Arabia, directed to various users (B2C) pretty similar to eBay or more specifically - Etsy. Its main goal was to increase women’s participation in the labor market by enabling them to sell various handmade products.
Additional functionalities in the product included, for example, the possibility of booking a stand space in various governmental institutions or the opportunity to take part in tenders organized by companies.
There were also other options typical for e-commerce solutions, such us integrations with payments, SMS gateways, and shipping companies’ APIs (specific for the Arab market). The subsequent plans concerned extending the platform by B2B functionalities.
Challenges
There were a couple of challenges, various at each stage of implementation. Initially, we realized the MVP, whose objective was to demonstrate the prototype and to secure funds for the upcoming stages by the Client.
One of the challenges was the very short implementation period (6 weeks) and the resulting fact that we had to co-create, together with the Client, a certain range of functionalities that would be sufficient for the investors and possible to realize in such a short time.
From the very beginning, a lot of pressure was placed on the perfect mapping of the provided designs. Despite the short deadline, we immediately realized the MVP in the API + SPA architecture, so that we were able to create code that could evolve and develop in the following 18 months.
Later, we underwent a dynamic team scaling process (from 3 members to a dozen at one time). At that stage, the challenge we faced was to organize work in such a way that the value could be quickly delivered to the Client.
We also had to become better acquainted with the specific traits of the Client, who considered a wrong shade of green or a button displaced by two pixels as more problematic than the actual error occurring after clicking that button.
What’s inside?
Tech stack: PHP 5.6 and 7.0, API, Symfony 3.0, MySQL, ElasticSearch, ELK, REST, AngularJS 1.5, Gulp, Protractor, Flexboxgrid, SASS, SPA, RWD.
Working on the backend part, we wanted to organize the code as best as possible at once. First of all, we used the Command and CommandBus patterns to structure the business logic in a clear manner.
The REST API was not based on database entities but on DTOs, whose structure was often adjusted to the needs of the Client’s SPAs, thanks to which we could make them independent of the database structure and we were able to limit the number of queries. We introduced a unified method of entity filtering (both with respect to those downloaded by means of queries and those available in the memory) by employing the Specification pattern.
What’s more, we prepared simplified mockups of external services (the single sign-on solution, the SMS gateway) to be able to test our app effectively regardless of the service providers’ problems.
To build the developer editions of the project we used Docker and Docker Compose. At that stage, the technology was so advanced and the project was so complex and dynamic that the maintenance of the local environment got difficult. From then on, Docker became the standard tool in all our projects.
Lessons learnt
- It was a pretty complex project, one of the first at Boldare that we had implemented in the API + SPA model.
- The CommandBus that we used served us well, so now we often employ it in our projects.
- We learnt how to use Docker, and the experience we gained in that project helped us create a tool for the dynamic construction of test and demo environments.
- We also improved our methods of cooperation in a large team, trying out various agile work methodologies – Scrum and Kanban.
- Finally, it was the first time we had worked with a client from the Middle East, so we learnt a little about cultural differences and how they can influence the everyday cooperation.
Summary
We’re happy you’ve reached the end! Was that an interesting piece for you? We’ve got more coming quite soon - featuring even more insights from our developers, the technical solutions we used, and the lessons we learnt for the future. In the new post, we’re going to tell you about how it was to work with the world’s largest carsharing startup as a client – BlaBlaCar.
What you see here is our daily job. We design and build large-scale digital products for international clients. If you’re interested in what we do and you want to get to know us better, don’t hesitate – you’ll find more info about us on our Career page (first of all, see the video and look up the PHP job offers). If you have any questions, feel free to write to us at career@boldare.com.
Share this article:
