<![CDATA[Technology at upGrad - Medium]]> https://engineering.upgrad.com?source=rss----c08812b771e6---4 https://cdn-images-1.medium.com/proxy/1*TGH72Nnw24QL3iV9IOm4VA.png Technology at upGrad - Medium https://engineering.upgrad.com?source=rss----c08812b771e6---4 Medium Tue, 14 Apr 2026 09:34:34 GMT <![CDATA[Web Performance and Related Stories — upgrad.com]]> https://engineering.upgrad.com/web-performance-and-related-stories-upgrad-com-a9fb9c6bb766?source=rss----c08812b771e6---4 https://medium.com/p/a9fb9c6bb766 Fri, 11 Jun 2021 06:37:45 GMT 2021-06-15T16:46:26.837Z Web Performance and Related Stories — upgrad.com

The story and learnings from improving upgrad.com’s (a Nuxt.js SSR application) Lighthouse performance scores from 17 to 65

In the month of January 2021 we, at upGrad, looked at our website’s page speed scores and accepted the fact that they demanded considerable improvement. Lighthouse is a popular and extremely useful tool to measure web performance, and well, the scores for upgrad.com were barely crossing two-digit values. The situation wasn’t great, but personally it was exciting for me because it presented a live problem to be solved, and this post is about the journey through the rough seas of web performance.

tl;dr
We were successful in improving our website performance in terms of the Lighthouse scores going from about 5 and 15 to around 50 and 70 on mobile and desktop respectively. I hope these numbers will encourage you to read the entire post, but I’ll also try to make it interesting in general to read. See you until the end!

I consider this domain of web-development to carry a large importance for both — the developer working on the website/application, and the business/person owning the product. The situation’s better when you play both of these roles, let’s say when you launch your side project. Web performance is an area which is interesting to work on as a tech person, as well as has direct impact on the business side of things. If you’ve run your Lighthouse tests quite often (it is time to automate them), you might have seen these facts being shown.

Speed does matter. As users of the internet ourselves, we know how frustrating it is to wait for a page to load. I sometimes empathize web developers of certain websites if they load slowly, and wait for a few more seconds. Unfortunately, real world users won’t do that. As everything is becoming more and more instant, giving the best experience on the web is one of the core responsibilities of a web developer.

The January of 2021

I do not want to sound poetic, but let’s go back to the January of 2021. The growth team at upGrad had worked on a crucial project this month — the separation of authentication logic from the website, and integrating a mobile OTP-based login+signup flow. It was an interesting project and Akshay (my teammate) is soon coming up with an article about it. But given that, now the upgrad.com website consisted only of representational content. In an ideal world, the website could have been built with plain HTML & CSS, but having a framework like Nuxt.js gives us a lot of benefits in terms of operability and dynamism, given that we have an in-house CMS and editors.

Anyway, the Lighthouse scores for the website were as follows (for desktop):

A 17 for desktop usually means your mobile scores sit somewhere lower, around 8–10. Things to note in the above screenshot are the values for the web vitals, most of them in red. Lighthouse considers these values to be important denoting factors about how your website loads and how it is perceived by the users. Let’s take a short detour into how a browser loads a page, the web vitals then would be much clearer on the way.

Journey of a page

Source: https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

A browser usually goes through the above flow whenever it receives its first chunk of HTML from the server. HTML is a special language, it is forgiving. And hence its parsing is special too. To go a bit into details, HTML does not have a Context-Free Grammar, as most of the languages would have. This grammar tells what is valid and what is invalid in a language. In HTML, the browser usually corrects if some parts are erroneous. In addition to this, HTML can change while parsing is still happening! JavaScript can inject HTML into the page using document.write() and because of this HTML parsing is called re-entrant.

If we consider a short example page’s HTML

Scenario 1

<html>
    <body>
        <h1>Hello</h1>
    </body>
</html>

Here, the parser will start from the top and go on identifying corresponding nodes. It will find open html -> open body -> open h1 -> text Hello -> close h1 -> close body -> close html. At the end of the parsing you’d generally have a syntax tree which will mirror a corresponding DOM tree. The object would be the one which will be exposed to JavaScript inside document.

Essentially, the DOM tree would be constructed, laying out would be done and then the bitmap would be painted on the screen. Super optimal.

Scenario 2

<html>
    <head>
        <link rel="stylesheet" href="/main.css" />
    </head>
    <body>
        <h1>Hello</h1>
    </body>
</html>

Let’s consider this example which adds a remote CSS stylesheet to the page. Any form of CSS on the page is render-blocking. It means that until all the CSS isn’t parsed, the renderer won’t paint the page — remember from the above flow diagram that the render tree construction requires the CSS tree to be ready.

Hence in this example, the DOM tree would be constructed, but the rendering would not happen until the CSS file is loaded and parsed completely. A bit less optimal.

Scenario 3

<html>
    <head>
        <link rel="stylesheet" href="/main.css" />
        <script>console.log('Hello from JavaScript!');</script
    </head>
    <body>
        <h1>Hello</h1>
    </body>
</html>

Let’s add a <script> tag to the head. Any form of JavaScript on the page is usually parser-blocking. The HTML parsing is blocked until the script is executed — this is again because JS has the potential to modify the DOM, so the browser wouldn’t want to proceed and later get to know that the code it had parsed was stale. You can think how this might get affected if you have remote JavaScript files, which is usually the case. The files would first have to be downloaded and then executed for the parser to move ahead. Very un-optimal.

Mozilla Developer Network documentation as well as Google’s web.dev articles explain this in great detail. You might want to look into those.

The crux of the detour above was to discuss what could potentially hinder our website from being loaded/visible to the users. From the discussion we can take two key points:

  • CSS is render-blocking
  • JavaScript is parser-blocking

These two points form a base to a large number of optimizations that one can perform to speed up their website. The core web vitals also get affected due to these.

Sourced directly from https://web.dev:

Anything render-blocking will worsen LCP. Anything process heavy on page load will worsen FID, e.g. synchronous JavaScript execution on main thread. Anything writing to the document and hence drastically changing the page layout will worsen CLS.

For the initial phases our target was reducing LCP. Additional reading:

Overview | Web Fundamentals | Google Developers

Identifying Areas of Improvement & Budgets

To tackle the problem of performance, usually one can look internally first (quite philosophical). Before performing a complex change in your system, one must try to find areas to improve in the existing setup. It is quite probable that there would be a lot to clean up and optimize. At least that was the case with us.

But before beginning any work, how would you know what to pick and how that change would impact the performance? Enter performance analysis tools. There are numerous tools available online that help you know exactly where the bottleneck is. Lighthouse is one of such tools but I believe it should be used to benchmark the final score. There is another online tool called WebPageTest that gives you detailed report of your website’s performance under various scenarios. I personally found is very useful to identify individual problems.

Following is a screenshot from webpagetest.org:

The above report gives a detailed view of what is happening on the page — from the vitals to the waterfall view and the vitals marked on it. It was particularly helpful to map what was delaying certain metrics and then target those resources specifically.

Budgeting

This is a debatable topic but everyone can have their own preferred ways of budgeting your optimizations. This helps us maintain a threshold for either metrics or the experience that we want to provide to our users. I’ll keep this section short and link to useful resources online:

We began with some obvious areas that we could target — something that we knew already but could not find time to fix. These included some unused scripts and some modules that were being loaded globally when we could load them locally. In Nuxt, you can define global plugins that get included in the main bundle — often a bad practice if not monitored properly. So in short, here are a few key areas that can be targeted:

Lazy-load Everything Unnecessary

Impact — Time To Interactive (TTI), First Contentful Paint (FCP)

You must defer/lazily-load everything that is not crucial for your first load and does not contribute to SEO. This includes modals, non-critical scripts, images, stylesheets and chunks of your application.

For our website, we saw a considerable difference when we lazy-loaded all our modal content. Since it was a separated module in itself, we could do this easily. Most of the frameworks have special syntax for lazy-loading components, e.g. React.lazy() in React and the import() syntax in Vue. Bundlers provide automatic code-splitting based on this syntax so that your chunks are separate and are only loaded when requested for.

Since Nuxt uses webpack, we could use webpack’s magic comments that allow you to define loading behaviours on chunks. /* webpackPrefetch: true */ is one such useful comment that pre-fetches the chunk so that the experience is similar to loading it synchronously.

Image lazy-loading is core to faster websites and usually is already implemented. But if it isn’t then you should do it right away. There are popular libraries that allow this and now there’s also a native way of doing it in HTML, though it isn’t supported in all browsers.

The standard way of telling the browsers to defer loading a script, or load them asynchronously is by using the defer and async keywords correctly. defer moves the processing of a script to the end of parsing step. The script is fetched in the background and in parallel if many. This solves the issue mentioned in ‘Scenario 3’ above. That is also why usually it is recommended to keep your script tags at the end of the body. This helps in two ways — it allows the script to ‘see’ the entire body of the page at it was built before the parser reached the script tag, and second that the parses did not get blocked on the script somewhere at the beginning of the page.

async helps in a similar way but instead of loading the scripts in the end, they are loaded and even processed asynchronously. These won’t wait for the DOM tree being built, but get executed as soon as they complete loading. A key difference between async and defer is that all scripts loaded with defer will block the DOMContentLoaded event while those loaded with async would not.

Another useful thing that can be leveraged off of frameworks is the dynamic loading of scripts. Keeping the core idea in mind — load only those resources that are required to build the page — we can dynamically push <script> tags in our website’s head. This allows, e.g. loading the YouTube player script only on pages that actually display a video, ensuring that does not slow down a page that does not have a video at all.

