Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

schneider.dev

Post reply on HN
Print view View original

121–130 of 155 posts

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

#121

Post by mwcampbell »

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…

Any idea why SSR used so much RAM? I wonder if the virtual DOM approach of React contributed substantially to it, and whether something like Svelte (https://svelte.dev/) would do much better.

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

#122

Post by mwcampbell »

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,…

Unless I'm missing something, Hasura requires much less effort on the back-end than what you're describing with Absinthe. Hasura runs in its own process (or processes; it doesn't have any state of its own so it can scale), and it can deliver events to your back-end via webhooks, so it doesn't matter what language you use for the back-end.

As for file uploads, it seems to me that the best way to do that is to have the front-end upload directly to your cloud storage service. Both S3 and Google Cloud Storage have a feature called signed URLs, where your back-end can create an object, grant the necessary permission, then give the client a temporary URL to upload to that object. Then just store the URL in the database.

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

#123

Post by pmontra »

mwcampbell wrote: post #121
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…

Any idea why SSR used so much RAM? I wonder if the virtual DOM approach of React contributed substantially to it, and whether something like Svelte ( https://svelte.dev/ ) would do much better.

We investigated it a little then decided that finding a proper solution wasn't worth our time. This is what we discovered.

We had a pool of 4 Node instances which is the default of the solution we were using (a patched version of https://github.com/hassox/std_json_io)

Each Node instance has a 1 GB memory limit (the heap? It seems Java like). We failed to find a way to raise it but, again, we didn't invest too much into it except some googling. It seems there used to be a command line option for that but it doesn't work anymore.

Each hit to Node raises the memory usage until it gets to 1 GB and throws an error and gets recycled, which unfortunately translates to a 502/503 to the client. We can intercept those errors in Elixir and try again but it's far from ideal.

To have less errors we naively decided to increase the number of workers but we also had to increase the RAM of the server. The first hit for each client gets served by Node so eventually Node's resource usage dwarfed Elixir's. We felt like we were doing it wrong (I'm sure there is a way to get a saner setup) and decided to turn off server side rendering. Nobody complained and we're saving some $40/50 per month on that single server, plus our time which is worth more than that.

I think that projects with little load should run on low tech uncomplicated solutions: a reverse proxy and an application server were enough in the 90's for the same scenario and are still OK now.

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

#124

Post by pdimitar »

regularfry wrote: post #92
lame88 wrote: post #41

Earlier quoted context omitted.

Expect a long journey if you’re trying to get to the state where you can make a web app. I am making a conjecture here but from my limited but nontrivial experience it seems libraries in the applications ecosystem of haskell apply the most advanced features they know of to solve their problems. That would normally be fine, but they do not abstract away this complexity; due to the type system’s rigor, these choices ar…

The problem I have with Haskell for getting anything actually done is that nothing I try to do actually works . I mean in the basic "try out the tutorial to learn the thing and be able to get to the end without an error I don't have enough experience to debug" sense. Stack should help with this, but it doesn't when the versions you get (and function signatures of those versions) have changed since the docs were writt…

Every time I see how many variants (and flags) the GHC has and I am like "feck no, I'll check it out again next year". But I think it's a culture thing in that community and it won't ever change.

That's what one of the things that's kind of making me give up on OCaml as well although there things aren't that bad.

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

#125

Post by pdimitar »

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

Don't let the history of other languages and frameworks fool you: Phoenix is a very minimal set of helpers over the much more bare Plug/Cowboy setup. And it's very easy to strip away parts you don't need.

The fact that you'll have 4-20 small(ish) boilerplate files on a brand new project isn't the end of the world and it gives you a lot of flexibility later.

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

#126

Post by pdimitar »

iends wrote: post #57
onebot wrote: post #54

I have just starting learning Elixir and Phoenix. It seems like a solid replacement for Rails. But I keep getting hung up on performance. With React, it seems like you are developing more API back-end, then web server back-end (if that makes sense). But when you look at the performance compared to Go and the steeper learning curve, why not just use Go? Kubernetes really solves the share-nothing let-it-fail aspect. Ob…

For non-stateful services, it seems very difficult to me to convince people to use Erlang/Elixir over Go. It also seems to me that Go is going to be more maintainable over time than Elixir. Also, Elixir has smaller corporate backing compared to Go. fwiw, I work at a telecommunications company and I've had no success convincing anybody to use either Go or Erlang/Elixir over Java (& Clojure).

You seem to list political / culture / habitual phenomena here. Care to list technical argumentation instead?

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

#127

Post by iends »

onebot wrote: post #60
iends wrote: post #57

Earlier quoted context omitted.

For non-stateful services, it seems very difficult to me to convince people to use Erlang/Elixir over Go. It also seems to me that Go is going to be more maintainable over time than Elixir. Also, Elixir has smaller corporate backing compared to Go. fwiw, I work at a telecommunications company and I've had no success convincing anybody to use either Go or Erlang/Elixir over Java (& Clojure).

That’s ironic considering that Erlang was designed for telecommunications. But I think statefulness is the right context between the two. Why do you think Go would be more maintainable?

I realize dialyxir exists, but I think a lack of static typing can lead to some maintainability issues over long term. At least this is my experience working on a 6 year old JavaScript codebase.

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

#128

Post by beckler »

kuon wrote: post #88

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…

I want to like Elm, but every time I try to pick it up it's always my biggest time sink.

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

#129

Post by pdimitar »

hestefisk wrote: post #19

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?

* Unified tooling (`mix`).

* Tests inside documentation.

* Macros.

* Protocols.

* `mix xref` has a family of sub-commands that gives you good code analysis (callers, callees etc.)

* First-class Unicode support. All strings are UTF-8 by default (you can fallback to ASCII if you need it; there are also good transcoding libraries in both Elixir and Erlang).

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

#130

Post by pdimitar »

sntran wrote: post #113

It always bugs me that, with Absinthe, you have to define Ecto schema and GraphQL schema separately, when most of the time, they are very similar. Can Absinthe somehow figure out from Ecto?

Always wanted something like that as well. I am guessing until we get something like `clojure.spec` -- true typing, even if gradual (but at least not a success-typing) -- then it's not happening anytime soon.
Post reply on HN