Live data from Hacker News

Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

schneider.dev

71–80 of 155 posts

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#71

Does anyone here who is working with elixir professionally have a sense of what kind of mastery is needed to jump into an elixir dev role? I've used it on and off for ~4 years at this point and in a few side projects (most recent one using everything in the title, weirdly enough) but can't really tell if I'm "qualified" to look for a job in it. It's this weird loop of "I've only done something as a hobby so I'm not q…

I don't think deep mastery of the language is needed in order to jump into a dev role. At least form my POV, as long as you know the language well enough to be productive and are comfortable with going to the docs, that's enough.

The more important thing is if you understand how the web works. I'd much rather work with an senior Rails or Laravel dev who had just been playing with Elixir for a few weeks than someone who had studied the language deeply but had little web development experience.

Gatekeepers are annoying but you can usually side step a few qualifications as long as you can do the work.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#72
post #2

I've just been trying to get back into elixir recently, myself. I'd done some basic crud 'helloworld' stuff when I first tried about a year into professional development. I've since had the Fortune to spend time learning about cloud native apps, distributed service patterns, and supporting infrastructure (spring cloud, pcf, vanilla k8s, gcp) and now returning to elixir having at least better understanding of what erl…

I'm a big fan of both the Manning and Pragprog books.

Even if you've worked at it a bit already, you'll probably get something out of doing the first dozen or so challenges on my channel as well: https://youtu.be/G3JRv2dHU9A?t=595

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#73

Good read. Curious about Elixir. Why would one use this over ‘plain old’ Erlang / OTP apart from the Rubyesque syntax, which might appeal to RoR devs?

> Why would one use this over ‘plain old’ Erlang / OTP apart from the Rubyesque syntax

The two really big features are macros and protocols.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#74
post #69

Great article. One point though (not aimed at the author). The majority of engineering articles I see today are along the lines of "X with Y, using Z", where X, Y, Z are specific products, frameworks or libraries, often trademarks. I rarely see more generic engineering/architecture topics such as: [virtual DOM based / string based client side templating] with [JSON/Protobuf] over [REST/Websocket] with a [compiled / i…

I'm actually writing a tutorial series aimed at programming beginners where we implement things in multiple languages/frameworks side by side.

I think it's a great way to learn concepts of software engineering instead of just memorizing conventions.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#76

Hey folks! Co-Author of Absinthe here, happy to answer any questions about it. The post here is good, although these days we recommend using Dataloader vs Absinthe.Ecto. Dataloader really extends the idea behind Absinthe.Ecto while providing in request caching, pluggable backends, and easier query manipulation.

I've got an app with back-end oauth-based login. I had a bit of a headache integrating the sessions with Absinthe and finally arrived on this in my Context module:

```

  def call(conn, _) do
    context = build_context(conn)
    Absinthe.Plug.put_options(conn, context: context)
  end

  def before_send(conn, %Absinthe.Blueprint{} = blueprint) do
    if blueprint.execution.context[:logout?] do
      Auth.drop_current_user(conn)
    else
      conn
    end
  end

  defp build_context(conn) do
    with ["Bearer "  token]  %{}
    end
  end

  # rest of the file
```

Then made a Logout middleware that sets logout? to true in the resolution context.

Is digging into the Blueprint as in the code above necessary? Is there a simpler way of solving this?

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#77
post #69

Great article. One point though (not aimed at the author). The majority of engineering articles I see today are along the lines of "X with Y, using Z", where X, Y, Z are specific products, frameworks or libraries, often trademarks. I rarely see more generic engineering/architecture topics such as: [virtual DOM based / string based client side templating] with [JSON/Protobuf] over [REST/Websocket] with a [compiled / i…

I'm actually writing a tutorial series aimed at programming beginners where we implement things in multiple languages/frameworks side by side. I think it's a great way to learn concepts of software engineering instead of just memorizing conventions.

I like this idea. Especially if you give a high-level overview of software design concepts.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#78
Stack described above is the one I’ve been working on for professionally for the last year and I wouldn’t recommend it.

Main reason is the absurd amount of complexity with costs heavily outhweighting benefits gained from the solution.

For example, simple task of adding new entity consists off: On backend: creating migration, creating data entity (Ecto), writing structure module (sanitization, validation, basic logic, if needed), mounting queries, writing input mutation(s), writing output query/queries, unit testing On frontend: creating component, creating form, writing graphql queries, writing mutation, wrapping components/queries in components, connecting query to components, providing action handlers for inputs, unit testing, integration testing

Now I have authors list. And even though I am full stack I haven’t yet spent even single minute on having Proper UX Design set in place. Oh, do we need to add author’s birthdate? Dang, let me adjust all of that.

In my opinion technical debt accumulates faster than in other solutions. GraphQL is complex. React (done right) is complex. Apollo is complex (Elixir is simple, yet it’s only one cog). Deciding on doing file upload in GraphQL led me to a rabbit hole, which took at least a week to dug out from.

When trying to find the source of all development issues my thoughts go towards GraphQL. Maybe it is too complex or we didn’t had enough experience in it? Yet it was really nice to work with when all the backend and frontend boilerplate was already written. It makes sense, even though requires some heavy thought behind it. Maybe it’s Apollo, which locks in one of two specific trains of thought, or Absinthe, which requires side-hacks in order to get some bit more advanced features working with Apollo, like file uploads or query batching.

From a perspective I’d say this is just too much. Every single part of this stack adds overhead to the other parts. Maybe if I had more specialized team members it would get easier, but being only 3 of us, with me, as a full stack, constantly switching between all of that was a tiresome, low-productive effort. Right now we’re disassembling app to a classic REST-app and we’re seeing development speed increase on week-to-week basis, even though we had to scrap most of the frontend.

I guess there would be some benefit on having the write up of all of it, since it doesn’t even scratch the surface of the year of development issues with this stack, but even in this very "short" form it may serve for a word of warning that this stack is not necessarily something you want to care for.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#79
post #78

Stack described above is the one I’ve been working on for professionally for the last year and I wouldn’t recommend it. Main reason is the absurd amount of complexity with costs heavily outhweighting benefits gained from the solution. For example, simple task of adding new entity consists off: On backend: creating migration, creating data entity (Ecto), writing structure module (sanitization, validation, basic logic,…

Thanks for this. I'm not a web dev, but yes, after seeing the 3rd or 4th "and then we do this" I've just started scrolling towards the end of the post and got bored fairly quickly. My thoughts exactly: this seems way too complex for creating just a few pages; too many dependencies, too many things to remember and update.

Re: Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

#80

Why is Elixir always being paired with Phoenix? Can’t I just have a backend API running on Elixir and a javascript front end to interact with it? I’d prefer a simple React, Postgres, Elixir stack (REP).

Same reason why Ruby web apps are usually written in Rails: familiarity with the tool plus you end up rewriting most of Rails as soon as your app is not a toy (tests, flexible router, associations between models, migrations). After some experiments with Sinatra years ago I always start with Rails now.
Post reply on HN