JSFoo 2019

Annual conference of 800+ front-end, backend and fullstack engineers

Tickets Propose a session

Scalable platform UI apps with polyglot components (Intuit case Study)

Submitted by ranadeep bhuyan (@ranadeepbhuyan) on Thursday, 9 May 2019


Preview video

Section: Full talk (40 mins) Session type: Demo Technical level: Intermediate

Abstract

The talk followed by code snippets and demos will show how to develop a scalable and resilient platform of polyglot components and let developers write components/code with whatever languages and frameworks they like (reactjs, vue, ReasonML, dojo etc).
A case study will demonstrate how to overcome various architectural anit-paterns and challenges yet keeping things simple with options and solutions.

Co-existing monolithic application with a ‘modern’ polyglot ecosystem of broken down components and microservices is the reality of more than 90% of large software applications now.

These kind of polyglot ecosystem of components grows with a mesh of UI components and a set of large number of micro services in it, which creates multiple anti-patterns very easily in the architecture. The demonstration will cover micro front ends and micro services that co-exists in a loosely coupled ecosystem with learnings and best practices.

Key takeaways:

  • JavaScript Plugin architecture for QuickBooks app store.
  • How to architect a UI platform shell that holds polyglot components together
  • How to isolate components so that they can be glued together to avoid decomposition in the future?
  • Security and Performance best practices while developing polyglot UI components
  • When to decide not to decompose a monolith, how to keep the balance

Outline

Context of the problem

Quickbooks was build during jQuery era. It has evolved since then and has gone through multiple platform changes. However, post era of MVC developer architected quickbooks using with components (building blocks) and allowed multiple frameworks and programming languages. Now a days we term it as a Polyglot application.

For example, WeComponents that are built using backbone, ES6, reactJS, DOJO etc are used in one web application powered by a set of microservices with nodeJS and Spring-boot in the backend. These ecosystems are gifts of hybrid technologies, easy available frameworks, libraries and servers. In general, a monolithic application grows with code and dependencies over a period of time unlike quickbooks, a polyglot application grows with a mesh of components and micro services and functional components in it.

Challenges with Polyglot ecosystems - examples

Reusability of components in such environments are less as they can have tightly coupled peer components that could create anti-patterns very easily - eg: dojo hui components - we can’t reuse them in a reactJS app or ES6.

Mesh of components or micro services with overlapping features/functionalists are also anti patterns for single responsibility principles. Poor Discoverability leads to create clones. Killing a clone is difficult as that requires complex migration of live customers.

  • Components with dojo, backbone and reactJS - case study

Web applications evolves over a period of time. We have been lucky to reset our technology stacks in every 24 to 30 months. This has added complexity in managing the load patterns on our web pages with all of these libraries, frameworks.
Architects and Developers are almost always free to choose their tech stacks based on some rational and need of the hour while solving for customers. We all love to explore and tend to use cutting edge technologies whenever it was relevant.

  • Costs of tech stack upgrade
  • Architect around a specific UI framework
  • Adding new features to UI Plugins (components) was time taking.
  • Major plugins become monolithic easily
  • Manage multiple monolithic code bases
  • Centranized Eventing bottleneck

Problems we solved

  • Loose Coupling
  • Improve memory management
  • Avoiding anti patterns
  • Embrace Web components standard
  • Allow framework to be extended
  • Improve developer experience as well as user experience
  • Quick go to market, world class monitoring and post launch support.
  • Componentization reduces the risk of down time of critical lifelines of components.

Drastic Demo

  • Co-existing web-assembly and Vue.js components
  • A quick coding and create both components

Requirements

Laptops
Some idea about front-end technologies

Speaker bio

Ranadeep is a full stack engineer at Intuit. He contributes to design, development and architecture of solutions for complex engineering problems for QuickBooks and it’s customers.

https://ranadeepbhuyan.wordpress.com

https://github.com/ranadeepbhuyan

https://github.com/intuit/Ignite

QuickBooks Engineering blog

Links

Slides

https://docs.google.com/presentation/d/1LIiHOz3ohQTd8hEC5sBEkP1Eg9xQs5002szcRnUYId4/edit?usp=sharing

Preview video

https://youtu.be/tHk-dgurWao

Comments

  • Zainab Bawa (@zainabbawa) Reviewer 3 months ago

    The proposal needs to explain:

    1. What is the problem statement? How is this problem statement general/universal, and not something specific to QuickBooks alone?
    2. Why did you choose the approach (and the tech stack) you did to solve this problem? What other approaches (and tech stacks) did you compare this with?
    3. Show deep dive into how you solved the problem. Explain the pros and cons, including the trade-offs of using this approach.
    4. What is the one key insight/takeaway you want the audience to take back?

    The draft slides have to reflect the above. And a preview video also required, giving an elevator pitch for this proposal. Submit this within one week for evaluation.

  • ranadeep bhuyan (@ranadeepbhuyan) Proposer 3 months ago

    Hi @zainabbawa,
    Thank you for feedback. I have updated the proposal.

  • Zainab Bawa (@zainabbawa) Reviewer 2 months ago (edited 2 months ago)

    This is good and detailed. a quick comment and question:

    1. Are you going to explain all this with QuickBooks as example? Will you anchor this talk in QuickBooks’ journey?
    2. By context, I mean context of the product/organization/architecture. Right now, you have specified the context by explaining the history of concepts (which is not the context we want).
    • ranadeep bhuyan (@ranadeepbhuyan) Proposer 2 months ago

      Hi Zainab,

      1. Yes quickbooks is the core example, I will touch up quickbooks journey as well. I am sure there are a bunch of such example out there. Facebook did couple of massive changes in there platforms on the other hand Segment took a very differrent approach which is an anti pattern some of the microservices architecture but that addresses issues with componentization of a large system.
      2. Sure, I have modified the context.
  • Zainab Bawa (@zainabbawa) Reviewer 2 months ago

    We will bring in reviewers from the community to comment on the technical aspects and problem formulation. To me, it seems like you still have to refine the pitch (by choosing on core argument), but this is good material and thinking to work with.

    • ranadeep bhuyan (@ranadeepbhuyan) Proposer 2 months ago

      Working on it.

Login with Twitter or Google to leave a comment