JSFoo is in its ninth edition this year. Talks at JSFoo 2019 will cover the following topics:
- Component architecture – how different web components have been stitched together to build apps; outcomes on UI and performance as a result of architecture choices
- Deployment practices for front-end and how Kubernetes and CI/CD fall into this picture
- Developer experience (DX)
- Functional programming paradigms: ReasonML and ClojureScript
- Privacy and Content Security Policy (CSP)
- New developments such as SvelteJS
Speakers from Razorpay, CloudCherry, Myntra, Innovaccer, GitLab, Microsoft, Atlassian and Gramener will share their work and learnings on these topics.
Who should attend JSFoo:
JSFoo is a conference for practitioners, by practitioners. JSFoo 2019 is a conference for:
- Front-end engineers
- Senior software developers
- Team leaders and engineering managers
- Fullstack developers
- InfoSec professionals
##JSFoo 2019 details:
Dates: 27 and 28 September
Venue: NIMHANS Convention Centre, Bangalore
The following workshops have been curated for before and after the conference:
For inquiries about conference tickets, workshop tickets and any other details, call JSFoo on 7676332020 or email email@example.com
JSFoo 2019 sponsors:
For tickets and sponsorships, contact firstname.lastname@example.org or call +91-7676332020. For queries about proposing talks, write to email@example.com
Front end architecture with polyglot components (A case Study)
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.
- 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
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.
- Co-existing web-assembly and Vue.js components
- A quick coding and create both components
Some idea about front-end technologies
Ranadeep is a senior staff engineer at Intuit. He contributes to design, development and architecture of solutions for complex front end engineering problems for QuickBooks and it’s customers.
- This Proposal:
- – ToDo
- Cuts from Previous talks:
- Reference links:
- https://intuit.github.io/Ignite/pages/Introduction.html (markdown layout components)
- https://www.developer.intuit.com/app/developer/homepage (create apps for quickbooks)