Moving from PHP with Laravel to React and NodeJS

This article aims to share my personal experience and reasons for moving from PHP with Laravel to React and NodeJS.

About Me

I started my career as a web developer using PHP 5. Later I discovered the Laravel Framework and kept using it since their version 4. Even nowadays, I still maintaining some repositories with Laravel.

I was already experimenting with new technologies like NodeJS, GraphQL, and React in my free time. I had the opportunity to apply them in small projects at work that provided me the necessary experience and confidence to work at production with this new stack.

Problem Context

I was the CTO of a travel startup focusing on the Japanese market. The team I was working with consisted of 2 programmers who were mainly back-end developers using PHP + Laravel.

We created our MVP using Laravel 5 without an API. Everything was working fine until we needed to make a mobile app.

At that point, we decided to:

• Create a new repository using Lumen, a micro-framework by Laravel, to have our API separated from the main code.

• Create the mobile app using React Native. We already had some knowledge of React, and it was quite simple to create the app.

• Refactor our Laravel website to fetch the data from the new API repository.

We started to use React components to improve the UI/UX for customers. The React components were fetching the information directly from the API. Eventually, our Laravel controllers were almost empty. They were just rendering the templates passing some basic information to the page.

The company started to grow faster, and we decided to expand the service to new countries. It implied changing our database schema, API, website, and mobile app to support more than one language and currency.

At this point, one of the programmers returned to his country, and we needed to hire at least one more staff.

What we decided to do?

We needed to touch many parts of our website, and It was kind of dangerous because we could affect our current sales.

Also, we started to think about the current problems we had and the ideal shape of our website.

Front

Problem:

• We didn't need Laravel; most of our pages were using React components.

• PHP was an extra an unnecessary layer

Solution:

• We decided to use NextJS, a popular React Framework.

• We used an incremental adoption strategy to start replacing page by page and not all at once.

Backend

Problem:

• We had many endpoints without documentation.

• Some endpoints were duplicated to return to particular pages only the necessary data improving the speed & performance.

• We tried GraphQL with PHP to solve those problems, but it added extra complexity, and some packages did a lot of magic to simplify the things that we didn't like.

Solution:

• Use NodeJS for the backend with Apollo GraphQL. The implementation was more straightforward and flexible than the PHP packages.

Mobile App

Problem:

• We were conformable with the results; mainly, the problem was fetching data from the REST API.

Solution:

• Replacing the REST API with the new GraphQL endpoint.

This is a quick summary of what we decide to do. After we started working on the new version of our website, we noticed some advantages we gained as a team and company.

One programming language

Now our frontend and backend used Javascript; it felt more natural and correct. We were able to share part of our helper functions, validations, etc., between our repositories.

Most of our time was spent on the user interface and less on the backend. GraphQL was a perfect solution to fetch only the necessary fields for each of our pages, and we got for free the schema documentation and field validations.

New programmers could explore the schema using the GraphQL Playground, and with the help of TypeScript and additional packages, we had the GraphQL schema automatically typed, improving our code quality.

• Apollo Server: https://www.apollographql.com/docs/apollo-server/getting-started/

• GraphQL code generator: https://graphql-code-generator.com/

One type of programmer

This simplified the hiring process; now, it was easier to find a good developer at Javascript in the frontend or backend.

At that time, we needed a good front-end developer, so we hired someone with experience mainly in the front-end.

Sharing responsibilities between the team

The majority of our tasks were in the front-end, it felt more natural for the team to collaborate even if someone had more expertise on the backend.

Because the language was the same, we shared our experience and best practice about Front-end and Backend-end. It helped us to grow as developers.

Code review across projects

We shared responsibilities and knowledge doing pair programming.

It also allowed us to do code-review between different repositories and improve the quality of our code. We were a team of 3 at that time, and the 3 of us understood how our frontend and backend work. We could help each other with suggestions and ideas.

Speed of Development

It felt more natural the communication with our back-end using GraphQL and our front-end with React. We extracted our essential UI components to a different repository, and we shared them between our repositories, applying a micro-frontend strategy.

We had our public pages, admin pages, support pages separate but connected using our GraphQL back-end and our components library.

Testing

Testing was one of the most significant benefits because we had to master only one testing framework (Jest). All the experience gained was applied to the rest of our repositories.

We used React testing library for our frontend, and we used Cypress for the End to End testing (E2E).

We also decided to use Typescript in all of our repositories, providing strong typing to our code, helping us catch bugs in advance.

• Typescript: https://www.typescriptlang.org/

• Jest: https://jestjs.io/

• React testing library: https://testing-library.com/

Host Anywhere

NodeJS makes it easy to host your website on any hosting provider, but it's mostly the way to go for serverless solutions.

We didn't have a DevOps specialist, and we wanted to make it simpler for us. We found serverless as a great way to save our time.

Many hosting providers simplifies the deploying process by just connecting your Git repository with their platform.

We decided to use Vercel for hosting all of our apps, and it only cost $20 per team member saving money and time compared with our previous deployment process that also required us to take care of the servers.

• Vercel: https://vercel.com

Final Conclusions

Our team is happy now using this new stack, and I particularly plan to keep using it on future projects.

Most of the points I have mentioned in this article are possible to do with PHP, but they weren't the most simples to do in my experience as a PHP developer.

It wasn't all perfect; we had to learn how to deal with some missing parts because we were using Laravel before that comes with already build-in solutions for translations, validations, ORM, Queue, etc.

I plan to write a different article to explain how we deal with that.