themgt
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: GitHub - themgt/shopify: Experimental Elixir Shopify API Client · GitHub
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?
Where Next?
Trending in Announcing
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Phoenix, LiveView, multimedia pipelines, distributed systems. 400 engineers, Elixir since 2017. Available for hire.
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
- #blog-post
- #elixirconf-us
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #security
- #elixirconf-eu
- #api
- #forms
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 1- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
OvermindDL1
I don’t know shopify at all so just a couple of things from me.
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.
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.