Andre Bogus
Dec 16, 2022 ⋅ 7 min read

How to build a Rust API with the builder pattern

Andre Bogus Andre "llogiq" Bogus is a Rust contributor and Clippy maintainer. A musician-turned-programmer, he has worked in many fields, from voice acting and teaching, to programming and managing software projects. He enjoys learning new things and telling others about them.

Recent posts:

Developing Web Extensions With Wxt

Developing web extensions with the WXT library

Browser extensions are an important part of the web ecosystem. They make our lives easier and enhance our web browsing […]

Debjyoti Banerjee
May 24, 2024 ⋅ 8 min read
Bulma Css Adoption Guide: Overview, Examples, And Alternatives

Bulma CSS adoption guide: Overview, examples, and alternatives

Explore how Bulma CSS simplifies frontend development with its ease of use and customizable, responsive, pre-designed UI elements.

Timonwa Akintokun
May 23, 2024 ⋅ 10 min read
Using Mountaineer To Develop A React App With Python

Using Mountaineer to develop a React app with Python

Develop a React app with Python using the Mountaineer framework for building a simple app with integrated your frontend and backend database.

Rosario De Chiara
May 23, 2024 ⋅ 7 min read
Enhance CSS View Transitions With Velevette

Enhance CSS view transitions with Velvette

Velvette is a utility library developed to make working with view transitions easier.

David Omotayo
May 22, 2024 ⋅ 9 min read
View all posts

2 Replies to "How to build a Rust API with the builder pattern"

  1. The build patterns are awkward because of the borrow checker, the complexity is obvious from articles like this. So my conclusion is actually that optional named parameters are very much needed in Rust to alleviate the creation of objects with a less heavy solution that is more efficient, easier to read and that doesn’t require the creation of intermediate objects.

    Another alternative is to make functions and methods optionally pass ownership, only if the function/method output is assigned to a variable.

  2. I disagree. First, often you can get away with having one or two methods or a plain struct to work with. The builder just ensures a nice and flexible interface while keeping open the door to later changes. Also the complexity cost is mostly paid by libraries which are usually meant to be reused, thus amortizing the investment.

Leave a Reply