yordisprieto
Hey there, I am working with a client for an OpenAPI spec, and I have a dilemma.
Imagine the following
defmodule API.Account do
@moduledoc """
Implements /account endpoints.
"""
alias StrawHat.Response
alias API.{Client, Client.Request}
@type t :: %__MODULE__{
email: String.t(),
id: String.t(),
is_international: boolean()
}
defstruct [:email, :id, :is_international]
@doc """
Retrieve account information.
"""
@spec get_account(%Client{}) :: Response.t(%__MODULE__{}, Client.error())
def get_account(client) do
client
|> Request.new()
|> Request.put_method(:get)
|> Request.put_path("/account")
|> Client.send()
|> StrawHat.Response.and_then(&transform_response/1)
end
@doc false
def new(data) do
%__MODULE__{
email: data["email"],
id: data["id"],
is_international: data["isInternational"]
}
end
defp transform_response(data) do
data
|> new()
|> Response.ok()
end
end
Here is my dilemma: Should I transform the incoming data into structs, or I shouldn’t bother with it?
I am talking about the following part
|> StrawHat.Response.and_then(&transform_response/1)
Should I keep that? Or should I just return the raw data?
I still don’t know what the right answer is here honestly.
From one side, it is a lot of work and I think doesn’t matter much, not sure.
From the otherwise, it is nice, I get to have structs and normalize a bit the keys and such.
Trending in Discussions
The obligatory hello world thread!
Who are you and where are you from? :stuck_out_tongue:
New
Hey there,
It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
Hey folks,
I wanted to share with you a project I’ve been working on for a while: It’s an Open Source (AGPLv3) newsletter tool. Think Ma...
New
Hi everyone :waving_hand:
I wanted to share something I’ve been building — NowBlind, a random chat app designed to help people discover ...
New
In my third year of college, around 2010, I found Erlang. A few years later, I found Elixir. I liked the ideas at once: many small proces...
New
Hi everyone,
I have 8 years of production experience with Erlang/OTP and I’m just starting to get to know Elixir. What would you learn f...
New
I’ve been tinkering with Lynx (by José) via hold_ledger. I used AI to write the code, a separate specification, the tests, and the Lean p...
New
Other Trending Topics
Hey there,
I haven’t seen a list of useful Elixir specific skills for the popular AI tools yet so I’m starting one here with my first.
...
New
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
(I just needed to vent somewhere and LinkedIn is full of hope, or hype, I’m not sure which exactly)
AI dream has many faces, but general...
New
Localize is the next generation localisation library for Elixir. Think of it as ex_cldr version 3.0. The first version will be released ...
New
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself.
My main conc...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #elixirconf-us
- #blog-post
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #performance










Showing Posts 1 to 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
princemaple
My personal preference is to return raw, so that you don’t have to keep up with the api as closely, and don’t have to distinguish between versions as strictly.
stefanchrobot
If I’m writing an API client where I work with the data (as opposed to just passing it to somewhere else), I usually add the request and response structs. This makes the API more discoverable without the need to reach to the API documentation. But this is not a universal advice - there are scenarios where you don’t care about the response, so why waste the time on building a reach response.