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

151–155 of 155 posts

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

#151

Post by mercer »

pmontra wrote: post #80
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).

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.

Plus it's much easier to remove stuff from Phoenix if all you need is something like Sinatra.

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

#152

Post by mercer »

pdimitar wrote: post #133
iends wrote: post #131

Earlier quoted context omitted.

Do you think language adoption in a company is anything other than "political / culture / habitual"? But in any case, Go is a very straightforward language if you're already familiar with popular languages like C/C+, C#, Java, or JavaScript. You basically just need to learn the concurrency features (goroutines/csp/select keyword). Elixir is a much larger conceptual leap in that it is functional and the currency tools…

> Do you think language adoption in a company is anything other than "political / culture / habitual"? Sadly you are correct. But what I was getting at is that I'm interested in how do you choose a language. Us the techies should strive to make technical decisions not based on politics, wouldn't you agree? > But in any case, Go is a very straightforward language if you're already familiar with popular languages like…

putting aside all the other benefits of a typed language, would you say Elixir's "let it crash" philosophy makes this even slightly less of an issue? Or are they entirely unrelated?

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

#153

Post by crowdhailer »

bobwaycott wrote: post #120
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).

If you want something simpler and more building-block, micro-framework style in Elixir, you'll want to take a look at Raxx[0]. You could also just build atop Plug itself, though Phoenix really is just a whole lot of Plug. [0]: https://github.com/crowdhailer/raxx

You might also be interested in Raxx.Kit, A project generator that gets your project started as quick as if you were using phoenix https://github.com/crowdhailer/raxx_kit

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

#154

Post by Existenceblinks »

brianpgordon wrote: post #138
slashdotdash wrote: post #99

Earlier quoted context omitted.

Phoenix Live View[1] fits the gap between server rendered HTML pages and JavaScript rendered front-ends. If you’re after a responsive web UI without needing to learn so many disparate frameworks and technologies it could be a good fit. [1] https://github.com/phoenixframework/phoenix_live_view

Phoenix Live View is very new and not appropriate at all for real-world use yet.

> Phoenix Live View is very new

Its technique is not new, it's just server-side rendering via websocket and DOM patching (Morphdom is also very old)

> not appropriate at all

"At some" would be appropriate. Pretty much typical CRUD (real world) that needs to fire requests to server anyway (e.g. form, business logic validation).

The only reason not to use it _right now today_ is it's not 1.0 yet.

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

#155

Post by brianpgordon »

Existenceblinks wrote: post #154
brianpgordon wrote: post #138

Earlier quoted context omitted.

Phoenix Live View is very new and not appropriate at all for real-world use yet.

> Phoenix Live View is very new Its technique is not new, it's just server-side rendering via websocket and DOM patching (Morphdom is also very old) > not appropriate at all "At some" would be appropriate. Pretty much typical CRUD (real world) that needs to fire requests to server anyway (e.g. form, business logic validation). The only reason not to use it _right now today_ is it's not 1.0 yet.

I'm not one of those people who think a first commit is only 6 months old it's probably not the wisest move to make it a cornerstone of your stack.
Post reply on HN