Part-2 of “How paypal engineers turned buggy software into great stable software” product

5 min readApr 8, 2023

Our admin panel is connected to multiple micro backends with one frontend. The problem with that is, if frontend had any bug. It’s just impossible to login into it

The bugs raised from admin are like access role problems, login problem and if any backend is down, the data is unable to fetch in frontend and then frontend used to raise unnecessary errors and used to become screen blank.

For this problem, the solution found by our paypal engineers who hired to our startup. That is…

Every micro backend will have a micro frontend

It means if there are 5 separate micro backends are available, then there should be 5 micro frontends available, All these 5 micro frontends are connected to one global main admin frontend. (Easy to navigate all these micro frontends)

When user logged into this main admin panel then global JWT token will be created and when user clicks any micro frontend then these tokens will pass into that respective frontend to access it.

If you haven’t read part-1, then check below…

How paypal engineers turned buggy software into great stable software

The story is about “Why paypal engineers joined in a startup” and what technical and management decisions took them to…

makedeveasy.medium.com

Revamp of all frontends

Here is an interesting part came into picture. All bad code which are in existing repo, Is rewriting those code again in the new repo(mono-repo)
To avoid bad code in new mono-repo, Developers started writing with typescript instead of javascript, and implemented unit tests, functional test cases for the code.
Also setting up the lint, prettier and builds in new mono-repo. Benefits of these are when any developer want to commit their code. At pre-commit time, lint, prettier and build will automatically ran by husky and docker. Identify the issues and suggest to the developer to resolve those issues.
If any developer didn’t corrected it and pushed bad code, then it will be very serious punished by leadership management.

RWR

RWR (i.e release when ready in devOps) means when anyone raise PR(pull request), For every commit there will be tag section is associated to it (on bitbucket UI).
Developers can pickup the latest commit and add unique text like deploy-<des> for that tag input on bitbucket UI, Then based on text the build pipeline will automatically run to host that UI into unique URL.

BFF Implementation

Every time initially backend team used to give one set of json structure to frontend team and after implemented with frontend.
Again backend team used to alter those JSON structure. Its very pain for the frontend team to change the frontend code according to the backend JSON structure. More bugs used to create these types of alters.
For this solution, we found is BFF i.e Backend for frontend. Its acts an middleware between frontend and backend.
BFF mainly helps, where frontend team wants to have some specific JSON data in one form of JSON structure but backend API it used to have another form of JSON structure with more keys and values.
To filter and remove unnecessary JSON data and to change the format of that JSON structure. To makes these happen from backend api in structured way. BFF will comes into place, where we can pass filtered JSON data from backend and simply pass to the frontend template.

Still confused need to know more watch this video about BFF👇

After implemented BFF, Frontend team used to prepare the templates with their own set of mock JSON data without relying on backend team.
Later backend team provides real DB API JSON data, then frontend team used to replace the mock JSON data in BFF with real JSON data by calling backend APIs in BFF.
So that frontend team used to have full control on JSON data and its structure to show on UI.

Tech forum Meetings

If anyone introduce any new implementation like BFF etc into the frontend. then we used to have tech forum meeting at once a week.
During these meeting, Developers used to discuss all these these type of new implementations to makesure aware everyone. so that other can easily implement for their respective development.

Replacing videos/graphics/animation with threeJS 3D models

Problem with inserting heavy assets like videos & graphics in frontend UI is — they used to take more MB bytes of storage and used to lack the frontend UI performance.
To avoid these types of issues. Introduced threeJS, Instead of attaching video files in frontend. we used to replicate same video elements, graphics and animations in threeJS.
Advantage with threeJS is it takes KB bytes of less storage and used to improve frontend UI in terms of look, performance a lot.

More info check —

Three.js - JavaScript 3D library

threejs.org

Frontend Asset Optimization

On frontend template UI, we used to import lot of icons and images to make more UI visualise. But the problem with that is, these icons and images we need to call one by one to show on UI. Instead we can call all these assets in parallel at once, By implementing the HTTP2 or sprites.

Main purpose is they used to stream all these assets like icons and images in parallel at once, instead of calling one by one.

CMS Implementation

Content from these template used to comes from CMS like strapi

Main benefit with CMS —

We can manage the content without interfering the developers on UI.
We can send multiple languages content into frontend template easily.
We can show the content on frontend UI based on the personalize user preferences.
For example- We have creators, users in our platform to create or watch videos.

If creator lands on our frontend website, It shows the data related creator —

a. How much creators can earn and other ways they can enable their monetisation in our platform

b. Its also shows about how many creators are there in our platform

If user lands on our frontend website, It show the data related user —

a. Latest and upcoming features released in our platform

b. Types of content you can watch in our platform.

Best part with CMS which we implemented is —

If any case CMS is down then we used to serve the data from backup folder to the UI.
Backup folder usually creates every manual build of CMS, i.e If we build the CMS once, the whole CMS data will store into backup folder.
So if case, CMS can’t serve data to the UI. Then data will serve from backup folder.

I hope you enjoyed. Stay tuned for part 3…