Best way to pass many arguments to a function?

The rule of thumb is to not have a lot of arguments for a function (for me personally 4 is the upper limit). The most dangerous thing is as you mentioned, should you mess up the order and you can be in trouble.

In this case going with a map argument is the way to go, however I would advise against Option 2, as it is generally discouraged to have a match where you literally match on all the fields.

What you can do instead is to use the . map operator, for example freight_order.shipping_customer, in this way you will have an exception if that key is missing.

If you want to ensure that the structure of the map is respected at compile-time please use Typespecs.

A couple of recommendations:

Because APIs are volatile, perhaps you want to give your users a message about it and NOT LetItCrash™, you should have your API calls return error tuples and use them with with.

with {:ok, shipping_customer} <- call_api(...),
     {:ok, receiving_customer} <- call_api(...),
     {:ok, line_items} <- call_api(...),
     {:ok, freight_company} <- call_api(...) do
  # Put them all together
else
  {:error, api_error} ->
    # Handle error
end

In terms of responses, I would have a mapper to rename keys and then you could even use Ecto to validate the final result (via an embedded schema).

def map_keys(shipping_customer, receiving_customer, line_items, freight_company) do
  %{
    shipping_name: shipping_customer["Name"],
    shipping_street: shipping_customer["Street"],
    receiving_name: receiving_customer["Name"],
    receiving_street: receiving_customer["Street"],
    # ...
  }
end

Here I actually wouldn’t use . in this case (even though it’s generally a good suggestion) to keep it simple and leave the validation for the final Schema.

Then you could make an Ecto schema for the final structure and validate it:

defmodule Thing do
  use Ecto.Schema
  import Ecto.Changeset

  embedded_schema do
    field :shipping_name, :string
    field, :shipping_street: :string
    # ...
  end

  def build(attrs) do
    %__MODULE__{}
    |> change()
    |> validate_shipping()
    |> validate_receiving()
    |> # ...
    |> apply_action(:update)
  end
end

Then the whole with would look like:

with {:ok, shipping_customer} <- call_api(...),
     {:ok, receiving_customer} <- call_api(...),
     {:ok, line_items} <- call_api(...),
     {:ok, freight_company} <- call_api(...),
     mapped_attrs = map_keys(shipping_customer, receiving_customer, line_items, freight_company),
     {:ok,  thing} <- Thing.build(mapped_attrs) do
  # Do stuff with `thing`!
else
  {:error, %Ecto.Changeset{} = changeset} ->
    # Handle data error

  {:error, %SomeHttpLibError{} = api_error} ->
    # Handle network error
end

In terms of number of params I definitely like to keep them low, but sometimes rules need to be broken! Not sure how many API calls you need to make, though, so as always, YMMV.

I do not have a hard limit for how many arguments for a function call; though I do agree that too many is a code smell. I use keyword list for options only. I’d also argue against making up map to reduce argument count. Use structs, or even Ecto. Yes, Ecto schemas can be used without a database.

Using ecto for validation of incoming data was a good advice, but using ecto for arguments is certainly an overkill, let’s not transform this topic into talking about types.

I was suggesting using structs instead of maps for arguments. Ecto might be useful to construct the structs, because there could be a need to validate the date from the (3rd party) API calls something like:

    %FreightOrder{}
    |> FreightOrder.changeset(%{
        shipping_customer: shipping_customer,
        receiving_customer: receiving_customer,
        line_items: line_items,
        ...
        })
    |>  submit!()

EDIT: seems like @sodapopcan already suggested that.

Structs are a great idea, I always use them, but totally forgot about them now!

Speaking about this question in general, it was not about validating data, but passing arguments around, so a map is a perfect wrapper for this kind of business, as are structs. There are cases where structs are better than maps and vice-versa, but for a beginner I think that presenting ecto structs as a good pattern to write code is a misguidance.

If the suggestion is around trying to clone strict typing in elixir, then that is a 100% anti-pattern in itself.

For a bit more context, many of our API calls return pretty large JSON responses. For now, we’ve tended to just work with string based keys because we’re worried of the atom limit, though we haven’t truly stressed tested that.

The example above would tend to produce a more deterministic set of keys for each API call, but we definitely have other parts of the codebase where the JSON response is much less deterministic.

You should definitely use string keys for JSON responses AFAIC pretty much exactly for the reason you stated. I also find it’s good signal to mean “untrusted.”

The idea of using Ecto is Schemas is to bring that under control. Convert the JSON into a known shape before it’s fed through the rest of your code. So you could end up with code something like: shipping_name: response["shipping_custoer_name"] || response["shipping_name"] || response["some_other_key"] or whatever logic you need. I made the mistake of only showing example of validation. Validation would only fail if something crucial is missing, but otherwise use the changeset to wrangle keys into something known, even if some are blank.

Of course, if you are blindly picking off keys and doing something with them without ever knowning what they are called then this isn’t possible. It does depend on use-case, of course.

A struct has one definite advantage over using plain maps is that you define what should be in that structure and what should not be there. It gives you much better control over the data. And as structs are implemented using maps it is just as efficient as using maps directly.

Agree, but defining structs with 2-4 keys can be too verbose in some cases. I don’t say I’m against it, however using structs excessively can lead to obscure code that is hard to read, after all code clarity is as important as compile-time guarantees.