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

61–70 of 155 posts

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

#61

Post by jaequery »

diNgUrAndI wrote: post #16

> I also find a lot of joy in its pattern matching and its pipe operator. It’s refreshing writing heavily functional code that still approaches the beauty of ruby, and I find that it drives me to think clearly about my code and write fewer bugs as a result. This. I use Elixir everyday. While it feels 'refreshing' to use pattern matching, sometimes it gets over-used, as a simple swtich-case statement is easier to read…

Doesn’t pattern matching lead to either more verbose code or a duplicate code? Most of the time?

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

#63

Post by anthony_doan »

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

You can have Phoenix serve API endpoints and not include the phoenix html template package in your mix files.

> I’d prefer a simple React, Postgres, Elixir stack (REP).

That's not even a web stack. Web stack for example LAMP include a web server (Apache) or something that is able to response to client request. Elixir is a language it can't serve anything. You need cowboy or something and then build around it. Or you can just use Phoenix.

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

#64

Post by harrygeez »

SaltyBackendGuy wrote: post #17
adamnemecek wrote: post #4

Ok, for backend, I’m deciding between rust with actix, jvm (kotlin + akka/quasar) or elixir. I kinda know the theoretical differences but I’m curious what hn thinks. Has someone actually deployed things in some of these. I do have preference towards rust but maybe there’s something better.

Dotnet Core is actually really nice as well, I think v3 is right around the corner. Something worth checking out if you're looking into beckend technologies. I've been using it lately, coming from Node.js for the last few years, and it's been a really nice change.

I've been on the fence about trying dotnet core for perhaps too long. What do you like about it?

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

#65

Post by hdra »

jaequery wrote: post #61
diNgUrAndI wrote: post #16

> I also find a lot of joy in its pattern matching and its pipe operator. It’s refreshing writing heavily functional code that still approaches the beauty of ruby, and I find that it drives me to think clearly about my code and write fewer bugs as a result. This. I use Elixir everyday. While it feels 'refreshing' to use pattern matching, sometimes it gets over-used, as a simple swtich-case statement is easier to read…

Doesn’t pattern matching lead to either more verbose code or a duplicate code? Most of the time?

It could, when its used "wrong", though thats usually a result of trying to fit pattern matching where there are other more idiomatically way to express a code. I wouldn't say "most of the the time", its more of a common beginner's mistake.

Pattern matching allows you to express the code in a more declarative way, and usually would result in a more succinct code.

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

#66

Post by anthony_doan »

sk5t wrote: post #53
anthony_doan wrote: post #13

Earlier quoted context omitted.

Erlang/Elixir's VM is gear toward high uptime, low latency, and highly concurrent. https://stressgrid.com/blog/100k_cps_with_elixir/ What it's not good at is numerical computation. As for the others I have no clue but I am sure jvm won't be as low latency as Elixir's VM since it's not a preemptive scheduler.

I think a lot of folks writing low latency code in C, or for the JVM, would be surprised at the suggestion a lack of preemptive scheduler makes their work futile.

If those folks enjoys writing low latency code in C for backend... I'm not going to stop them. I'll sit in a corner somewhere and enjoy Elixir.

There's a JVM vs BEAM VM comparison paper (http://ds.cs.ut.ee/courses/course-files/To303nis%20Pool%20.p...).

I believe section 2.2. ERTS of the paper talk about BEAM VM advantage for low latency.

> The per process heap architecture has manybenefits, one of which is that because each pro-cess has it’s own heap and there are presum-ably numerous process’s,...

update:

Ah... I think the relevant part is in 3.3 Lightweight threads.

> 3.3. Lightweight threads

> The effect is that Erlang is one of a fewlanguages that actually does preemptive mul-titasking. The reduction count of 2000, whichis sub 1ms, is quite low and forces many smallcontext switches between the Erlang processes.

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

#67

Post by schneidmaster »

anthony_doan wrote: post #63
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).

You can have Phoenix serve API endpoints and not include the phoenix html template package in your mix files. > I’d prefer a simple React, Postgres, Elixir stack (REP). That's not even a web stack. Web stack for example LAMP include a web server (Apache) or something that is able to response to client request. Elixir is a language it can't serve anything. You need cowboy or something and then build around it. Or you…

> You can have Phoenix serve API endpoints and not include the phoenix html template package in your mix files.

Incidentally, that's what I did for the project in the blog post. If you bootstrap with `mix phx.new --no-html --no-webpack` then you get a leaner version of Phoenix that's good for an API, without the HTML and frontend asset parts.

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

#68

Post by anthony_doan »

schneidmaster wrote: post #67
anthony_doan wrote: post #63

Earlier quoted context omitted.

You can have Phoenix serve API endpoints and not include the phoenix html template package in your mix files. > I’d prefer a simple React, Postgres, Elixir stack (REP). That's not even a web stack. Web stack for example LAMP include a web server (Apache) or something that is able to response to client request. Elixir is a language it can't serve anything. You need cowboy or something and then build around it. Or you…

> You can have Phoenix serve API endpoints and not include the phoenix html template package in your mix files. Incidentally, that's what I did for the project in the blog post. If you bootstrap with `mix phx.new --no-html --no-webpack` then you get a leaner version of Phoenix that's good for an API, without the HTML and frontend asset parts.

Oh wow I didn't even know there's a command for it. Thanks.

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

#69

Post by hliyan »

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 / interpreted / JIT compiled / virtual machine based] backend runtime, built on [RDBMS/NoSQL/hybrid] etc.

Am I alone in feeling this way?

Post reply on HN