Download to read offline
Uploaded byColoredCow
Why you should rewrite to Laravel by Nishanth Kaladharan
The document discusses the transition from Liferay (Java) to Laravel (PHP), detailing the challenges faced by the Liferay application and the benefits of rewriting it in Laravel. It highlights improved development costs, user experience, and long-term scalability as key advantages of the rewrite. Additionally, it emphasizes the importance of addressing evolving business needs and developer training within this context.
More Related Content
![[KaizenDiary] Minimize processing time on Automated Test](https://cdn.slidesharecdn.com/ss_thumbnails/studyimproveautomatedtest-190626102534-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Why you should rewrite to Laravel by Nishanth Kaladharan
Why you should rewrite to Laravel by Nishanth Kaladharan
- 1. Why you shouldrewrite to Laravel A success story of Liferay (Java) to Laravel (PHP)
- 2. INTRODUCTION Part 1 Asuccess story of Laravel Part 2 What we can learn from the experience Questions
- 3.
- 4. 1 A product thatis merely surviving 01 Challenges the Liferay Application was facing What went wrong with Liferay? 1. High configurability of Liferay wasn’t required. 2. Poorly written and architected. 3. Hard to train and induct developers. 4. High cost and timelines of adding new features.
- 5. 1 Idea of a Rewrite 02 Birthof secret Project X in Laravel. Parallely building a prototype in Laravel 1. Demonstrate the benefits of Laravel. 2. Redesign a better ver2.0 with improved features and usability. 3. Implement primary features.
- 6. 1 The Success 03 From survivingto the Moonshot Short Term Benefits 1. Lower Development Cost 2. Faster Development and Release. 3. More Usable Product Long Term Benefits 1. Higher budget for Product development and Sales. 2. Scaling with more users
- 7.
- 8. 1 When to Rewrite 01 Business needsit 1. Cost of maintenance is increasing exponentially. 2. Product requirements have evolved Technology is in question 1. Developers are hard to find and train. 2. Is not suitable for the product. Political Interventions (Ha Ha)
- 9. Why Laravel 02 Reduced costs 1.Easier to build. (Did someone say artisan?) 2. Easy to maintain. (Testing support) Easier to train 1. Training resources are plenty 2. Community presence is great.
- 10. The Approach 03 Julia How doesa rewrite benefit my business? CEO, Product X
- 11. 1 Questions ? Via NishanthKD, ColoredCow https://www.linkedin.com/in/nishanthkd/ Or Visit at www.ColoredCow.comYou can also stay in touch
- 12. References ● Min-maxing SoftwareCosts - Konstantin Kudrayshov, Laracon EU 2015 ● Rewrites vs Refactor: 17 essential reads for developers
Editor's Notes
- #2 Good evening Everyone, I must say, it feels great to be in the same room with a majority of the Laravel community present in India and neighbouring countries. I think as a group this conference is a huge step and my respect to goes out to the organisers of this event. My name’s Nishanth, I’ve been a Laravel enthusiast for the past three years. And While my journey in Laravel began as a developer, it has now grown into evangelising more and more application in Laravel. You might be curious and ask me at this point why am I evangelising Laravel. Is Taylor or someone from the Laravel community paying me to do that? In the past three years, I’ve seen that Laravel applications doesn’t just delight developers like me. Happy developers and good code delight business. I’m here today to share one such experience, and of course my learning from it. When Laravel took a business from a failed tech product to becoming a market leader.
- #3 I’ve divided this talk into 2 parts. In the first one we’ll talk about this success story of Laravel In the second part one we’ll gather our learnings from the entire experience. It’ll be a ten minute talk, save questions for later a five minute QA.
- #4 In fall of 2015, we started working on a product, written in Liferay. It had been acquired by various firms in the past 3 years and somehow with time, the product was surviving with beta users and rounds of funding. It was clear that if it continues on the same path, it would be a matter of another year before the product ceases to exist. There was a road map for version 2.0 a more stable, usable product that fits the markets needs. We came in as consultants to assist building this version 2.0 along with their in-house development team that was taking care of all the Liferay development so far.
- #5 In the first few months we realised that there were tonnes of reasons why the product wasn’t doing great. There were multiple reasons but somehow everything pointed to the Liferay application. Liferay was not fitting Liferay Provided a high level of configurability that the application did not need. The primary use case or the idea to be implemented was quite simplistic and did not require a heavy portal framework in Java. I remember booting up my dev environment would itself take almost 30 - 40 minutes. That’s approximately 2 productive hours of a team member gone to waste in a day without a single line of code. Poor Architecture Hard to Train The development team was not as skilled at Liferay, their decision making in terms of architecting and refactoring the code was very limited. Inducting new developers into the platform required months of training on the platform. Cost of Development With a team that was struggling to develop the quality features in time the development cost was high.
- #6 In late December, we considered the idea of re-writing this application in a new technology away from Java and Liferay. PHP Laravel was our choice of framework. We figured that with Laravel the development cost of the same features would reduce by 2x. Yeah I’m not kidding! It was that bad. We also figured that since the UI was obsolete and UX was bad, the application would anyways need a re-wamp in the near future. Before we would take this huge step we would have to validate that this idea is indeed correct. Laravel is a better choice for the future. So we estimated what it would take to build a certain feature in the existing Liferay application. It came out to be 1 month. Then we built that feature in Laravel. Any guesses on how much time it took? 1 week. Given the success, we put the Liferay application on the minimum support mode and started building ver2 in Laravel.
- #7 This project lasted for another 6 months, and in summer of 2016 we retired the Liferay Application. Today that same product is a market leader in it’s domain and supports thousands of lives. It continues to grow. How ? Slides
- #8 From this experience of Liferay to Laravel, we realised that there could be so many applications like this that have been built on frameworks and technology stacks that don’t fit in the scenario. Places where Laravel can help these businesses in a similar fashion. We figured we should extract our learnings from it and apply them in other places. It’s been about two years since then that we did more rewrites. From frameworks like Ruby on Rails and CodeIgniter.
- #11 A rewrite doesn't happen because X technology is better than Y or because Laravel is the best framework to build on. It always has to benefit the business. Focus on Long Term benefits from the re-write. Build it better than the previous one. More Usable Better Architecture Easier to maintain