tesla VS mint

I haven’t used commanded, exmachina, or ash:

- Tesla has a mode which can be used completely without macros, and I am increasingly encouraging that it be the only way that it is used. So does the author (as of 2020): https://github.com/elixir-tesla/tesla/issues/367#issuecommen...

There is also `req` mentioned in a recent post as an alternative (it looks good, but I am still playing with it to see if it is a suitable replacement for Tesla in all cases).

- Absinthe is something of a compiler itself, because it has to strictly define things the way that is specified in the GraphQL spec. You can now import an SDL file, but you still need to hook resolvers and middleware into it. Honestly, I don’t think that the schema definitions in JS/TS are much better for GraphQL in terms of readability.

Being heavily macro-based means that there are sharp edges that are harder to work around when you want to add your own macros for code reuse purposes. That said, aside from the schema definition, Absinthe is entirely usable without macros. Within the schema definition, Absinthe isn’t making anything up, it’s using the same basic definitions that the GraphQL spec do, adapted for Elixir syntax.

Exmachina didn’t interest me because I don’t think much of factory_bot (which used to be called factory_girl), as I saw it abused far more than used well (IMO, it’s impossible to use correctly). Ash…looks like an interesting experiment, but I don’t know that there’s a lot of pick-up with it compared to Phoenix. And I have yet to find a use for CQRS/ES, so there’s no reason for me to play with commanded. I certainly wouldn’t consider any of these three to be "major" players in Elixir. Tesla and Absinthe? Yes.

tesla

To integrate the API via Elixir let's use the HTTP wrapper Tesla. There are many good options out there, such as the good old Httpoison. However, Tesla has some added benefits. I won't go into details as it's not the purpose of this article, but it's worth checking out.

One example is HTTP libraries.

For instance, take Mint (https://github.com/elixir-mint/mint):

> Mint is different from most Erlang and Elixir HTTP clients because it provides a process-less architecture.

Mint is a low-level library which doesn't make attempt to manage processes (including HTTP pooling).

In contrast, Finch (which builds on top of Mint) includes pool management:

https://github.com/elixir-mint/mint#connection-management-an...

It can take someone a bit off guard when they realise that the library they use provide a "default pool" they were not aware of, and that it can become a bottleneck etc.

> no error checking at all

Functions that raise always end in `!` in Elixir, or at least they should. Most have alternatives that return error tuples instead which you can pattern match on (this is what I recommend). You can read the docs for `get/2` (as opposed to `get!/2` which raises) here: https://hexdocs.pm/req/Req.html#get/2.

A common pattern is for the `!` version to call the version that doesn't raise, check the result, and raise on error, which is the case here: https://github.com/wojtekmach/req/blob/9de30de0df481ee557ccc...

> and if "body" is JSON, how do you even get the raw body, or can you?

You would set `decode: false` when calling `get!/2: https://hexdocs.pm/req/Req.html#new/1. You can also set this as configuration with https://hexdocs.pm/req/Req.html#default_options/1.

As a closing note I'll mention that Req is intended to be a very high-level, scripting-friendly requests library, similar to Requests in Python. If you don't want conveniences like Req provides, you can either turn them off or use something different, like Finch (which Req is based on, https://github.com/sneako/finch). Other than Req and Finch I'm personally only familiar with HTTPoison, which is significantly older than all of the libraries derived from Mint (like Finch and Req, https://github.com/elixir-mint/mint) but still works. There are many others though, like Gun and Tesla and such.