Limit Critical Resources — Shorten the Critical Rendering Path

Impact — First Contentful Paint (FCP), Largest Contentful Paint (LCP)

Critical rendering path (CRP) is the journey of a page being rendered in a browser from the point when the browser receives the first bytes of the response (HTML) to when the page starts becoming visible. Our aim should be to keep this as short as possible. As resources get added to this path, the time to start painting goes on increasing, hampering the page load experience.

CRP depends on the way your HTML document is parsed. If it is only static HTML, you would have a great LCP score. But practically, there are a lot of resources that usually get added on a HTML page, that are at times crucial for the website to behave properly. If these resources are required for your page to render, then they contribute to CRP. The parser has to do the work of loading and executing them and then continue to parse the page and then finally the renderer to take over.

Good resources:

Critical Rendering Path | Web Fundamentals | Google Developers

For us, it was about looking at the waterfall snapshot from webpagetest and see what was delaying the first render. Upon checking, we could find that a particular CSS file was being loaded critically and to worsen the problem, it wasn’t being served via a CDN.

Finding such resources and unblocking them helped us improve our start render times by a good number — old one being at 4.2 seconds, improved to 0.4 seconds.

The initial HTML response of your page must contain only the critical CSS — CSS required for your page to be properly styled. All others can be lazily loaded. One popular way to asynchronously load CSS is using the media attribute of link tag.

<link
    rel="stylesheet"
    href="/link/to/file.css"
    media="print"
    onload='this.media="all",this.onload=null'
/>

Here, since the media value is ‘print’, the HTML parser in a browser would skip waiting on this stylesheet and move ahead. The stylesheet will still load in the background, and whenever it does, it will get parsed. This prevents blocking of the parser at the CSS link tag and is good for stylesheets that aren’t required at the time of first load.

Even with the above solution, we must ensure that the critical CSS is lean. Tools like PurgeCSS help in automating this by cleaning out the styles that are unused on the page by going over the HTML of the finally generated page.

Preloading Critical Assets

Impact — Largest Contentful Paint (LCP)

One other important practice is to preload all your critical resources. If your website has an image in the first fold, you must preload it so that it is visually available as soon as possible.

One can use the preload keyword to do this and many bundlers do this automatically for you.

<link rel="preload" as="image" href="banner-image.webp" />

More on preload here:

Link types: preload - HTML: HyperText Markup Language | MDN

Applying these practices brought down our LCP largely — from 3.9 seconds to 0.9 seconds.

Google’s web.dev sums up the above points in a very good way — it introduces the PRPL pattern.

  • P — Push (or preload) the most important resources.
  • R — Render the initial route as soon as possible.
  • P — Pre-cache remaining assets.
  • L — Lazy load other routes and non-critical assets.

Apart from pre-caching, I think I talked about the rest of the points. Pre-caching helps in improving the performance of the subsequent loads by caching assets that have a higher time-to-live.

Overall Improvements in upgrad.com’s Performance

Since the website runs on a server-side rendered Nuxt, it poses some special conditions to approach performance. Any SSR framework, accompanied with a CDN cache, guarantees a great TTFB and LCP, but suffers in time to interactivity as there’s a re-hydration process that happens on the front-end.

A short description of how SSR works in Nuxt (from nuxtjs.org):

Server-side rendering (SSR), is the ability of an application to contribute by displaying the web-page on the server instead of rendering it in the browser. Server-side sends a fully rendered page to the client; the client’s JavaScript bundle takes over which then allows the Vue.js app to hydrate.

Server Side Rendering

Considering this, we only targeted the rendering and preloading bit of the entire process. We have plans to move to complete static rendering in the future which should solve the problem of hydration.

Anyway, we did this exercise over a period of 4 months, and occasionally worked on performance specific tasks. I believe most of the work in this field has to be slow and steady. There’s a fair amount of trial and error, research and reading required when you begin. But consistent efforts towards improving and then maintaining performance do pay off well. This is how the LCP (in a desktop setup) improvement for us looked over time:

Our Lighthouse scores went up as well, as mentioned in the beginning of the article. Current score:

I have thoroughly enjoyed working on this and have learnt quite a lot about how pages get rendered and how to make them fast. We are targetting to a even better score as there is still a room for improvement, but honestly the current score is a good one to take a break and look back at it with a fresh mind. As next steps, this is what we are looking at:

  1. Performance Benchmarking — We’ve improved the scores, but it’s our job now to maintain them there. Continuous monitoring is a crucial part of maintaining performance. There are tools available out there, or you can easily make one on your own (I did that :P, will link it later).
  2. Performance-optimised components — We’re looking towards replacing certain shared UI components with lighter-weight alternatives.
  3. Brotli Compression & Infra-level changes — Brotli is enabled but needs some improvement in terms of the implementation. Also, infra-wise we look to reduce the number of hops required before reaching our origin server.

This entire feat wouldn’t have been possible without my cooperative team, my manager Maitrey and Rohan. Me, Rohan and Maitrey have had numerous meetings to discuss this and have always worked towards building a performant and efficient platform. Things have worked like magic! Also, kudos to product leaders — Rohit & Shahir, to look at this as a direct business impact (and constantly pinging us about the website being slow :D). And finally, thanks to engineering leaders Vishal and Puneet for constantly supporting this entire exercise.

I’ve already linked relevant resources as and when required, but for all others, here’s a collated list:

This story was originally published on my personal blog. You can find my other writings there as well.

Web Performance and Related Stories - upgrad.com

Do you have any similar experience, or a suggestion? I’d love to discuss! You can reach out to me on email, or Twitter, or comment below. Do visit upGrad.com to check out our programs that are completely online! If you wish to work with our ever-enthusiastic team, check out our careers page. We are always on the lookout for ambitious, talented folks!

upGrad Careers

Web Performance and Related Stories — upgrad.com was originally published in Technology at upGrad on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[upGrad’s Virtual Hackathon — 2020]]> https://engineering.upgrad.com/upgrads-virtual-hackathon-2020-182ef579fc96?source=rss----c08812b771e6---4 https://medium.com/p/182ef579fc96 Thu, 29 Apr 2021 06:07:08 GMT 2021-06-11T09:52:45.306Z upGrad’s Virtual Hackathon — 2020

An Event Where Innovations Came to Life!

Over a year of being struck by the worldwide pandemic and the resulting work from home situation, we have realised the importance of constant communication and working together to solve real-world challenges. We are now accustomed to remote working and are coordinating and creating solely on virtual platforms. Hackathons are the events where the unthinkable is achieved, and innovations are born. They also encourage us to put our brains to work and develop something that can solve genuine challenges. Hackathons are also hubs for networking. This year’s hackathon was a bit different at upGrad — with everyone working remotely, it was a challenging feat by the organizing committee to bring everyone together, online, and execute each step of the event with perfection.

We conducted a 36-hour long virtual hackathon in December 2020. It was upGrad’s first-of-its-kind remote event that was a massive success.

Pre-event Excitement

It all started with the organizing committee floating out forms to accept the innovative ideas a few weeks before the hackathon. We received over 60 interesting ideas, out of which a total of 15 ideas were selected on the hackathon day. The 15 selected ideas were pitched, and the final voting was conducted, out of which the top 8 ideas were selected. The participants who had pitched the selected ideas were declared as captains of the teams.

The Hack Begins

The teams were formed, and they rigorously worked to develop the solutions pitched earlier. Team formation was one of the most fun and essential parts of the whole hackathon. An IPL-style auction was held for team formation where captains placed bids for people to include them in their team. Separate rooms were set up for each team to chat and brainstorm on their solution.

To create a synonymous environment as that of an office, the teams had 15–20 minute chai breaks between work. We would meet up in an open meeting link and chat about random things. Regular checkpoints were organized for the captains to connect and share their progress and concerns. One checkpoint was at the beginning of the day, and the next was at the end of the day. The teams were developing their products at a rapid pace, and many of them completed their MVPs. True enough, hackathons are the fastest way to bring ideas to life.

Stills from the Hackathon Zoom Call

The teams continuously worked hard from research to building an MVP of their solutions. The best thing was that even after the hackathon being a competition, all the teams were helping out each other and networking. A team plays an indispensable role in developing an idea to reality. It was astonishing how teams consisting of participants from different competencies came together and built solutions to solve real-world challenges.

The teams very well leveraged each other’s strengths. They identified their problem statements, developers, designers, and business minds worked out to develop the perfect solution. The outcomes were indeed impressive.

The Final Demo

It all boiled down to the 5-minute presentation of the final day. After 36 hours of non-stop development and fun, at 5 PM on day 2, the captains presented their final MVPs before the judging panel in innovative ways. A quick question–answer round was held after each presentation for judges to understand more about the ideas and clarify their doubts. Out of 8 teams, five winners were chosen instead of three. There was a tie between the 2nd and 3rd positions. The judges were highly impressed. They appreciated their hard work and gave constructive feedback to the teams.

Stills from the Final Demo Call

The Judges and Judgement Criteria

The hackathon was judged by genius minds Rohit Dhar, President — Products at upGrad, and Puneet Tanwar, President — Technology at upGrad.

Rohit leads the entire Product, Data Science, Analytics, and Design teams. With his vast experience, he was able to critically analyze the innovative products developed by the teams.

Puneet, who leads the technology vertical at upGrad, has over 20 years of software development expertise. With his expertise in software and experience in leadership, he analysed the technical and practical feasibility of the MVPs and ideas.

The judgment was made on five parameters, including clarity of vision and roadmap of further development, user experience and ease, the complexity of implementation, completeness of the MVP, and the overall presentation.

