2. Lack of etiquette and manners is a huge turn off.
KnolX Etiquettes
Punctuality
Join the session 5 minutes prior to
the session start time. We start on
time and conclude on time!
Feedback
Make sure to submit a constructive
feedback for all sessions as it is
very helpful for the presenter.
Silent Mode
Keep your mobile devices in silent
mode, feel free to move out of
session in case you need to attend
an urgent call.
Avoid Disturbance
Avoid unwanted chit chat during
the session.
3. Our Agenda
01
Microservices Introduction
02 Why should I develop in microservices
03 Introduction to backend for front-end pattern
04 API vs BFF
05 When use BFF and its benifits
4. Why I should develop in microservices
● Scalability
● Multi language
● Reliability
● Easy to release
● Decoupled Services
● Performance
● Agile/Lean Team
● Better Maintenance
● Production ready
● Cross Platform
● Cloud Implementation
5. Microservices Introduction
Also known as microservices
architecture- is an architectural style
That structures an application as a
Collection of service that are highly
Maintainable, testable , resiliently,
Independently, deployable and
Organized around business
capability
Breaking up an application into a
series of smaller , more specialized
part , each of which communicate
with one another across common
interfaces such as API and REST
interface like HTTP.
Microservices
Back-end-for-front-end is an
architectural paradigm, a variant of
the API gateway pattern, with each
client application having its
corresponding back-end application.
This pattern is good when you have
multiple client interfaces with diverse
needs, leveraging the same
underlying resources. A real-world
example of the BFF pattern is an
application having both a Web and a
mobile client.
-Support for multiple isolated
interfaces.
-Client specific trueaks are much
faster.
-Hide sensitive information
seamlessly.
-Picking right stack / protocols for
client.
Why BFF?
BFF-Architecture
6. Introduction to the Back-End for Front-End Pattern
● Let’s imagine the case when you need to create a mobile app for an existing
system. The system was one monolithic solution that exposed an API serving only
the web client.
● The idea from the client is not only limited to new mobile apps, but he also considers
voice assistants and 3rd party services which will use our API.
● So the issue is that one API needs to support all these types of clients, and we need to
take care of their requirements and maintenance.
7. ● The back-end for front-end (BFF) architectural pattern proposes a server-side component for each
front-end application, thus enhancing and improving the user experience.
● A BFF layer comprises multiple back-ends that are designed to meet the demands of specific
front-end applications, such as desktop, browser, and native-mobile applications.
● One of the most appealing aspects of BFF is that it provides smooth user interaction independent of
the platform on which the front-end application executes.
Introduction to the Back-End for Front-End Pattern
Monolithic
DB
CLient
9. ● You need to think of the user-facing application as being two
components — a client-side application living outside your
perimeter and a server-side component (BFF) inside your
perimeter.
● BFF is a variant of the API Gateway pattern, but it also provides an
additional layer between microservices and each client type
separately.
● Instead of a single point of entry, it introduces multiple gateways.
● Because of that, you can have a tailored API that targets the needs
of each client (mobile, web, desktop, voice assistant, etc.), and
remove a lot of the bloat caused by keeping it all in one place. The
previous image describes how it works.
Backend for Frontend (BFF) design pattern over API gateway
10. When use BFF?
● Like many other patterns, using the BFF in your application depends on the context and the architecture you
plan to follow.
● For an application that only provides one front-end, I suspect Backend For Frontend will only make sense if and
when you have a significant amount of aggregation required on the server-side. Still, even then, the concept of
API gateway can be used. BFF style can be considered when you plan to extend the number of frontend types.
● If your application needs to develop an optimized backend for a specific frontend interface or your clients need
to consume data that require aggregation on the backend, BFF is for sure a suitable option. Of course, you might
reconsider if the cost of deploying additional BFFs’ services is high, but even then the separation of concerns that
a BFF can bring make it a fairly compelling proposition in most cases.
11. ● BFF is impacting the development community in many positive ways and here are just a few
reasons behind its appeal:
● Multiple frontend application interfaces can call their respective BFF backends in parallel, and
dedicated backend services can respond faster.
● Following BFF architecture reduces the time to make modifications and enhancements in backend
systems with dedicated teams working on the upgrades.
● The BFF layer in the overall system architecture can benefit from hiding sensitive or unnecessary
data before transferring it to the frontend application interface, which helps simplify the system.
● BFF backend systems can use any protocol like FTP, SOAP, REST or GraphQL to request data from
microservices, but still use a single protocol when interacting with the frontend application
interface.
The Benefits of BFF