I’m mid-project on a small webapp with a Elixir / Phoenix back end and Elm front end. The Phoenix app uses Absinthe to create the GraphQL endpoint. The Elm app communicates to the back with elm-graphql.
It works. It’s pretty cool. I wouldn’t recommend it. The app we’re building is fairly small and straight forward with 5 pages and if it were a straight Phoenix/Liveview app it would have been done in about one third of the time. I’ll be charitable because this is our first Elm project outside of a tutorial and say that adding Elm and GraphQL roughly doubled the implementation time.
Absinthe automates most of the set up for the graphql endpoint, but it has some rough edges that elm-graphql package dogmatically turns into some nasty types like Maybe (List (Maybe Foo)) that then add a lot of clutter to your Elm code. The Elm-graphql library illustrates what I feel to be a big rift in the philosophy of writing documentation between the Elixir and Elm communities. Elm docs for most packages generally feel very incomplete and are coupled with a few meager examples that are equally poorly documented.
Mostly I feel that by the time you set up an API and a front end SPA you’ve taken away all the big productivity boosters from Elixir/Phoenix/Ecto web apps. There’s also a very big paradigm change every time you switch contexts front-to-back end since Elixir has a lot of conventions built into it (productive as long as you follow them) and Elm is more “here’s a few powerful tools to go write whatever you want”. There’s no real synergy gained by the combination.
I feel like I’m the only person so far with a negative take so I’m watching this thread closely to see if there’s something I’m missing.
although for the one specific problem you mentioned:
