BraveBits bắt đầu hành trình của mình vào 2007 với một mục tiêu duy nhất: Tạo ra những sản phẩm giúp cho Thương Mại Điện Tử dễ dàng hơn và dễ tiếp cận hơn với tất cả mọi người. Kể từ đó, chúng tôi không ngừng học hỏi, thích nghi, phát triển và mang đến sự đổi mới trong tất cả những sản phẩm của mình. 

Trong bài blog này, cũng lắng nghe câu chuyện từ anh Minh (Paul) – CTO của PageFly. 

Kể từ khi PageFly mới chỉ là một ý tưởng, đến PageFly 3.0, kể từ khi team chỉ có một vài người đến một đội ngũ hơn 40+ con người cùng chung một tiêu và kể từ 0 đến 90.000+ khách hàng toàn cầu, Paul vẫn luôn ở đây và sự đóng góp của anh đặt nền móng cho sự phát triển của ngày hôm nay. 

Q: Hi Paul, đối với anh đâu là thách thức lớn nhất trong quá trình xây dựng PageFly và anh vượt qua các thách thức đó ra sao? 

Paul: 

Trước PageFly thì mình cũng có thành công nhất định với một sản phẩm xây trang khác là JSN PageBuilder 2. Phiên bản đầu tiên của PageFly thì lấy cảm hứng nhiều từ JSN PageBuilder 2, và nhìn như thế này: 

Nghe thì cũng có vẻ là ngầu nhưng mà đằng sau nó thì những công nghệ JSN Page Builder 2 sử dụng cũng nửa mới nửa cũ – mới thì là React, React thời điểm đó mới ra được hơn năm, hoặc là những cập nhật mới nhất của JavaScript, nhưng mà vẫn còn nhiều công nghệ cũ. Và khi mình kết hợp công nghệ cũ và mới với nhau thì những cách mình làm chưa được chuẩn ví dụ như là mình phải viết rất nhiều custom code để đạt được mục đích cho một tính năng ( element) duy nhất và không biết rằng nó ảnh hưởng đến các tính năng khác và không có một hệ thống rõ ràng, do vậy, sản phẩm ngày càng khó để phát triển hơn.

Sau đấy một thời gian thì cả team họp lại và quyết định phải làm lại sản phẩm một cách chỉn chu hơn, thì sau đấy mới bắt đầu tìm hiểu những phương thức làm mới. Quyết định khá là to đó là cả team quyết định đập đi xây lại và tạo ra JSN Page Builder 3, và từ đó thì xây PageFly bản đầu tiên. PageFly và JSN Page Builder dùng cùng một lõi, chạy trên hai nền tảng, một là Shopify, hai là Joomla. 

Hai sản phẩm này thì cũng được tối ưu rất là nhiều, và cập nhật những tính năng mới nhất của JavaScript và React. Tuy nhiên sau đấy mình không tự hào gì vì backend được xây dựng công nghệ cũ là PHP – sau đó một thời gian thì PHP nó có rất là nhiều lỗi mình mình không kiểm soát được. 

Sau đấy thì mình quyết định xây PageFly V2 – hay gọi là PageFly Reborn. PageFly V2 thì bao gồm viết lại phần backend bằng NodeJS và MongoDB thay thế cho PHP và SQL ngày xưa. Đồng thời tiếp tục tối ưu code và data structure của mình – dữ liệu của các page, mình sắp xếp dữ liệu sao cho app chạy nhanh nhất và hiệu quả nhất có thể, và mình có thể scale sản phẩm nhanh hơn. 

Ở phiên bản 2 thì mình cũng có một design system mới, do team Inhouse làm ra và phát triển với Styled Components. 

Q: Vậy thì đâu là sự khác nhau lớn nhất giữa Design System của PageFly V2 và PageFly V3? 

Design System của V2 thì do mình tự phát triển nên số lượng component khá giới hạn, mặc dù team in-house cũng khá mạnh. Tuy nhiên app ngày càng phát triển thì mình không đủ nhân lực để thiết kế hết tất cả component mình cần. 

Design mới dựa trên Ant Design, Ant Design cung cấp cho mình rất là nhiều các component mà mình cần – các nút, layout, accordion, text thì tìm trên Ant Design đều có hết. Phiên bản mới với Ant Design thì được tối ưu cả UX và UI – màu sắc, text, animation, tất cả đều theo quy trình và hệ thống, từng chi tiết đều có sự tính toán tốt hơn từ đó tạo ra trải nghiệm tốt hơn cho người dùng. 

Q: Vậy em hiểu là Design System mới sẽ giúp cho mình phát triển sản phẩm được nhanh hơn, bởi vì mình có thể phản ứng nhanh hơn với nhu cầu của khách hàng trong quá trình dùng app?   

Paul:

Đúng rồi. Design System mới có sẵn rất nhiều components và có thể  phục vụ cho cả sau này. Sau này PageFly có nhiều tính năng mới thì  mình không cần thiết kế quá nhiều mà mình chỉ cần ghép components với nhau và code thôi. 

Ngày xưa thì mỗi khi có một tính năng hoặc yêu cầu mới thì mình phải vẽ lại từ đầu và nghiên cứu từ đầu, thì so sánh với hiện tại mình tiết kiệm được nhiều thời gian hơn rất nhiều.  

Ở bản PageFly V3 thì code cũng được tối ưu lại và gần như viết lại hoàn toàn, tiếp tục tối ưu code và tối ưu server. Mình cũng tối ưu lại code của PageFly V2 lên V3 và cập nhật những thư viện chính mà mình sử dụng là React và Styled Component, mình cũng đang sử dụng những tính năng mới nhất của React như React Hook và mình cũng tự viết các thư viện quản lý state của React. 

Q: Vậy thì đâu là mục tiêu tối thượng của mình cho những lần cập nhật từ V1 lên V2 và V3? Để cho app chạy nhanh hơn, khách hàng dùng sản phẩm dễ dàng hơn đúng không ạ?

Đúng và Sai. 

Đúng vì ngay từ đầu thì mình vẫn đặt Trải Nghiệm Khách Hàng vào trọng tâm, do đó mình cập nhật và cải thiện PageFly với mục đích là giúp khách hàng xây trang nhanh hơn, dễ hơn và hiệu quả hơn. 

Không là vì với những lần cập nhật app từ V1 lên V2 rồi lên V3, mình có có một mục tiêu khách cũng quan trọng ngang bằng đó là anh em mới khi tham gia vào công ty, vào team Dev thì có thể tiếp cận nhanh hơn với sản phẩm của mình. Ngày xưa thì sản phẩm có nhiều custom code, và rất là rối, nên là khi anh em mới vào thì phải mất nhiều thời gian để học và mày mò để code được các tính năng. 

Tuy nhiên sau PageFly V2 và V3 thì mình tối ưu rất nhiều cấu trúc code của mình – cấu trúc code hiện tại sử dụng nhiều chuẩn mới, ví dụ như khi mình code với React Hook hay với công cụ quản lý state. Hồi trước anh em mới phải mất 3 tháng để làm quen trước khi bắt đầu công việc chính thức tại team Dev, nhưng mà dần dần đến bây giờ thì anh em mới chỉ mất khoảng 1 tháng để training là có thể vào code các tính năng cho app được luôn. 

Q: Anh có thể cho em một tóm tắt về những công nghệ cốt lõi mà mình sử dụng với PageFly không ạ? 

Paul: 

Ừa mình kết hợp khá nhiều công nghệ lẫn với nhau đồng thời mình luôn gần như tận dụng những cơ chế nâng cao nhất và mới nhất trong các công nghệ mình dùng

• Styled Components 
• State Management Library
• React & React Hooks
• Ant Design 
• NodeJS
• MongoDB 

Cụ thể hơn chút thì React là không thể thiếu. Ngoài React thì mình có sử dụng Styled Components – mình còn áp dụng những tính năng nâng cao của Styled Components. Tiếp theo thì có thư viện quản lý State của React, ngày xưa thì mình thử nhiều thư viện như Redux hay Backbone, nhưng mà gần như không đáp ứng được cách mà mình triển khai Page Builder vì có nhiều components móc nối lẫn nhau và những thư viện này thì rất tốn chi phí, chậm và không hiệu quả. 

Sau đó với phiên bản V2 của PageFly thì mình viết một thư viện quản lý state riêng và dựa trên tính năng mới của React là React Context. Một thời gian sau React Hook ra đời thì team cũng quyết định nghiên cứu từ rất sớm, từ những bản Beta, thấy rất phù hợp và quyết định áp dụng cho sản phẩm của mình – tạo ra một thư viện mới dựa trên React Hook và Context để tạo ra thư viện hiệu quả hơn, thư viện mới thì có tên là Global State Hook. Thư viện này ngắn gọn thôi chỉ có khoảng 50 dòng code là có thể quản lý state của React rồi. 

Q: Vậy thì ở cương vị CTO, đâu là tầm nhìn và định hướng phát triển của anh với PageFly? 

Paul: 

Đối với anh thì anh luôn thích công nghệ mới, ví dụ trong tương lai mình có tính năng mới thì anh sẽ tìm hiểu công nghệ mới nhất để làm. Trước mắt thì vẫn tiếp tục dùng ReactHook, Styled Components và các công cụ quản lý State mình đã có, và kể cả công nghệ backend như NodeJS và MongoDB – mặc dù mình sử dụng lâu nay rồi nhưng nó chưa hề cũ và vẫn luôn được cập nhật, thì mình sẽ tiếp tục theo dõi và cập nhật theo từng phiên bản. 

Theo hướng mình phát triển thì mình hoàn toàn có thể phát triển Headless Commerce, nhưng mà mình sẽ phải tìm hiểu ngách để làm cho phù hợp với nhu cầu của thị trường. Để nói về hiện tại thì trong vài năm tới thì vẫn tập trung vào PageFly và bổ sung các tính năng cần thiết như Mobile Editing, hoặc A/B Testing. 

Sau đấy thì có thể làm ra một phiên bản Software As A Service, làm ra một công cụ có thể kết hợp với nhiều platform khác nhau, không chỉ với mỗi Shopify mà có thể với Joomla, BigCommerce, Magento, vv. 

Q: Cảm ơn anh rất nhiều – câu hỏi cuối cùng: Đâu là thành tựu mà anh thấy tự hào nhất trong quá trình xây dựng PageFly? 

Bản thân anh thì anh tự hào nhất là sự kiên trì của cả team, kiên trì đi đến những phiên bản mới, liên tục cập nhật app và kiên trì với cách làm của mình, dám thử những cái mới, đặc biệt là những lần mình dám liều đập đi xây lại, ngay từ JSN Page Builder 2. 

Có một thời gian ở team PageFly thì ngày nào cũng OT đến 9, 10 giờ tối – thời điểm mình chuyển từ PageFly V1 từ PageFly V2. Thời gian đấy ở lại công ty rất là nhiều, và cũng may là sản phẩm chạy ngon. Có một lần release sản phẩm và dính bug xong phải ở lại đến tận 1h sáng. 

Nói chung là sau nhiều thay đổi thì thấy mình không muốn anh em khác phải chịu áp lực như mình hồi xưa, nên bây giờ app ổn định hơn nhiều và anh em Dev cũng có nhiều thời gian hơn, hết giờ làm về. Đấy cũng là một điều anh cũng khá tự hào, vì mình cũng góp phần tạo ra sự ổn định đó cho cả team. 

---

Inside PageFly: A Tale Of The Technology We’ve Developed

It was back in 2007 when our team first started this journey with one goal: create products that could make ecommerce effortless. Since then, we have (almost) never stopped for breath, running at full speed to adapt, grow and bring forth innovation. 

In this blog post, we’ll dive into an interview with Paul – CTO of PageFly. 

From the inception of PageFly to PageFly 3.0, from a team of less than 3 people to a growing team of 40+ extraordinary human beings, from 0 to 90.000+ global customers, Paul was there all along and his contribution is what made it possible for us to get here. 

Q: What Was The Biggest Challenge During The Inception of PageFly? 

Paul: 

Prior to PageFly, we had some success with another Page Builder – which was JSN PageBuilder Jo. The early version of PageFly drew a lot of inspiration from JSN Page Builder 2, which looked like this. 

At that time, Joomlashine Page Builder employed the latest technologies at that time like React, Redux, CSS Module, in combination with popular JavaScript libraries like jQuery, UnderscoreJS, BackboneJS. Joomlashine Page Builder grew to be top 03 most popular Joomla page builders. 

However, the thing is: After lots of updates, JSN PageBuilder codebase was becoming cumburous as its technical debt was constantly thrusted with custom codes to meet customer demands. The technologies behind Joomlashine Page Builder 2 were neither fish nor fowl and it was getting harder to maintain and scale. 

Because of this not-so-optimized combination, it was not the most efficient product. The team had to write lots of custom codes for each functionality or feature – which consequently could make them cancel out or badly affect each other’s performance. 

So we put our heads together and decided that we could, and should build on Joomlashine PageFly Builder 2.  So we set up and researched about the latest technologies we could use at that time – which was 2017, and we made a bold move, to scrape off the whole thing and build a brand-new Joomlashine Page Builder – JSN Page Builder 3, and from this, we built  PageFly – the official first version of PageFly Page Builder. 

Both Page Builders used the same core technologies – which was a major step up from Joomlashine Page Builder 2 with the latest applications of Javascript and React, just operated on different platforms – one on Joomlashine and the other (PageFly) on Shopify. 

The thing is, we did not stop to pat ourselves on the back because lying at the backend of both PageFly and Joomlashine, was what I’d call “old technologies” – PHP – it was a technically inconsistent language with not-so-good design – which spawn out a lot of uncontrollable bugs. 

So we set out to create PageFly V2 – or what we called PageFly Reborn. The first thing I did was to reprogram our backend with NodeJS and MongoDB to replace PHP & SQL. The second thing we did was to optimize PageFly’s data structure with NodeJS and MongoDB to allow for more robust performance and better flexibility & scalability. 

We also deployed a new design system – designed by our inhouse team and developed with Styled Components. 

Q: So What Are The Biggest Differences Between the Design System of PageFly V2 & V3? 

The previous design system was created by our inhouse team, so it was a bit limited. 

For example, if we had a new element or feature, we’d need to design it from scratch, whereas with the new design system – which was based off Ant Design – we can get access to an extensive library of element and feature designs. Everything we need can be found on Ant Design. 

The new design system is also UI/UX-optimized. For example, with the previous design system, the way we designed app UI & UX can be inconsistent and we just did not have enough resources to make everything perfect as we wanted it to be. However, with the new design, we have a more systematic and consistent approach to UI & UX design, down to the tiniest details and components, allowing us to create a better in-app experience. 

Q: So I understand that the new design system allows PageFly to grow faster as now we have a better capacity and flexibility to respond to a growing demand and customer base, is that correct? 

Paul: 

That is correct. 

The new design system has lots of components that we can use for PageFly updates in the future, we can streamline the development process by minimizing time spent on design new elements/functionalities and simply leveraging this design system. 

We also ran another round of app optimization with optimized codes. Basically we updated our React & Styled Component Libraries and employed the latest addition in React – React Hooks to manage React state and other React features more effectively. 

Q: What is the singular goal of our Product Updates? From V1 to V2 to V3, is it all about creating better customer experience with the app’s better capacity and flexibility? 

Yes and No. 

We are customer-centered from day 01, so yes, we continuously update PageFly so that our customers can build their own dream stores faster, easier and more efficiently. 

and No, it’s not the singular goal. There is another goal of equal importance. The other goal is to allow our new developers to quickly understand how the product works. With the previous version of PageFly, the code was a maze with lots of customer code – so it took months of training and tons of fumbling around for our new developers to get a grasp of the product. 

But with PageFly V2, and PageFly V3, we improved the structure of the code a whole lot – it’s more standardized, so it’s a lot more accessible to new developers. 

Q: Can You Give Me A Recap Of The Key Technologies You’re Using For PageFly? 

Paul: 

Sure, I’d say they are: 

• Styled Components 
• State Management Library
• React & React Hooks
• Ant Design 
• NodeJS
• MongoDB 

Q: Thank you. What Is Your Vision For PageFly? 

Paul: 

I always keep a super close tab on State of the Art technologies – so if there is a new technology that can be applied to make our product better, you bet that I’ll look into it. 

We’ve talked about PageFly going into Headless Commerce but that would be in the next few years and require  intensive market research. In the very near future, the team aimed to add new features to PageFly like A/B testing, Content Scheduling, and Mobile Editing. 

Q: Thank you a lot for having the time to sit down with me. Last question: What Is Your Proudest Achievement In The Whole PageFly Journey? 

I have always been proud of the team’s perseverance and determination, marching on to take feedback and create better products, marching on to boldly step into the unknown and bravely take on new challenges – like scraping off the whole thing and building the product up from scratch.  

There was a time when everyone OT-ed to 10pm, everyday for like a week or so. It was fun, but I valued work-life balance so as I said, that’s why we continuously update and improve our app making it more efficient and stable, so that the team does not have to endure the same pressure I had with the early version of PageFly. That’s another thing that I took pride in. 

Learn more about Career and Job Opportunities at PageFly & BraveBits: Join Us!