The hackathon was a fun-filled, exciting event for the entire product and technology team at upGrad. The annual hackathon provided the team a platform to make their ideas a reality, experiment, and innovate in the field of ed-tech which is a promising domain right now. Even after the hackathon fatigue, the participants were still full of adrenaline and discussed ideas and further development.

Over the last year, upGrad has increased its team size and is looking forward to expanding even more. upGrad believes that online learning can transform one’s career. Online education is especially advantageous to those who don’t have access to in-person formal education. upGrad is bridging the gap and empowering individuals to learn affordably and from wherever they are.

Interested in working at upGrad?

By working with upGrad, you support thousands of dedicated learners who empower themselves with education and make progress in their careers. At upGrad, you change lives and contribute to the bigger mission of transforming thousands of students and working professionals’ careers. At upGrad, you learn and grow. This hackathon is only one out of the several tech and informal events we organize. Follow this blog to get future updates about technology and culture at upGrad.

If you are aspiring to be a part of our team, visit our careers page:

upGrad Careers

upGrad’s Virtual Hackathon — 2020 was originally published in Technology at upGrad on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Revamping the Job Search Experience on Career Centre]]> https://engineering.upgrad.com/revamping-the-job-search-experience-on-career-centre-8c4797c0df45?source=rss----c08812b771e6---4 https://medium.com/p/8c4797c0df45 Tue, 06 Apr 2021 10:10:17 GMT 2021-04-06T10:10:17.508Z How we rapidly built and shipped Career Centre’s brand new mobile-friendly job search experience

A frontend developer’s mildly terrifying nightmare is hearing “yes” to the daunting question of “Are we releasing this for the mobile web”? You first wonder how that’s going to impact estimates.. then the testing.. font sizes.. performance.. Your head starts to spin as you suddenly notice how your vision is blacking out..

A few developers working on the Career Centre at upGrad had a comparable incident some time back. We were tasked with bringing the slick, revamped jobs experience to the mobile web.

mWeb — why it’s not dead.

Across the internet, conversion for prompts to install a native app convert less than 4% of the time. Allowing a native app real estate in what is your most personal gadget, is still seen as a long term commitment — you need to first hook the user and then incentivise them to to install it. So unless your app does something that is not technically feasible on a mobile browser, addresses a high frequency use case or needs heightened security — your key focus should still be on mobile first web-apps!

mWeb also allows us to bring key features to users much quicker than native apps! It’s an easier platform to A/B test our features on and we routinely use mWeb to gather important insights into user behaviour or to gauge the success of a feature before introducing it to the native apps.

With increasingly larger strides in how mobile browsers are tapping into processing power and how new frontend technologies promise an app-like experience, modernising our jobs experience on mobile was a no-brainer.

The old vs the new job experience

The technical challenges

The Career Centre is built on Vue.JS, which happens to have a rich ecosystem of libraries. We went into the jobs project knowing that going forward, we should be targeting the entirety of the Career Centre to be served through a cohesive, responsive web experience.

UI library

We needed a scalable and flexible component library that could accommodate upGrad’s growing design system — Hygge. Our top priority when choosing the ideal library was customisability, performance and community support. After deep-diving into the availability of event hooks, template slots and general stylability, we narrowed down on Vuetify and Quasar.

These libraries had very similar underlying philosophies and component coverage. With that in mind, we tried out a real-world PoC showdown, trying to implement the screens provided by design in two very real-world tests. After pitting the two against a selected set of metrics which included ease of development, production package sizes, responsive design coverage and more, we narrowed down on Quasar!

Another “first” we tried out for this release is using theme-neutral components and iteratively evolving it to make it our own. This allows us to bring the product to the users much quicker, evolve our component libraries and setup the processes to share it between teams, while also making sure that other teams can shift to the new design system.

Why a UI library?

UI libraries allow rapid development of consistently styled UI components, that can be later shared across teams. Besides being responsive, these components are built to be compatible across browsers, while allowing developers to not worry about accessibility. Components also unify the way we feed and store data going to and from the components.

The immediately visible caveat is that the initial learning curve is a bit steep, but that time lost is easily made up in the additional time it takes to QA any custom UI component. Diving a bit deeper, there might be one possible argument against component libraries in the fact that a custom UI library would be leaner alternative to bloated and overly customised off-the-shelf components. While this concern is valid, in the real world, we were able to customise components globally to fit our design needs with a couple dozen or so lines of CSS.

After narrowing our list down to just 2 libraries, we chose Quasar over Vuetify and here’s how we evaluated it objectively.

Vue 3 support

Vue 3 brings with it some major features centered around performance and we definitely do not want to miss out. While both Vuetify and Quasar have a detailed roadmap to support vue3, we felt that the jump would be marginally easier to make with Quasar, since it promises reverse compatibility. That said, we really did like how Vuetify has a highly organised roadmap on Notion.

Emphasis on Security

When you first look at the sections on Quasar’s page, what really stands out is the security tab! It consists of a surprisingly exhaustive set of security DO’s, DONT’s and limitations for each of the most commonly vulnerable components. To top it off, a few components come with in-built sanitisation that are really handy!

Core Philosophy

Quasar, before it was officially released, started off as a mobile first framework that focussed primarily on building hybrid and electron apps. Then as it expanded to include desktop web-apps, it gained traction soon.

Dev Experience

Documentation and ease of use

When developing large scale web experiences, the documentation aspect of any library plays a huge role in shipping quality code on time. At first glance, Vuetify’s well presented documentation, coupled with a relatively lower barrier for entry made it a clear favourite. However, once we started delving into the more complex use cases, Quasar really started to shine.

Styling

The component styling are equally easy in both the libraries. Quasar has a custom class with a —inner prefix that can be used as a hook to create custom styles. It also has modifiers to changer styles based on element states. (This is especially useful in cases like the one illustrated below where the input element is much lower down the DOM tree than the element controlling the style)

Flexibility

The core component coverage of both the libraries is quite identical. However, Quasar has a slight edge in the extended components (stepper, timeline, etc). So then we started to analyze the number of customizable props and slots, etc for all of the core components, we found Quasar to be significantly more customizable than Vuetify.

The flexibility of the component library was very important to us since it’d enable us to write code and test faster, and bring the feature to production sooner. Moreover, if all the Vue repos at upGrad to shift to a single library, it would be easier to share off-the-shelf components bundled with the settings, rather than a custom written component with deeply-linked dependencies.

Let’s have a look how we assessed flexibility -

When we first had a look at the search bar’s functionality, it seemed like we’d have to build a component from scratch to account for the unique use cases.

The search bar has 3 states — recent searches, search suggestions and custom search. While the recent searches is straightforward to implement, the latter 2 cases operate on all the tags present in the search bar as well as the untagged input.

The closest components that resemble the functionality of the searchbar in Vuetify and Quasar are the v-combobox and q-select, respectively. Looking at the APIs for v-combobox, there’s no built-in way to access the the untagged input value.

The example below gives an idea of how easy it would be to customise the behaviour of a component to suite a complex use case.

Typescript

Another aspect of the release was a shift towards TypeScript. The immediate advantages are IDE autocomplete and static type checking. The well defined types makes it easier for newer developers to understand code (this is especially useful when sharing components between teams). The biggest tradeoff for us was an increased learning curve. In the longer term, we were expecting slight dips in productivity.

The Release

We split the releases into two, one for desktop and a subsequent one for mobile-web. We started by laying out the foundations for responsiveness in the desktop release. However, we used a conditional flag to hide the mobile version in production. The second release that brought mobile responsiveness was written in a mindful way that made sure that the previously tested code was mostly untouched

Once the desktop release went live, we quickly got back to work (after a quick break to celebrate, of course 🍻). We re-looked at key factors like interactions, touch targets and spacing using a mobile-first lens and after using BrowserStack to do extensive dev-testing, handed it over to QA.

Future scope

We have a series of features that would improve the general ease of use for our learners who are accessing the Career Centre on mobile. We’re focusing on improving the page speed performance and bringing more of the desktop functionality to mobile. Going full-PWA is next up on our list of TODO’s. PWAs will open the doors for background processing and push notifications, and that will take us a step forward in bringing a world-class learning experience to everyone.

Do visit upGrad.com to check out our programs that are completely online! If you wish to work with our ever-enthusiastic team, check out our careers page. We are always on the lookout for ambitious, talented folks!

upGrad Careers

Contributors: Adarsh Sosale

Revamping the Job Search Experience on Career Centre was originally published in Technology at upGrad on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Taking upGrad.com International]]> https://engineering.upgrad.com/taking-upgrad-com-international-bf0e6e328295?source=rss----c08812b771e6---4 https://medium.com/p/bf0e6e328295 Tue, 02 Mar 2021 18:49:45 GMT 2021-03-03T04:50:55.947Z

A few months back, upGrad decided to expand into international markets and thus came the need to support this expansion within the various client-facing technology products. The first one that required a substantial change was the course listing website — upgrad.com. In this post I talk about how we approached and implemented this, and the things we learnt on the way.

For the first phase of internationalization, the expectation from the platform was that the internal teams should be able to market upGrad’s courses independently in different countries, i.e. the content displayed in each country could be different and it should be possible to maintain it separately. In addition to this, visitors should be auto-redirected to their country-specific URLs when they try opening any page on the upgrad.com website. This is a general behavior across many websites where content is distinguished using certain codes that are appended to the base URL.

An additional requirement that might not seem obvious is maintaining this appended code throughout the visitor session. If someone lands on upgrad.com/us, then all the subsequent routing should be handled keeping the initial location code in context. E.g. if the viewer clicks on a hyperlink or a button that causes routing to /data-science-pgd-iiitb, then the resultant URL should be upgrad.com/us/data-science-pgd-iiitb.

