This talk was presented at API The Docs Virtual 2021 event series on 14 April. We are glad to present the video recording, slide deck and talk summary below. Enjoy!
Visit our talk recaps ToC page for an overview of all presentations!
Mihaela-Roxana Ghidersa
Application Developer at Centric IT Solutions Romania
Mihaela's presentation
Mihaela's slides
Read more from Mihaela on the topic:
Backend vs. Frontend:
- Backend developers used to deal with meaningful issues, like maintainability, state management, or API design
- With JavaScript exploding in the last years, a lot of this responsibility went on Frontend
Sharing responsibilities in distributed development teams:
- The base of collaboration is the data received from the server
- The question: Are our (API) clients managing a bit too much sometimes?
- If the answer is yes, might be difficult to keep up with having to change and managing the code base, and can also bring complications on the performance side
“I need some additional data in the UI.”
- "Just create a new endpoint and use it" leads to chattiness and latencies
- "Add more data to the endpoint we are already calling" results in fat payloads
But leaving the application to grow in complexity results in One-Size-Fits-All APIs.
Is the implementation actually REST?
- Trying to use principles in a way that are not really complementing our application can lead to complications
- Switching to a microservices architecture pushed complexity onto the client as the data source is shaped to the requirements of the client
- However, it invalidates one important function of REST APIs: absorbing complexity
How to make the right choice of approach?
- How different are the needs of each client?
- Are the services and the client on by different teams?
- Are we performing aggravation in the API gateway?
BFF: Backend for Frontend
An architectural software pattern that shapes the data fetched between clients and servers. The goal of this pattern:
- Decouple the frontend from the backend through
- A layer that meets the exact needs of a specific client
- All the clients can fetch data from the same BFF server, code reusability
- Make very complex processes less chatty
Where GraphQL is a better fit than REST:
Serving the client with specific data
- Very specific request, very specific response
- Endpoints are gone, resources are declaring on their own
- Reduces the number of HTTP calls
- Different error code processing - related to GraphQL’s self-documenting ability and quick response
- No more traditional issues with versioning
Where GraphQL shines
- The client gets more freedom respecting the data it gets
- Possibility to serve several clients
- Makes it easy for different clients to coexist and evolve
- Less deployment complexity
- Less interdependence among separate teams
- Isolates UX from changes
Some changes in the mindset
- Quit the association of frontend and backend with client and server
- Create an overview on the whole of the application
- Work of the communication to backend developers
Sign up to our Developer Portal Newsletter so that you never miss out on the latest API The Docs recaps and our devportal, API documentation and Developer Experience research publications.