Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo • Hacker News Board

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

#81

Post by fouc » Mon, Apr 22, 2019, 6:48 AM UTC

xlii wrote: 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,…

I assume you're keeping Elixir/Phoenix as RESTful api, and then React on the front-end? I've heard Redux suffers from similar issues with complexity, so what will you do?

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

#82

Post by pmontra » Mon, Apr 22, 2019, 6:48 AM UTC

xlii wrote: 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,…

Similar experience but without GraphQL. We had server side rendering with a Node server. Our production server became a Node farm with Phoenix + PostgreSQL requiring less than 1 GB of RAM and Node using at least 8 extra GBs. We eventually ditched SSR, send the React app and wait for it to render. We're back to 1 core and (mostly unused) 4 GB. It's a business application with complicated UI, customers don't mind waiting a couple of seconds of they want to start from a bookmarked screen.

For a simple UI I'd generate HTML server side with eex and spare us the cost of front end development. It's also a productivity nightmare. The amount of work needed to add a single form field with React/Redux is insane.

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

#83

Post by dlib » Mon, Apr 22, 2019, 6:59 AM UTC

rossenberg79 wrote: post #30

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).

In this specific case it is also because Absinthe/graphQL subscriptions are built upon Phoenix channels so if you plan to use subscriptions, Phoenix is the easiest route.

Phoenix also is pretty minimal layer over Plug, especially if you don't include the html library.

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

#84

Post by out_of_protocol » Mon, Apr 22, 2019, 7:11 AM UTC

bitcrusher wrote: post #37

rossenberg79 wrote: post #30

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).

Yep! Just use Plug. There’s no need to drag the entire Phoenix stack in. https://hexdocs.pm/plug/readme.html

Then you'll need to create own version of migrations, routing, configure asset building pipeline etc etc etc. Phoenix have everything in place, without need to re-implement lots and lots of basics

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

#85

Post by y4mi » Mon, Apr 22, 2019, 7:12 AM UTC

xlii wrote: 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,…

> * Right now we’re disassembling app to a classic REST-app*

still with elixir/phoenix or did you scrap even that part?

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

#86

Post by dafrie » Mon, Apr 22, 2019, 7:17 AM UTC

pmontra wrote: post #82

xlii wrote: 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,…

Similar experience but without GraphQL. We had server side rendering with a Node server. Our production server became a Node farm with Phoenix + PostgreSQL requiring less than 1 GB of RAM and Node using at least 8 extra GBs. We eventually ditched SSR, send the React app and wait for it to render. We're back to 1 core and (mostly unused) 4 GB. It's a business application with complicated UI, customers don't mind waiti…

Just a quick one: why would you need redux for forms? This is in my opinion a total overkill.

I have forms either having their own state or (preferred) just use Formik for all of this. In my stack, this then allows to just add a field in the GraphQL schema (backend), add it in the query, add the formik field + yup validation and done.

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

#87

Post by hakanito » Mon, Apr 22, 2019, 7:30 AM UTC

sickcodebruh wrote: post #39

hakanito wrote: post #12

Earlier quoted context omitted.

Fwiw we’ve had a lot of success with Golang (graph-gophers/graphql-go w/ dataloader). Running in prod for about a year. Worth noting is that any GQL server implementation not written in JS, will play catch-up to the JS/Apollo counterpart. The JS ecosystem just moves so much faster

Before having success with Go, did you try or consider any other languages for your GraphQL server? What about other GraphQL libraries in Go?

Our backend is mostly Go so we _had_ to make it work. Tried most of the available libraries, gqlgen etc. But eventually settled on this one because of the schema-first approach and nice resolver api. And the defacto golang dataloader lib is from the same author.

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

#88

Post by kuon » Mon, Apr 22, 2019, 7:37 AM UTC

I just started a new app, and I decided to try Phoenix LiveView. It's really simpler and easier to work with. It won't work well with all kind of apps, especially those with offline support, but for many many apps/website it is a good fit.

The last app I did was a mobile app written in Elm with Phoenix. I can't recommend Elm enough, it makes JS much easier to work with. For communication I used a simple REST oriented API.

While I understand why GraphQL exists, I think it is a major addition in complexity for little to no benefits. I tried it, wrote half a project with it, but they removed it. When things gets complex (for example, let's say the user.email field can be redacted under some conditions) your endpoint becomes really hard to manage. GraphQL certainly have a use for large API with graph oriented datasource (well, like facebook), but it is a specific use case.

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

#89

Post by cuddlecake » Mon, Apr 22, 2019, 7:44 AM UTC

sugarpile wrote: post #29

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…

My main issue with elixir dev jobs is, that they are usually not just "request/response", because elixir offers so much more with OTP.

At least that's what's holding me back.

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

#90

Post by jypepin » Mon, Apr 22, 2019, 8:01 AM UTC

dafrie wrote: post #86

pmontra wrote: post #82

Earlier quoted context omitted.

Similar experience but without GraphQL. We had server side rendering with a Node server. Our production server became a Node farm with Phoenix + PostgreSQL requiring less than 1 GB of RAM and Node using at least 8 extra GBs. We eventually ditched SSR, send the React app and wait for it to render. We're back to 1 core and (mostly unused) 4 GB. It's a business application with complicated UI, customers don't mind waiti…

Just a quick one: why would you need redux for forms? This is in my opinion a total overkill. I have forms either having their own state or (preferred) just use Formik for all of this. In my stack, this then allows to just add a field in the GraphQL schema (backend), add it in the query, add the formik field + yup validation and done.

Some people would argue that if using Redux, also having local state logic is an anti pattern.

That would mean that if you use Redux, a form also requires actions for form update/submit/success/error and the form data should be stored in the redux store.

That is one of the main issues I have with Redux, which I feel adds automatic complexity for simple things, but at the same time I'm not sure if it's very good to have a mix of tings happening from store/actions/reducers and others from local state/ajax.