So in all, we had three problems to solve:

  1. Enable saving location-specific pages in DB and allow respective editing
  2. Handle client-side routing
  3. Auto-redirect to these specific pages according to user location

Updating CMS to handle international pages

We have an in-house content management system (CMS), named Apollo, to manage content on upgrad.com. ‘Pages’ can be described as documents in a database mapped to a unique slug. Previously, it was only possible to have single-level slugs which directly mapped to the URLs on upgrad.com. E.g. data-science-pgd-iiitb mapped to upgrad.com/data-science-pgd-iiitb. To allow pages to have a two-level URL like upgrad.com/us/data-science-pgd-iiitb, we introduced a new property in the page document called i18n. This is an object which holds the value for locale which is a unique two-digit code assigned to each country. Locales are good textual identifiers for countries and can be directly mapped to URLs.

While creating pages, editors could specify which country page they wished to create and the value would get attached to the page document once created. We broke the previously used slug identifier for the page into two parts viz. name and i18n.locale.

// Old
{
  "slug": "data-science-pgd-iiitb",
  ...
}
// New
{
  "slug": "us/data-science-pgd-iiitb",
  "name": "data-science-pgd-iiitb",
  "i18n": {
    "locale": "us"
  }
}

The name property would contain the more logical value of the program for which the page belonged to. This could be used to later group all pages falling under the same name. As mentioned in the above snippet, the slug property now included the complete URL that the document would signify, i.e. if requested for the United States page for /data-science-pgd-iiitb, I can expect that I’d get data from the above document. Yet, the page data loading logic isn’t so straight forward, I’ll talk about it ahead.

You might question here why we are maintaining duplicate information in name, slug, and i18n.locale. The answer would be simple — to simplify various fetching scenarios. During this project, we wanted to keep breaking changes as minimum as possible and provide fallback mechanisms wherever possible. The CMS, which we call Apollo internally, was previously only being used by the web clients. But after the introduction of upGrad’s mobile applications, it was extended to Android and iOS mobile clients. Hence, keeping CMS API endpoints and response schema unchanged was of utmost importance.

Fallback Mechanisms

To be able to reach as many locations as possible and simultaneously to keep a low data footprint, international marketing pages followed a region-wise fallback mechanism. If thought in a straight-forward manner, creating a page for each country per program would mean an m * n rise in our data. This would also mean that content maintainers would have to update several pages in order to make changes across all country pages of a specific program. This wasn’t a happy scenario.

To solve this problem the idea was to maintain a minimum number of international pages and serve relevant content from these handful pages to all locations worldwide. This meant that we would have to maintain only a few pages and could update which page had to be served for a particular location on the fly.

Generalizing this, we introduced a configuration object in our APIs. This was a JSON structure which held region wise grouping of locations. The logic was simple, the values at the leaf nodes of this tree denoted individual countries/locations which could potentially have a page associated with them. If they did not, the page fetching API would go up one level and try to fetch a page linked with that locale recursively.

For e.g. if the client requested a page for locale=ae, we would check if ae page existed, if not then check if asia page existed, again if not then return the global page for the requested entity.

// Configuration
{
  "global": {
    "asia": {
      "sg": {},
      "ae": {}
    },
    "europe": {
      "gb": {}
    }
  }
}
Fallback regions. Indian pages still run independently, global pages have fallback defined.

Introducing this allowed us to associate countries to specific regions so that we could serve the region data in every country which fell under it. To avoid making this configuration huge, we ensured on our level that a global page variant existed for every page. This ensured that if a page was requested for a country that did not exist in our configuration, it would always fall back to the global page.

The page endpoint now accepted a locale parameter through which the clients could specify which country page was required. This primarily covered most of the compatibility issues, mostly with gradually updating mobile clients, as the endpoints remained the same, and even if no locale query parameter was sent, the API assumed that it was in (India) by default, which was the case before internationalization.

Handling client-side routing

We use Nuxt in the universal mode to serve our marketing pages. Fortunately, Nuxt (and the Vue community in general) has a set of official modules for popular use cases, including internationalization. Thanks to the nuxt/i18n module, a lot of our work was simplified. This provided auto-generation of static routes on startup, client-side routing and also provided various ways to configure them.

nuxt-community/i18n-module

At a lot of places, we were redirecting users to URLs in or outside the app. With i18n, this had to be pushed through a transformer function that attached the current locale value to the new URL. nuxt/i18n exposes a function called localePath for this. We found this to be a good opportunity to clean up our existing redirection logic and bring it to a single place by writing a wrapper function to redirect to URLs that internally optionally used localePath if the URL was an internal one.

When the app boots up, nuxt/i18n saves the data related to the current locale from the URL. E.g. upgrad.com/us/data-science-pgd-iiitb sets a value of locale us to the store, with other related information. Using this, the Nuxt app fires a call to the CMS API with the locale query parameter equal to the one set by the module. Post this, the API takes care of returning the exact matching data or applies some fallback mechanism to retrieve the nearest matching one. Once the data is returned, the Nuxt app renders according to the layouts specified in the data.

Auto-redirection to country-specific URLs

This was the most aesthetic feature of the entire project. No matter how much DB and API changes were made behind the scenes, one would look at the URL magically changing to their location code and be amazed. But we as developers knew how much effort went into making this possible along with ensuring that the rest of the platform worked fine as before.

Our existing marketing website is served via CloudFront to achieve low latency by enabling edge-caching. We decided to leverage this setup to add an extra step of routing to the location URLs. Just to restate the problem at hand:

When a viewer opens upgrad.com/data-science-pgd-iiitb from, say, the United States, the request should be redirected to upgrad.com/us/data-science-pgd-iiitb.

This was a perfect use case for on-demand executing functions — AWS Lambda. AWS Lambda has a CloudFront variant called Lambda@Edge, which creates copies of a function and deploys them across the CloudFront distribution network. This can then be configured to execute on certain triggers.

Various triggers available for Lambda@Edge. Source.

As mentioned in the diagram above, we placed the Lambda function on the origin request trigger. This event fires when CloudFront requests content from the origin server — the function sits between CloudFront and the origin. It is Lambda’s duty to create a redirection or pass on the URL to the origin server. To detect user location, CloudFront’s country headers came in handy. In addition to this, we also used our internal location resolving API powered by MaxMind’s IP database.

To access CloudFront’s country headers, they are required to be added to the whitelisted headers in the behavior configuration. You can find it by the name CloudFront-Viewer-Country .

The Lambda function, implemented in Node.js, roughly looks as follows:

exports.handler = async (event, context, callback) => {
  let request = event.Records[0].cf.request;
  const uri = request.uri;
  const querystring = request.querystring;
  const countryCode = request.headers['cloudfront-viewer-country'][0].value;
  // Skip some URLs which you might not want to redirect
  if(shouldSkipRedirection(uri)) return callback(null, request);
  
  // Resolve location from headers or IP
  let { locale } = await resolveLocation(countryCode, request.clientIp);
  
  // Create a 302 redirect
  let response = {
    status: 302,
    statusDescription: 'Found',
    headers: {
      location: [{
        key: 'Location',
        value: '/' + locale + uri + (querystring ? `?${querystring}` : '')
      }]
    }
  }
  return callback(null, response);
}

Once this Lambda was published over to the edge locations, origin requests started to flow through the lambda function and users viewing the website from locations worldwide saw different content. This was the last step (first in the user journey) in the entire flow and if we retract one point at a time, all things fall into place.

The flow of a request feat. Lambda@Edge

When a user opens the upgrad.com website from the US, the lambda detects the location and assigns locale value of us, and redirects to /us before hitting the origin server — the Nuxt app. The nuxt/i18n module takes over and sets the locale value as us in the Nuxt context which leads to an API being fired with the respective query parameter attached. The API server tries looking for the US page in the database and returns the nearest matching document to the client. On receiving this data, the client successfully renders the page and returns it back to CloudFront. It then returns this result back to the viewer and also caches it against the original request URL as well as the redirected URL. And that’s all folks!

Future Scope

This was the first phase of internationalization across the marketing website and has enabled marketing our courses in multiple countries now, and we are able to drive content independently everywhere. The next steps would include adding local language support and allowing manually changing regions. In addition to this, we think there could be improvements in the Lambda approach. Currently, the logic of skipping certain URLs that do not fall under this criteria is a bit scattered. We are thinking of ways to make it more centralized so that it can be configured via a single source of truth. Let us know in the comments if you have implemented something similar to this in your applications, would love to have different perspectives.

This project wouldn’t have been possible without the entire team that made it a success. Kudos to Maitrey, Jitesh, Shahir, Abhishek, Harshita, Omkar, Akshay, Vishal, Yuvaraj & team, and all others who contributed. Do visit upGrad.com to check out our programs that are completely online! If you wish to work with our ever-enthusiastic team, check out our careers page. We are always on the lookout for ambitious, talented folks!

upGrad Careers

References & Further Reading

Taking upGrad.com International was originally published in Technology at upGrad on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Introducing Versioning in a Content Management System]]> https://engineering.upgrad.com/introducing-versioning-in-a-content-management-system-1b167c949cf3?source=rss----c08812b771e6---4 https://medium.com/p/1b167c949cf3 Thu, 11 Feb 2021 08:37:21 GMT 2021-02-11T08:34:39.611Z
Photo by Annie Theby on Unsplash

