Frontend and Backend

{their roles and boundaries between them}

Introduction

01

About me

Johnny Seyd

years of experience in web technologies�(30 years of coding, 16 years management)��� 18 years father� 14 years consultant� 12 years entrepreneur� 8 years speaker/lector

4 years startup founder

• hundreds of projects
• from tiny websites
• to huge enterprise projects
• from large scaleup
• to VC funded startup

Backend

02

BE as API

Who is the BE developer here?

Responsibilities of the API

System and data are manipulated only via API!

• offers all functionalities via endpoints
• manages the data and files
• handles authentication & authorization
• integrates with external services or APIs
• responsible for database

What you won’t find on the backend?

“The backend is for introverts!”

• visual design, layout, CSS, responsive design, animations
• parallel events or waiting for user interface events
• observables and other concepts from FE
• UX topics, UX testing, trying more approaches at once
• cross-browser issues & accessibility
• long debates with the customer about functionality

What you can LOVE on the backend?

• deterministic and predictable
• straightforward program flow (“synchronous” operations)
• focus on logic over presentation
• focusing on algorithms and data structures
• emphasis on performance and optimization
• isolated functionalities - each endpoint works separately
• easy to code review and to test

Frontend

03

FE as Web App

FE as Web App

Who is the FE developer here?

Responsibilities of the FE

The user sees and evaluates only the frontend!

• to enable the use of BE functionalities (for people)
• to be intuitive (no documentation needed)
• to help achieve the goal (UX, responsive design, accessibility)
• to extend the reach (PC, smartphone, refrigerator, …)
• not to discourage and not to piss off
• to sell the product/service

What you won’t find on the frontend?

“The frontend is for extroverts!”

• database queries and data indexing and data performance
• encryption of sensitive data
• authentication and authorization responsibility
• security compliance, GDPR regulatory, audit / logging
• memory and CPU management
• stress testing, scaling, monitoring, …

What you can LOVE on the frontend?

• visible progress (instant gratification)
• rapid prototyping and development (even without the API)
• creating visual design (non-programming in CSS)
• dynamic and interactive content
• focus on user experience (UX evaluation, infinite options)
• non-monotone work (wide variety of frameworks and tools)
• satisfaction from user engagement (feedback, visible impact)
• constant evolution (career flexibility)

04

The Boundary Between

Who is the Full-stack developer here?

Why to separate FE & BE?

• separation of concerns
• independent development and deployment
• reusability of backend services
• FE-agnostic backend / BE-agnostic frontend
• easier testing, easier performance optimization
• team specialization
• less complex

Where is the boundary?

FE

BE

?

Where is the boundary?

FE

BE

API

Where is the boundary?

FE

BE

API

Where is the boundary?

FE

BE

API

code / system

code / system

doc / specification

What can be a bad idea

05

​

Backend-Centric API Development

• isolated backend design, inconsistent API design
• lack of requirement gathering, code-first mentality
• mismatch between FE and BE expectations
• inefficient data transfer
• increased integration time of FE, integration issues
• frequent changes and instability
• overengineering, increased development time
• API specification is auto-generated from the code

Frontend-Centric API Development

• GraphQL
• Firebase
• improper data structure design
• security risks
• scalability problems
• vendor lock
• learning curve / crosses the line of FE responsibility

No King - Agree Among Yourselves

• waiting for an impulse from the other side
• inefficient and useless work
• FE is waiting for complete API endpoints
• BE is then waiting for the feedback
• unannounced changes breaking changes of API
• low morale and frustration
• incomplete documentation (after all, it's in the JIRA task)
• very low productivity, frequent changes and instability

What Works for Me

05

​

The Most Important Documentation

• requirements documentation
• functional documentation
• system architecture
• data models and database schemas
• component, sequence and state diagrams
• UI designs / screen prototypes

The Most Important Documentation

• requirements documentation
• functional documentation
• system architecture
• data models and database schemas
• component, sequence and state diagrams
• UI designs / screen prototypes
• API documentation

The Most Important Documentation

• requirements documentation
• functional documentation
• system architecture
• data models and database schemas
• component, sequence and state diagrams
• UI designs / screen prototypes
• API documentation (+ entity diagram)

Spec prepared by an Analyst

• who has experience with systems analysis
• who can talk to the business, to stakeholders, to FE and BE
• who has experience with well-known standards
• who can act quickly
• who understands what is important and what can be changed or added later
• who can involve other parties (or/and create tasks)

The Design-First Approach

Writing REST API documentation in advance.

​

Also known as the "design-first" approach - �helps ensure that all stakeholders have a clear understanding of the API's functionality before development begins. This approach can lead to better-designed APIs, fewer misunderstandings, and a more streamlined development process.

What a good API spec should contain

• list of all endpoints (name, method, url / resource hierarchy)
• target audience (public, authorized, roles, subroles, owners)
• description, restrictions, constrains
• input parameters (request: headers, path, query, payload)
• output (response: status code, output structure, error states)
• non-functional requirements - performance, security, encryption, compliance, logs, delete strategy… �(instructions for programmer)
• versioning / deprecations / changes

Examples

request

{

response

{

{

JSON body�structure

Examples

Communication

Frontend�Developer

Backend�Developer

Analyst

(owner of the spec)

Why is Swagger not enough?

• I have to code the spec in advance
• if not, I have to update the code spec (comments) �after each spec doc change
• I cannot discuss or suggest the changes
• I am not the owner of the API spec
• long time to publish changes
• weak collaboration and sharing
• missing instructions for BE developer

Useful tools and libraries

Mock Service Worker

/package/msw

• Seamless: Application's code and �tests unaware of whether something �is mocked or not.
• Deviation-free: Augment an existing API, or design it as you go when there is none and you can prototype before the real API is developed.

Frontend

ZOD +

• real-time validation of�every API response
• if something doesn’t match,�break the flow and �report to the Sentry
• infer the static TypeScript types

/package/zod

Frontend

TSOA

• rely on TypeScript type �annotations to generate �API metadata if possible
• minimize boilerplate
• auto-generate Swagger �documentation

/package/tsoa

Backend

What AI tools .. �are you using?

Powered by AI

???

Frontend�Developer

Backend�Developer

Analyst

(for writing the spec)

Summary

06

​

API Specification�is the most important document

Design-First Approach�with an experienced analyst

Understand the Other Side�don't overstep boundaries but try to help

Involve Useful Tools�that enable collaborative work and sharing

Try to get AI on Board�as soon as possible �and under any circumstances

FE and BE are both important�one needs the other, �cooperation is necessary

Q&A

07

​

THANK YOU