ngStockholm #8 at NetEnt - Micro Frontend Architecture

Micro Frontend and How
come we work with it.
Ishaan Puniani
Game Framework Developer

About me
 Full Stack Developer at NetEnt
 Previously,
Associate Architect, Blogger,
Mentor, Free Lancer, Motivator, Speaker,
Team Leader
E-mail: Ishaan.Puniani@gmail.com
GitHub:
https://github.com/ishaan-puniani
LinkedIn:
https://www.linkedin.com/in/ishaanpuniani/

Glossary
Full-Stack Dev Team
Frontend Dev Team
Backend Dev Team

How we start web development?
--- In late 90’s

Back to the basic
 A simple Web application and a team responsible for developing this
application

Impact and Benefits
 Best suits for small projects and simple functionalities.
 Encourages face-to-face communication between backend, frontend and
QA.
 Consistent area of focus that accelerate Development speed.

Issues
 Feature scaling and parallel implementation of features is close to
impossible.
 Hard to maintain.
 Scalability, A/B Testing, RCA’s, troubleshooting, Impact Analysis,
Deployments etc.., are the major issues.
--Even few terms did not exists.

Let’s start Divide and Rule….

Team splits based on their interests
 Named as Frontend Team and Backend Team
Frontend Development Team Backend Development Team

Impact and Benefits
 Best suits for medium sized projects and many functionalities.
 Encourages API’s communication related documentation.
 Still a consistent area of focus that accelerate Development speed.

Issues
 Feature scaling and parallel implementation of features is at-least possible
in a scalable manner.
 Still Hard to maintain.
 Scalability, A/B Testing, RCA’s, troubleshooting, Impact Analysis,
Deployments etc.., are still major issues.

Something happed mysteriously….

Backend Team splits based on their focus area
 Named as Frontend Team and Micro Service Teams.
Frontend Development Team Backend- Microservice Team

Impact and Benefits
 Has all the benefits of previous approach like High speed of development,
feature intensive, good documentation, well defined focus area etc..
 Best suits for large sized projects and many functionalities.
 Encourages API’s communication related documentation.
 We start understanding Scalability, A/B Testing, RCA’s, troubleshooting,
Impact Analysis, Deployments etc.., to much extent.

Issues
 Communication is challenging
 Product vision start deviating
 Lot’s and Lot’s of documentation is required.
 With the growing backend features, Frontend is still a monolith and
becomes bottleneck of Time to Market.

Frontend techniques starts evolving
 Browsers starts getting matured.
 New standards for W3C and Browser API’s
 Frameworks and Patterns for Frontend become super active.

Approach 1 ) Teams based on their focused features
 Named as Vertical Teams (A team of full-stack developers of mixed
competences).

Approach 2 ) Teams based on their focused areas
 Named as Micro-Frontend Teams and Micro Service Teams.

Impact and Benefits
 Has all the benefits of previous approach (that fits in) like High speed of
development, feature intensive, good documentation, well defined focus
area etc..
 Best suits for large sized projects and many functionalities.
 Feature scaling and parallel implementation of features is possible to much
extent in a scalable manner.
 We start understanding Scalability, A/B Testing, RCA’s, troubleshooting,
Impact Analysis, Deployments etc.., to much extent.

A glimpse of Business Goals
 Receive any type of Notification from the Back Office
 Display according to the priority of notification in the new system
 Allow us to be able to set up new type of notifications in the future
 Extendable to handle messages from other sources

Technical Goals
 Separate it from Game and treat them as add-ons.
 Easy to deploy, modify, update without modifying games.
 Flexible and Extendable to handle messages from other sources with
different communication protocols (HTTP REST API, Web Sockets etc..)
 Independent and have clear separation between business logic and view.

Implementation
 We are trying to implement it as Micro Frontend and Micro Service
Approach
 It will have its own Continuous Integration pipeline.
 Each component can be delivered independently.

High level design of a small component

Interoperability and language independence
 Motivation
▫ Microservices are independent of technology stack we choose.
 Implementation
▫ We achieved is each component can be developed using technology
stack that suits the business requirements effectively.
▫ TypeScript empower us to have interfaces that are available for
developing standard components and defining base.

Service Router / Locator
 Motivation
▫ Microservices are load-balancer and service locators to resolve the
application behind the end-point based on the conditions.
 Implementation
▫ We achieved this by using script-loaders to load the components and
its dependencies on run-time.

Event Bus / Communication
 Motivation
▫ Microservices generally uses event driven pattern, queues or event bus
for communicating with each other.
 Implementation
▫ We use event based patterns that allows one component to coordinate
with the other component and with the state of application.

Service versioning and Multi-Instance
 Motivation
▫ Microservices generally runs on multiple instances (might be with
different versions for A/B testing).
 Implementation
▫ With script-loader we can easily make conditional script loading and
perform A/B testing and actually multiple instances are not required
directly CDN’s will take care of that.

Other small details
 Logging Modules
▫ In the similar fashion with microservices, logging module can be
implemented separately.
 Fail Resistant
▫ In case of failure only impacted components stop rendering and display
message in a nice way.
 A/B testing support, flexible, extensible and decoupled.
 Evolutionary and extended future support

Other approaches that did not fit
 Micro Frontend By Page
▫ Didn’t fit in as our games are running on a single page.
 iFrames for different components
▫ Makes things too much complicated and very hard in terms of
communication between different iFrames.
 Custom Elements
▫ Since there is not SSI or there is no scope of packaging them in the
game release due to Regulations.

Power comes with responsibilities
 Compromises the runtime performance, load time of the application.
 Runtime Dependencies lead bug reporting's to the later stages.
 Needs a careful look at System Integration Testing.
 CSS collisions and impacts.
 Consistencies might vary and needs to be taken care.
 Multiple versions of vendor libraries used in different components
 Tool chain needs to be revamped.

ngStockholm #8 at NetEnt - Micro Frontend Architecture

ngStockholm #8 at NetEnt - Micro Frontend Architecture

More Related Content

What's hot (20)

Similar to ngStockholm #8 at NetEnt - Micro Frontend Architecture (20)

Recently uploaded (20)

ngStockholm #8 at NetEnt - Micro Frontend Architecture

Editor's Notes