With tons of minor to major edits daily, keeping track of all content changes becomes challenging for content and website administrators, and that’s where content versioning comes into the picture. It is the concept of tracking different versions of content updates to answer simple day-to-day operations, such as:

  • What edits were made?
  • When was content changed?
  • Who made the changes?
  • What is the difference between previous and updated content?

Content versioning answers all these questions to make everyday operations efficient and seamless. The best example to understand content versioning is Google Docs. You can view version history, real-time changes and roll back to any version of the document without any hassle.

Since we are a swiftly scaling online higher education providing platform, our website upGrad.com requires constant changes. Almost until a couple of years ago, the content edits on the website were still being done by the technology team. This included information about our programs, and how they add value to an individual’s career. Even though most of this data was in the form of JSON, it required constant code changes to update the website. To solve this, we built Apollo, our in-house content management system (CMS). Apollo allowed us to add, alter, and delete content on the fly. Over these two years, content editing has streamlined and individual program owners now own their respective content. But as it is true in software engineering — you never solve a problem completely, you only get mature enough to solve greater ones. Along with immense flexibility, Apollo also brought in some complications, which eventually raised the need for introducing versioning.

The Why

As mentioned, Apollo CMS allowed our internal programmers and administrators to edit website content hassle-free. But over time, managing a track of every edit became hectic. When we realized that editing content with Apollo was creating problems, we started looking for a solution, and we found that versioning can be a potential fit. But what were the issues that kept us looking for a solution like versioning?

What we used to do is have separate collections for components, layouts, and pages on Apollo. The CMS is backed by a Nodejs server using a MongoDB database. The initial design was more like a relational DB. To represent a page’s data, we included references for components into layouts and then layouts’ references into the page. This led to a mesh topology where every document was connected to several components, layouts, and pages from.

As the size of the data and frequency of edits increased, keeping track of every edit with such infrastructure was challenging. Also, it was troubling to delete or rollback to any previous point in the website. For instance, if we wanted to delete any particular document, we had to go through the entire mesh topology and look for references of all the components, layouts, and pages associated with that collection. Hence, it was hectic for everyone, right from content managers to us, developers, to delete or revert to any previously updated webpage.

Each query’s response time was also increasing as the program had to go through the entire database. Slow response time affected the performance of the whole website, which was not acceptable by us. All these problems led to an urgency for introducing versioning in Apollo.

The How

We introduced versioning in Apollo by eliminating the step of instance references; instead, we started storing the actual instances in each collection. This reduced mesh topology’s complexity, and now everything, with actual instances, was held in a single collection. Hence, everything: tracking, altering, reverting, and deleting content became more straightforward.

Our CMS was now storing data about who was changing what content at what particular time. Even a minor edit was creating a new version of the entire collection. The administrator and internal programmers now had the option to compare the changes side by side to see how they will affect the website’s whole layout.

We created two stacks of pages, one for storing only the latest page version and the other for keeping the latest and older versions. Whenever a query was called to retrieve the latest version or when someone visited the website, the program would take the code from the stack with the newest version and give the output to reduce response time and enhance performance. On the other hand, if the administrator wanted to compare two versions, he can merely head to the versioning interface and select any two versions to see the differences between them.

The Seamless Transition to Content Versioning

Let’s look at an elementary example to understand what’s the difference between the older Apollo and the newer one with versioning. The below table showcases how the versions are made, and the collection is changed with each edit.

+----------------+------------------+----------+-------------+
| Global Version | Internal Version                          |
+----------------+------------------+----------+-------------+
| 1              | Page             | Layout   | Component   |
+----------------+------------------+----------+-------------+
| 2              | Page             | Layout   | Component 1 |
+----------------+------------------+----------+-------------+
| 3              | Page             | Layout   | Component 2 |
+----------------+------------------+----------+-------------+
| 4              | Page             | Layout 1 | Component 2 |
+----------------+------------------+----------+-------------+
| 5              | Page             | Layout 1 | Component 3 |
+----------------+------------------+----------+-------------+
| 6              | Page             | Layout 2 | Component 3 |
+----------------+------------------+----------+-------------+
| 7              | Page             | Layout 2 | Component 4 |
+----------------+------------------+----------+-------------+
| 8              | Page             | Layout 2 | Component 5 |
+----------------+------------------+----------+-------------+

Without versioning, the administrator had to pass queries to search through the entire website code to add, alter, rollback, or delete any content. With versioning in place, the administrator only has to select a particular global version number to find out all the details about that version. It became possible to track changes, rollback, or delete content with just a few clicks without worrying about the associated instance references.

How Versioning of CMS Helped Us?

This initiative of introducing content versioning in CMS provided us with numerous benefits, the most significant ones are:

Easy traceability: With versioning, we could track even minute changes and details such as who made the changes, what changes were made, and when they were made. It also allows us to compare the data on two versions by highlighting the changes made.

Enhanced performance: The speed and overall performance of the website were improved. For instance, to navigate a page with 3 layouts and 15 components, the program had to run 1 x 3 x 15 = 45 queries to provide the results as each collection of stored instance references. But now, with versioning, since everything is in a single collection, the program only has to run a single query for getting the output. This led to enhanced performance.

Efficient content management: Versioning allowed our internal programmers, content managers, and administrators to manage the entire website efficiently. Everything right from adding, updating, altering, reverting, and deleting content on the website became hassle-free and easy.

Introducing versioning in Apollo has helped us overcome the hurdles in efficiently managing our website. This has not only increased traceability but also has made reverting to older versions easy and has improved content stability. As engineers, this was an interesting problem to solve, deriving inspiration from versioning systems like git . If you are interested in solving similar and other interesting problems, do check out our careers page. We are always on the lookout for ambitious, talented folks!

Do visit upGrad.com to check out our programs that are completely online!

Contributors: Jawad Sonalkar

Introducing Versioning in a Content Management System was originally published in Technology at upGrad on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[How we improved user experience by building a lite version of the upGrad learner platform]]> https://engineering.upgrad.com/how-we-improved-user-experience-by-building-a-lite-version-of-learner-experience-ui-2df5ee521a5f?source=rss----c08812b771e6---4 https://medium.com/p/2df5ee521a5f Thu, 07 Jan 2021 05:43:53 GMT 2021-05-03T08:14:14.112Z How we improved user experience with a lite version of the upGrad’s learning platform

Preface

Problem Statement:
Many of upGrad’s users in India do not have access to powerful devices or high bandwidth internet, which affects their browsing experience. upGrad learners with poor or unstable bandwidth connections or with low-end devices had reported issues with screen loading times and general responsiveness of the User Interface (UI).

This was an important problem for us to resolve as providing a smooth and seamless learning experience to all our users is a key goal for upGrad.

The upGrad learner platform UI was written in Backbone.js a few years ago, was heavy in size, lacked re-render performance, and was difficult to maintain and enhance. In order to solve the problem, we decided to revamp our architecture with a modern rewrite and build a lighter version of the platform — upGrad Learn Lite — which is much more forgiving of poor bandwidth and devices.

The outcome

  1. Lighthouse Scores:
Lighthouse comparison of old and new platform

As a result of the exercise, we increased the Lighthouse score from a marginal 1 to a staggering 92 on the home page of the application. In addition to improving the load times, we also converted the app to an easily extensible Progressive Web App (PWA).

2. Load time improvements

Load time comparisons

As you can see from the above image the legacy learner platform was heavy with 13.4 MB as the size of requests and takes 6.6s to load. The Learn Lite platform is 3.4 MB in size and takes 3s to load entirely. The best part is once the New App is loaded all the bundles and assets are cached the request size is just 1.7MB!

Where this improvement shines is in low bandwidth situations. The application provides faster initial loads and mimics the experience of an app where most static assets such as bundled CSS and JS files along with fonts, images, and icons are cashed and only API calls are required to fetch data.

3. Interactive Performance:

Interactive performance comparisons

As you can see there is a significant drop in scripting and loading times (by a factor of 5). The user experience of the new app is noticeably better; every interaction is slick and smooth and re-rendering is low due to usage of Reactjs and thanks to React’s Virtual DOM Reconciliation.

The rest of this blog describes technical details of the revamp (project codename Ares) of the legacy platform.

How we did it

First and foremost, the technology behind the entire Revamp (project code name — Ares)

Frontend:

Tooling

Infrastructure

Infrastructure based on Client View

Our architecture is plain simple and gets the job done. The application gets compiled and uploaded to AWS S3 after deleting the old build via our CI/CD Pipeline (Jenkins) and is delivered across geographies with the help of AWS Cloudfront CDN. For every release old cache gets purged.

The index.html file is never cached. This is intentional as any new updates are routed via new index.html

We use Imagekit (Image CDN with automatic optimization) for delivery of Images

Having no intermittent server reduced the Infrastructure Complexity and Increased the scalability whilst also drastically improving the Web App Delivery. 🚚

The Code

Now, let us deep-dive into React and general frontend principles talking about the changes we have done. Usage of React and its ecosystem by itself was a huge factor in boosting the app's performance.

Lazy Loading

Lazy Loading is a feature that enables you to load certain other bundles after some user interaction like changing the route. This means that you can chop your huge application into segments with some performance budgeting to meet your needs.
This will drastically reduce the initial load size of the App and load the application as per the User's usage of modules.

import React, { Suspense } from 'react';
Import FirstComponent from './FirstComponent';
const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
  return (
    <div>
      <Suspense fallback={<div>Loading...</div>}>
        <Switch>
         <Route to="/"> <FirstComponent /> </Route>
         <Route to="/lazy-route"> <OtherComponent /> </Route>
        </Switch>
      </Suspense>
    </div>
  );
}

