Experimental Shopify API client, feedback wanted

Longtime rubyist, I’m very new to Elixir and have been looking for projects to experiment on. Our company does a fair amount of work building app integrations on the Shopify platform, and when we want to scaffold out REST API clients in ruby we often use a fairly simple metaprogramming pattern, which works best on APIs that have relatively uniform naming / return values.

As an experiment I tried to sort of port this metaprogramming idea to an Elixir Shopify API client (the only existing one I could find is boulevard/shopify and lacks most of the endpoints). The library I built is here: https://github.com/themgt/shopify

I’m still just starting to wrap my head around Elixir metaprogramming, but you can see in the quite brief code it basically loops through all the first-level Shopify API endpoints and defines CRUD methods for accessing them and returning the JSON data.

I was mainly looking for some comments / examples of best practices for REST API clients in Elixir. I’m assuming I should use {:ok, _} vs {:error, _} return signatures?

Coming from ruby I find it a bit awkward passing around the struct with domain/token - any way around that, or should I change the arity so that’s first in all the methods?

Also just curious in general on the Elixir community’s thoughts on using metaprogramming in a situation like this - a lot of the documentation has a big flashing “only if you need it!” warning - wondering if it’s generally frowned upon?

1 Like

I don’t know shopify at all so just a couple of things from me. :slight_smile:

For functions, yes. If an error condition is possible (like remote server calls possibly failing) then error and ok tuples like you have there are perfect. You should not raise exceptions except in truly exceptional circumstances (they are slow, and bad form).

If it is designed to work with Plug and/or Phoenix, the usual way is to add it to the Conn structure as an assign somewhere earlier in your pipeline. If you get it during your main require you might want to factor it out higher in the pipeline so it becomes easier to handle and embed elsewhere too. Otherwise not really, you gotta pass around something. That is the usual functional programming. :slight_smile:

Only if it truly makes the interface better, shorter, more readable, and not magical; magical looking code that you cannot figure out what it is doing from looking at it is bad. Otherwise raw functions are almost always better.