With help of React.lazy you can lazy load certain components We’ve had to lazy load the main module routes to fit into our performance budgets (less than 500kb). Suspense is a React component that would render some placeholder until the lazy-loaded component is fetched. You can have a placeholder component(loader, image and etc.,) in the fallback prop until the new bundle is loaded.

import React from 'react';
import { somefunction } from 'someLib';
function MyComponent() {
  
  const lazyFun = () => {
    import('lazy-lib').then((lazyLibraryFunction) => {
     lazyLibraryFunction();
   });
  };
  
  
  return (
    <div>
     <button onClick={() => lazyFun()}> Click to lazy execute   
     </button>
    </div>
  );
}

Not only did we lazy load components and routes but we have gone a step further to lazy load certain libraries that are only used conditionally.

export const changeLanguage = (locale) => (dispatch) => {
 import(`../locale/${locale}.json`).then(({ default: language }) =>{ 
    dispatch({
             type: 'SET_LANGUAGE',
             language,
             locale,
             });
  }).catch(() => {});
};

We are also lazy-loaded certain static JSON optionally. Like the example above where we lazy load the language JSON as per locale selected. This way the language files that were loaded were of the user’s choosing.

Usage of React Hooks:

React Hooks are a new addition in React 16.8 and they are certainly for the best. You can write pure Functional components and still manage to use State and Lifecycle via hooks courtesy of useState and useEffect. You might be pondering upon how the usage of hooks in functional components adds benefit with respect to performance.

Class-based component to JS (ES 2015)
Functional component to JS (ES 2015)

As you can see from the above Gifs functional components have nearly half the footprint of Class-based components simply due to the complexity of emulating classes and it’s a feature in JS as functions. This end of the day results in much smaller bundles.

This also means using Hooks from other libraries like React Router and React Redux wherever support is provided. At this point, everybody has moved to hooks or at least support it.

React memo:

When deciding to update DOM, React first renders your component, then compares the result with the previous render result. If the render results are different, React updates the DOM.

Current vs previous render results comparison is fast. But you can speed up the process under some circumstances.

When a component is wrapped in React.memo(), React renders the component and memoizes the result. Before the next render, if the new props are the same, React reuses the memoized result skipping the next render.

export function MemoComp({ prop1, prop2 }) {
  return (
    <div>
      <div>Property 1 : {prop1}</div>
      <div>Property 2: {prop2}</div>
    </div>
  );
}

export const MemoizedComp = React.memo(MemoComp);
Courtesy of Dmitri Pavlutin

Avoiding Reconciliation:

This basically means to avoid unwanted re-renders. Here are a few things you might have to give a thought about.

  1. Usage of React.memo as shown above, dramatically reduces re-renders.
  2. Subscribe to only used sections of the global store. Subscribing to a larger section opens up possibilities of unwanted re-renders caused by other state changes.
  3. Dispatch One Action for One Reducer that is if you are changing the Redux State at any given point maintain 1–1 ratio of action to dispatch. The below example dispatching two actions to the same reducer triggers one extra unwanted Rerender. This is for one simple API Action but as and when the application grows a lot of these things go unnoticed.
const ActionGenerator = () => dispatch => {
 dispatch(ON_LOADER);
 api().then((data) => { 
  dispatch(OFF_LOADER)
  dispatch(SET_DATA, data)
 })
}
// This causes 2 updates to store and 2*componenets times Rerenders

What if you have to dispatch multiple actions or you have to update two sub-states. You can use Redux Batch to speed to do this. batch API allows any React updates in an event loop tick to be batched together into a single render pass.

import { batch } from 'react-redux'
const myThunk = () => (dispatch, getState) => {
 // should only result in one combined re-render, not two
 batch(() => {
  dispatch(increment())
  dispatch(increment())
 })
}

Avoiding Usage of Large Libraries:

There are certain libraries like Moment, Loadash, etc., that huge packages without the support of Tree Shaking (Tree shaking is a term commonly used in the JavaScript context for unused code elimination). These libraries increase the time for the initial load. Take a look below.

Moment JS bundle stats

A good alternative to Moment would be date-fns (18kb)or DayJS (2kb) day js has fewer features in comparison with date-fns. For lodash we started writing our own utils inspired by lodash.

We wrote most of our components from scratch without using any UI Framework like antd thus reaping the benefits of performance.

📝On a side note, Ant Design is one of the most feature-packed React Libraries out there. Solves most of your problems with less development time and effort.

Optimizing CSS and Assets

As mentioned in the above point we build our own UI Components likewise we refrained from using popular CSS libraries like Bootstrap, Bulma, etc., this means CSS contains only styles we used and not any other fluff.

Purging CSS: This is a tool that removes unused CSS. This is especially useful if you are using any CSS Library (we did not have to) it just removes all unwanted styles.

SVG Components for all our assets: All the Design assets like Icons, Illustrations, Badges, etc., apart from Few Images were exported as SVG’s and used as React Components show below.

// Component 
import React from 'react';
import SvgWrapper from '.';
const AssetsExample = props => (
 <SvgWrapper {...props}>
  <path></path>
  // other SVG markup  
 </SvgWrapper>
);
// Usage
...
<AssetsExample fill="#555555" width={x} />
...

The benefit of this is that all our assets are treated as JS files. They are compiled and minified along with other JS which makes it much lighter. Elsewise you would have to load SVG’s as Images even via a CDN.

Lighthouse specific enhancements

Lighthouse is an Industry standard for web performance. The criteria for scoring in Performance as of lighthouse 6.0 by order of weightage is Largest Contentful Paint, Total Blocking Time, First Contentful Paint, Speed Index, Time to Interactive and Cumulative Layout Shift.

We targeted to maximize the top four criteria which contribute to 80% of the lighthouse score. As that is where most of our business impact is seen.

Largest Contentful Paint — LCP [25%] LCP essentially means time taken to render out the largest image or text field visible within the viewport.

elements that are considered <img>, <image>, <video>,An element with a background image loaded via the url() and Block elements with text or inline elements.

The size of the element reported for Largest Contentful Paint is typically the size that’s visible to the user within the viewport. If the element extends outside of the viewport, or if any of the element is clipped or has non-visible overflow, those portions do not count toward the element’s size.

For image elements that have been resized from their intrinsic size, the size that gets reported is either the visible size or the intrinsic size, whichever is smaller. For example, images that are shrunk down to a much smaller than their intrinsic size will only report the size they’re displayed at, whereas images that are stretched or expanded to a larger size will only report their intrinsic sizes.

For text elements, only the size of their text nodes is considered (the smallest rectangle that encompasses all text nodes).

For all elements, any margin, padding, or border applied via CSS is not considered.

credits: web.dev by google

What we did was to introduce the use of Skeleton Loader with Shimmer Animation via `background-image: URL(<imageUrl>)` before even making the API call to fetch the data. Once the data is fetched we replace the skeleton loader with the actual UI.

Old vs New app loading

This is a better way of communicating to the user what interface to expect as early as possible in the loading process. As they outline the structure itself, they can be hardcoded to appear while the server is still collecting and delivering all the page-specific content. Additionally, the user is provided with a sense of progression as the blank screen fills in with the skeleton and then the content, instead of just staring at a loading spinner or blank screen until the content is rendered.

Total Blocking Time-TBT [25%]: TBT is the minimum wait time required by the user to use the application as in trigger events, such as mouse clicks, screen taps, or keyboard presses. The sum is calculated by adding the blocking portion of all long tasks between First Contentful Paint and Time to Interactive. Any task that executes for more than 50 ms is a long task. The amount of time after 50 ms is the blocking portion. For example, if Lighthouse detects a 70 ms long task, the blocking portion would be 20 ms.

We did not actually do anything specifically to boost the TBT score. But I shall explain things that might push down TBT scores.

Loading, parsing, or execution js(javascript) impacts the time required for users to start interacting hence reducing bundle sizes by methods mentioned above like Lazy-Loading, Usage of Hooks and Nonusage of huge libraries reduces our bundle size which in turn reduced amount of js that has to be processed.

FCP: The First Contentful Paint (FCP) metric measures the time from when the page starts loading to when any part of the page’s content is rendered on the screen. These contents might be Images, SVG elements, Text elements, and white canvas.

credits: web.dev by google

What we did: In a SPA(Single Page application) you would have a Root div element and your entire app would mount on inside that element. like the snippet below.

<body>
 <div id="app"></div>
</body>
...

Without the loader in the html file.

...
<body>
<div id="app">
 <div id="pageLoaderRoot" class="loaderRoot">
  <img class="spinnerImage" src="/path/to/loaderImg"
   alt="Loading..." />
  <div class="barSpinner"></div>
 </div>
</div>
</body>
...

With the loader inside the HTML file

Here we have placed a loader in form of an image inside Root Div with this the HTML file will load the loader first and later our JS bundles would override contents inside the div with our Application.

By adding the loader like this as soon as the index.html file is loaded the loader spinner is rendered ASAP. This by principle would boost FCP scores by a good margin.

Speed Index: Speed Index measures how quickly content is visually displayed during page load. Lighthouse basically captures a video of the web page loading and calculates the visual difference between each frame.

What we did:

  1. Font Visibility: The easiest way to avoid showing invisible text while custom fonts load is to temporarily show a system font. By including font-display: swap in your @font-face style, you can avoid FOIT in most modern browsers
  2. Preloading Key Requests: We preloaded all our fonts, CSS, and certain JS files via Webpack and use of preload-webpack-plugin. By doing this all our crucial resources required throughout the app are pre-loaded in a non-blocking manner.
  3. Pre connecting to CDN and other tools: The preconnect directive allows the browser to setup early connections before an HTTP request is actually sent to the server. This includes DNS lookups, TLS negotiations, TCP handshakes. This in turn eliminates roundtrip latency and saves time for resolving used resources.
  4. Purge CSS: PurgeCSS is a tool to remove unused CSS. If you are using any third-party library or using your library for styling changes are that they are huge and you are not really using all the selectors. Purge CSS would scan all your selectors and remove all unused CSS that does not have a selector used.

Epilogue

This blog is our story of how we achieved good web performance for a React JS based Single Page Application using standard SCSS. There are certain applications and processes like usage of CSS in JS or using Server Side Rendered(SSR) application that might differ in certain cases from the above.

The need to build fast applications came in as a necessity but the knowledge was my Life Long Learning from past experiences. Likewise, my work at upGrad is now only about building applications but also to build a platform that empowers a ton of folks and helps build the Careers of Tomorrow. Do visit upGrad.com to check out our programs that are completely online! If you wish to work with our ever-enthusiastic team, check out our careers page. We are always on the lookout for ambitious, talented folks!

If this blog was helpful do clap as much as possible and let us know in the comments how it helped you. If you feel anything amiss and there is more to it, Please drop in your comments we are more than happy to engage with your discussion.

Resources

https://reactjs.org/docs/optimizing-performance.html — React Specific optimizations.

https://ui.dev/why-react-hooks/ — React hooks why ?

https://web.dev/performance-scoring/ — Lighthouse scoring deep dive.

https://dmitripavlutin.com/use-react-memo-wisely/ — React Memo deep dive

https://developers.google.com/web/tools/workbox/guides/configure-workbox — workbox configuration deep dive

https://medium.com/@joecrobak/production-deploy-of-a-single-page-app-using-s3-and-cloudfront-d4aa2d170aa3 — S3 deployment made easy

How we improved user experience by building a lite version of the upGrad learner platform was originally published in Technology at upGrad on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[How to Role Based Access Control (RBAC) ? ‍♂️⚠️]]> https://engineering.upgrad.com/how-to-role-based-access-control-9294146dc6e3?source=rss----c08812b771e6---4 https://medium.com/p/9294146dc6e3 Fri, 12 Jun 2020 14:21:23 GMT 2020-06-04T10:51:03.682Z How to Role Based Access Control (RBAC) ? 👮‍♂️⚠️
like seriously some people ask me this
NOTE: For the sake of simplicity this article is going to be based on React JS along with React Router and Node JS on Express JS for backend, all of which are awesome and do check them out.

Have you ever wondered how in the world certain large scale applications like airbnb, facebook, youtube etc., manages to block a certain part of their application for certain people or release features based on certain conditions ? They all use a tried and tested methodology called RBAC this solution gained traction during the 90’s and still is widely used in a lot of forms. RBAC stands for Role Based Access Control as the title says and this article helps you fathom the RBAC game.

Parameters to considers for RBAC :-

1. Route Guarding 🛣️:

This is a process of authenticating 🔒 and authorising routes or part of a url in your web app. Typically you have a router switch with route paths couple. Here you can see that the routes stay in a different file to act as s single source of truth. In the switch instead of routes we wrap it with a wrapper and pass roles required path and component to be rendered as props.

route wrapper here will check for authentication data and access based on the role needed by route and user role matrix. If you are un-authenticated the app will log you out to prevent conflicts, If you are authenticated but not authorised to access the route we will redirect to an error page. If your authenticated and authorised we will finally render the component. This check happens on all route changes for our protected routes.

2. Restricting access to a part of the page 🚏:

There might be certain situations where you might want to block features or a section of a page (route) while granting access to others. Here’s how we do it.

This is a RBAC HOC ( higher order components ) we get the user roles from a global store (can be through other means as well) and we try to derive the access based on user role matrix check. We render the wrapped component only if access is permitted.

3. Securing Backend Endpoints 🔗:

Last but not the least we need to make sure the backend secures their API’s from their end as well.

Well there are a ton of ways to do this using some API gateway, Proxy Servers etc., For the sake of simplicity I’m assuming certain parameters. These parameters are not necessary and you can implement the logic in way that you need as the crux is core logic only.

First thing first you’ll need a role to routes file similar to what we saw in frontend.

ℹ️ This might be a duplicate but try to host this somewhere common to solve your DRY OCD 💠 issues if any 😂 .

then this RBAC middleware below will help manage things for you automatically. Here it’s pretty simple check access and authorise / respond with error.

Now we need to wire it up with our route like this. Thats it we got them unauthorised users 🛑

Stay tuned 🕐 for part 2 of this article I might write about implementation other platform such as Next JS and GraphQL.

I’m sure there are modifications / implementations to better the above article and also fun fact route paths can be a regex(/^\/(api|rest)\/.+$/) this is something that now many of you may know. Likewise, my work at upGrad is now only about learning new things to better my career but also to build a platform that empowers multiple people in transitioning their careers as well. Do visit upGrad.com to check out our programs that are completely online! If you wish to work with our ever-enthusiastic team, check out our careers page. We are always on the lookout for the ambitious, talented folks!

How to Role Based Access Control (RBAC) ? 👮‍♂️⚠️ was originally published in Technology at upGrad on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Beginners guide to Analytics]]> https://engineering.upgrad.com/beginners-guide-to-analytics-c8ce3e92fa42?source=rss----c08812b771e6---4 https://medium.com/p/c8ce3e92fa42 Fri, 12 Jun 2020 09:45:50 GMT 2020-03-30T13:58:42.813Z Beginner’s guide to web analytics

If you are reading this blog, you might have encountered a situation where you need to implement some sort of user tracking for your product or you need to make some changes to the existing implementation and now you are looking for some material to understand the whole territory then you are at the right place.

In this blog, I will be covering all the major topics broadly, which you need to take care of when you are dealing with the analytics

Credits: meya.ai

What is tracking?

The purpose of web tracking is for websites to gain insight into their users, their behaviour and preferences.

These insights serve to optimise user-friendliness and experience, as well as for statistical purposes, customisation, commerce, and profiling and targeted marketing.

Why you need a separate platform for tracking?

Most of people use separate platforms for tracking. Google Analytics, Mixpanel, Clevertap are some of the popular analytics platforms out there. Now the question is why would you want to purchase a tool for tracking whereas you can store this data in your database and save a lot of money. Here is why.

  1. Separation of concerns- In your primary database you would like to store things that are close to your actual business e.g products, payments, users etc and you would like to focus on your business-specific code rather than tracking specific code.
  2. Focus on business-specific tools:- As a company, you would like to build tools important for your business. Building a tracking platform is not an easy job. It requires a substantial amount of effort and resources which you can spend on the other important things.
  3. Infrastructure considerations:- Scaling a tracking platform is the hardest thing. As you would like to track each and every click user does, a small app with hundreds of users can generate millions of concurrent events. Handling these many requests is a challenging task and can force you to maintain an infrastructure which could have been avoided in the first place.
  4. Features and user experience:- Most of the tracking platforms provide a lot of features e.g. auto-track properties, attribution models, funnel creation, A/B experiment, campaign param handling etc. which are hard to build and maintain. But most importantly these platforms provide a very nice and easy interface, which your business teams are generally familiar with and they can easily create reports.

Start with the tracking

After you finalise and install a tracking platform. You can start tracking events. For the start, start with the top 10 events which are most important to your business and marketing.

Important event Types

  1. Page views: Page views are the most important events when you start tracking. page views give you an estimate on how many users visited a particular page. Pageviews also help you create funnels, measure the impact of A/B experiment and so on. Most of the tracking platforms expose a separate method to track page views. You should rely on this method only to track page views instead of a custom event.
  2. Events: Events are the custom events which you need to fire when a user does specific events like button click, link click, and zoom a particular section. When you are talking about analytics, you are talking about any kind of click, scroll, video, the time elapsed events. On most of the platforms, an event consists of an event-name and few properties. Generally, events are of two types: interaction type and non-interaction type events. You should be really careful when you are marking events as interaction type /non-interaction type. Otherwise, your bounce rate metrics will get screwed.
  3. User calls: The third type of call that I am covering over here is user identification calls. The prime focus of this call is to track the user across multiple devices. Most of the tracking platforms set a cookie for distinct id in the user’s browser when the user opens your website for the first time. All the events by the user are tracked against this id. But what about events by the same user from some other device? For this purpose you do a identify call, in which you ask the tracking platform to recognise that particular user with your given id. Generally, you do an identification call after login/signup and ask tracking platform to track that user with the user id in your database. Now if the user logs in from some other device you can track that user with the same database id.
  4. Reset Calls: As much as user calls are important, reset calls are equally important. Reset calls help you to reset a particular user from the platform. All the tracking calls after the reset call are considered from a new user. Reset calls are important to make when the user logs out of your application.

Reporting

If you have done all the above steps you have successfully set up tracking on your platform. Now the next big thing to achieve is reports on the analytics platform. All the tracking platforms offer a lot of views to see your data.

  1. Reports: You can create reports based on your events and filter them based on the various event properties that you have sent or based on the properties the particular platform is tracking automatically e.g timestamp, UTM params, page URL etc. Most of the platforms offer a feature to create reports based on the unique events by users which is really helpful to understand the product.
  2. Funnels: Funnel is created to get information about the journey of a user when he is using your website. Most of the times funnels are used to see drop-offs at the various stages. e.g a common funnel for an e-commerce platform is search → product view → add to cart → product check out → payment. Now let say you rolled out a discount on a particular product you can see its effect by comparing the change in product view to add to cart ratio.
  3. Retention reports:- These reports give you insights on the probability of a user returning on your platform after n days or weeks. These reports are can give you really important insights on user patterns before purchasing a product and you can configure your marketing or re-marketing accordingly.
  4. Bounce Rate: Bounced users are the users who landed on your platform and closed platform without doing anything significant. You should create reports for bounce rate on the different sections of the platforms and specific to ads.
Sample Search Funnel

Attribution

When you are running advertisements on different ad platforms(e.g google, Facebook, youtube etc) you will need to understand that which ad platform is doing better for you and where it makes more sense to spend more. You will also need to bifurcate organic, direct traffic from the traffic coming via ads. For this purpose concept of attribution is used. Attribution in itself is a fairly complex concept.

How attribution is performed

In most of the cases, attribution is done via query params. Urchin Tracking Module (UTM) parameters are five variants of URL parameters used by marketers to track the effectiveness of online marketing campaigns across traffic sources and publishing media. Most of the tracking platforms give inbuilt support for UTM params. When you create an ad on a particular platform you associate unique UTM parameters in the URL. Later when a user lands on your platform by clicking the ad URL, these parameters are present in the URL and are automatically tracked by the tracking platform in all the events fired from your platform. You can later use this data to generate reports.

Defining an attribution model

Attribution models come into the scene when you have visitors landing on your platform from multiple campaigns/channels. Let's say you have a user who lands on your platform first from google ad link and then from Facebook ad after a day and then purchased something. To which ad will you attribute this sale? This is handled by attribution models. You need to select an attribution model which works best for your business. Most common attribution models used.

  1. First touch:- In this model, you attribute a user to the first ad campaign which caused this user to land on your platform.
  2. Last touch:- In this model, you attribute a user to the last ad campaign from which the user landed on your platform and purchased the product.
  3. Linear:- In the Linear attribution model, each touchpoint in the conversion path would share equal credit for the conversion.
  4. Time decay model:- In the Time Decay attribution model, the touchpoints closest in time to the sale or conversion get most of the credit
  5. Position-based model:- In position-based attribution model, you divide majority attribution to first touch and last touch campaigns and a small percentage to intermediate campaigns.

Conclusion and Next Steps:

Although all the above-mentioned things can help you set up the tracking infra for your business. But the list is not exhaustive. Tracking is a very vast topic and it’s not possible to cover everything in a single article. As the next step in your learning, you can read more on

  1. Third-party cookies and how they are used to track the user across different platforms.
  2. Marketing pixels.
  3. Server-side tracking.
  4. Advanced E-Commerce, Video Analytics, form field analytics.
  5. Re-marketing

And the list goes on.

I hope this article helps you and gives you good insights and a head start in the area and you know your users better.

Beginners guide to Analytics was originally published in Technology at upGrad on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Creating and deploying chrome extension on Web Store]]> https://engineering.upgrad.com/creating-and-deploying-chrome-extension-on-web-store-15f779908eb3?source=rss----c08812b771e6---4 https://medium.com/p/15f779908eb3 Tue, 21 Jan 2020 12:45:07 GMT 2020-01-21T12:50:52.449Z
https://www.flickr.com/photos/86979666@N00/6891191751

A browser extension is a mini-application. It can help in many ways like adding additional features to your browser, modifying content on the website or integrating with other existing services. They are useful in customizing the user’s browsing experience and enable them to tailor Chrome functionality and behavior to individual needs and preferences. An extension must fulfill a single purpose that is narrowly defined and easy to understand. Sometimes a single extension can include multiple components and a range of functionality, as long as everything contributes to a common purpose.

Creating your first Chrome extension

Let’s begin by creating a manifest.json file. This file contains all the properties which help us in loading our application in chrome.

Most of the fields are self-explanatory but take note of the following:

  • browser_action where we specify the default_icon and default HTML page of the extension.
  • permissions section which specifies the APIs intent which we will be using in our application.

After this, we can proceed with our HTML and JS file. Since we have declared popup.html in the manifest.json so we will create an HTML file with that name and write the following code in it.

Include all custom CSS and JS files. If you have any other dependency you can specify in this file like we have added the jQuery. Below is the code for your popup.js file.

You can test your chrome extension locally by doing the following steps:

  1. In your chrome type chrome://extensions

2. Turn on the Developer Mode as this will allow you to upload your created extension on chrome and test it locally.

3. Click on “Load Unpacked” and select your project folder and now the icon of your extension should appear on the right-hand corner.

You can now see your chrome extension at the top right corner.

Deploying on web store

Instead of including popup.js file directly we can have a minified file by using webpack. Create a webpack.config.js file and add the path to your JS file in place of “path_to_.js” as specified in the below code snippet. This will yield better results.

When uploading the extension on the Web Store we need to perform certain steps like creating a zip folder and updating the version in manifest.json. All these tasks can be done by creating a build script to automate the process.

In package.json you need to specify the following script:

This build script can be easily used to package data for deploying it on the Web Store. The build.js script will have the following code:

Now you can use npm run build to have complete chrome extension together with a zip of your src folder.

Conclusion

All these steps will help us in building a basic chrome extension project. There are many features like OAuth, Message Passing, events tracking using analytics tool and user privacy, etc which can be implemented in extension for better performance and results. I have referred the chrome developer guide thoroughly for creating the upGrad Transition Tracker extension which includes these advanced features. This extension helps the learners to add any job on the web to their Career Centre by using a job link.

Check out upGrad’s chrome extension!

Transition Tracker

Creating and deploying chrome extension on Web Store was originally published in Technology at upGrad on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[The One with Vue in React]]> https://engineering.upgrad.com/the-one-with-vue-in-react-533e701e8de1?source=rss----c08812b771e6---4 https://medium.com/p/533e701e8de1 Mon, 30 Dec 2019 11:43:38 GMT 2019-12-30T11:43:38.536Z
Why would you do that?

That was the first reply I got when I mentioned this in the React community. Well, can’t blame them, you might be wondering the same.

I will tell you why

The Vue widget here was a tagging plugin, that we have to integrate across different platforms with tech stacks including Backbone.js and React.js.

Now you might ask:

Why didn’t you build it in React then?

We went for Vue because it provided a much easier and faster development pace and not to mention a much smaller build size. By now the React devs are frowning and grinding their teeth. I know comparing frameworks and libraries can be a controversial topic.

Just for the record, I am a React fan

Don’t kill me

So let's continue the story

My task was to integrate the tagging plugin into 5 types of forms in the test platform which is currently under development ⚒. The platform provides 5 types (Multiple Correct, Single Correct, Numerical, Coding, and Open Text questions) of question creation forms.

The first thing was obviously to make a separate Tagging Component in React, which will handle all the integration logic of the Vue widget.

Let's move to the integration

Like every other developer, my first instinct was to google whether someone has done this before. I was confident enough that there will be someone who has faced the same problem. Unfortunately, I wasn’t able to find any example. Whaaaat?!!! That's the main reason I am writing this blog.

What now?

I knew the only place where I can get help is the Vue docs. To my luck, the Vue documentation was as clear as the frame on Monica’s door. For all those muggles out there (the ones who aren’t crazy fans of F.R.I.E.N.D.S), this just means crystal-clear.

To begin with, what I needed was a way to create an instance of a Vue app and mount it on a div in the React tagging plugin component. By the way, React doesn’t render a Vue widget if you directly use it in the render HTML like this 👇

function TaggingPlugin(){
//react tagging plugin component
...
return <vue-tagging-plugin/> // vue tagging component
}

So I had to create the Vue instance programmatically, like this 👇

Not to worry, I am gonna explain this in detail

var vm = new Vue({   // options })

This creates a Vue app instance and mounts it on the el which is the root HTML node.

We have a Vue instance created and the node to be mounted on. What we need now is the widget we need to render in the Vue app, which brings us to the very important part 👇

render: function(h) { // h = createElement
     return h(window.taggingPlugin, {
        props: this.props
     });
}

The render API of Vue is passed a createElement function. This creates the HTML, hydrates it with the data & props if any and finally returns a Vue node which is then appended to the DOM. The first argument to createElement can be an HTML tag name, component option or any async function that resolves (which in our case is the instance we created) to any of the above. The second argument is an object with attributes that you use in a normal Vue component definition, in my case, the props for the widget.

Now we have is the data prop 👇

data() {     
    return {
          ...     
          props: {
          }
    }
}

The data prop in Vue is basically the equivalent of React component’s state. Now you might be wondering why did I create a props object in the data and use that props, in turn, to pass it to the Vue createElement’s prop. So the reason is that the widget I created is a child of the root Vue Instance and it was also a better way to pass down the data from the root of the app itself, instead of directly injecting the props from React component.

return h(window.taggingPlugin, {          
     props: this.props     
});

The this here is the Vue instance, so we can easily access the data of the Vue app. So whenever I needed to update the id prop in the Vue widget from React component, I would do something like this 👇

useEffect(() => {
     window.taggingInstance.props.config.componentId = id;
}, [id]);

Well the part where everything comes together 👇

This is the React component after all the integration with Vue widget.

Also, JFYI, for the taggingPlugin to be available in the window you have to add the widget build js file, CSS file and Vue bundle files in your index.html of the React app.

Conclusion

Not finding any solution when I googled this for the first time was a turning point. Otherwise, I wouldn’t have gone through the amazing Vue docs and got a deeper understanding of Vue internals - how a component is rendered, how the data flow works, and most of all, the rush of finding a way out to solve such an interesting problem. I am sure that there will be better and efficient ways of doing this. If there are any such references or methods please do add them in the comments.

The One with Vue in React was originally published in Technology at upGrad on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]>