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

131–140 of 155 posts

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

#131

Post by iends »

pdimitar wrote: post #126
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).

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

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 toolset is a lot more to grok. Deploying code with Go is also easier than Erlang/Elixir. Static typing is also pretty huge (dialyxir seems more like a bolt on).

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

#132

Post by yawaramin »

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.

Or use the browser's built-in form state management: https://medium.com/@everdimension/how-to-handle-forms-with-j...

Bonus: it's almost certainly more accessible than custom solutions.

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

#133

Post by pdimitar »

iends wrote: post #131
pdimitar wrote: post #126

Earlier quoted context omitted.

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

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 C/C+, C#, Java, or JavaScript.

In every single area of my life I found out that what is cheaper at the start always ends up hugely expensive later. But I am not here to argue life philosophy. Just a quick tidbit.

> Elixir is a much larger conceptual leap in that it is functional

True. I still found the investment very worth it though, even after I spent 14-15 years with OOP / imperative languages before that, mind you. But that's a matter of personal career choice.

> Static typing is also pretty huge (dialyxir seems more like a bolt on).

This is undeniably one of the big weaknesses of Erlang/Elixir (and the BEAM languages in general). It made me try and reach for languages like Go and OCaml.

Go is pretty easy but extremely verbosive. Also the imperative languages' tendency to always show you how you are doing things instead of the what you are doing (namely the way of the functional languages) is something that is poking my eyes out lately, for the better or worse. Additionally, people use Go's typing escape hatch (`interface{}`) way too often, to the point that the typing system feels completely optional.

OCaml I like quite a bit, and its typing system is world-class. Lightning-fast compilation times are a huge productivity boost, one I didn't expect. But lack of even basic parallelism wrappers is pretty off-putting (I am not counting convenient pthreads-like DSL, they are just that and nothing else).

All in all, I'd still go for Elixir for 90% of what I ever do due to its preemptive scheduler and very friendly parallelism and concurrency story. And higher-level tools -- like Broadway -- keep getting added.

The BEAM languages are not a panacea. That's a fact. They seem to fit excellently in the web programming though.

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

#134

Post by AlchemistCamp »

TN1ck wrote: post #94
AlchemistCamp wrote: post #75

The project I've been working on the past couple of months is a very similar stack to this—Phoenix, Absinthe, Apollo, React, Redux. The main difference is I've been using TypeScript and the Absinthe resolvers are using Dataloader.

How's the integration of Apollo and TypeScript? Do you like the stack and would you recommend it?

Both apollo-client and react-apollo ship with definitions in their npm packages, so using TypeScript with Apollo isn't a problem.

I don't like the stack. It's way too heavy. If I were building everything again now, I'd go with a standard Phoenix app and ditch Redux for sure and hold off on fullblown front-end frameworks and Graphql.

I'd ship v1 with Phoenix, UJS and Turbolinks, and it would take 1/4 the time. Then, if the project grew to where it needed and could support a larger team, I'd bring in Absinthe, Apollo and then finally Vue.

My main recommendation would be to keep things as simple as possible for as long as possible. Use something like Phoenix or Rails or Laravel and get stuff shipped.

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

#135

Post by volkk »

srndh wrote: post #105
simonw wrote: post #40

Earlier quoted context omitted.

Smart teams hire great engineers and trust them to get good with the stack at hand. Don't get hung up on how much experience you have with a particular stack when looking for jobs. I've hired Rails developers for Django roles and seen them get productive within weeks. If you've used Elixir on-and-off for four years you have more experience than the majority of engineers who might be considered for an Elixir role.

> I've hired Rails developers for Django roles and seen them get productive within weeks. What did you like about the Rails developer that you chose the person for the role? Basically, I want to know irrespective of the language, how do I show my "quality as an engineer"?

oh it's simple, you just have to invert a binary tree

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

#136

Post by out_of_protocol »

Xixi wrote: post #112
out_of_protocol wrote: post #84

Earlier quoted context omitted.

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

A bit pedantic, but migrations are provided by Ecto [1], not by Phoenix. You don't need Phoenix to use Ecto. https://hexdocs.pm/ecto/Ecto.html

Well, you'll still need to add Ecto, configure it to use separate configs for prod/dev/test environments etc - so point still stands :)

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

#137

Post by out_of_protocol »

schneidmaster wrote: post #20
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?

It's 100% the syntax. It appeals to ruby devs and also I think it's a lot easier to grok in general. But you can write Erlang code directly in an Elixir file, you can use Erlang libraries directly in Elixir, and Elixir compiles to the same BEAM instructions that Erlang does, so there's functionally no difference in terms of capabilities or what happens when they run.

* consistent standard library (huge win IMO)

* efficient utf8 binary strings (which is actually conforms with utf8 standard), no mixup with charlists

* mix etc standard tooling

* macros

* enum stuff

* pipeline operator "|>", which by its mere existence enforces input/output param's consistency in user-written functions

etc

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

#138

Post by brianpgordon »

slashdotdash wrote: post #99
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,…

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.

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

#139

Post by lame88 »

quickthrower2 wrote: post #52
jsjohnst wrote: post #51

Earlier quoted context omitted.

> 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. Apologies to others for the “me too” reply, but I wanted to let you know you aren’t alone, I also feel this way. It’s intellectual masturbation (without any reward/benefit), IMHO.

Haskell is a funny beast because I get a lot of joy from “conquering” the next level up (like a game) but in terms of productivity I’m not getting a lot done. OTOH in more pedestrian languages I’m using that brain BHP on getting stuff done. I really got into the Haskell thing a while back, going to meetups etc. but getting a job using Haskell is hard unless you’ve got experience already and want to take a pay cut.

Agreed - it certainly is rewarding in itself to get to the next level, but that's precisely it: the means become ends in themselves. I stopped using stuff like Arch Linux a while back for similar reasons.

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

#140

Post by lame88 »

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…

I'm not familiar with Cloud Haskell, but I can attest that documentation and information availability in general have become a huge priority for me recently after getting burned by lack of it in recent years. This is actually very tricky to nail a sweet spot in, because it almost requires that a technology be currently popular, yet stable. There are long-lived Haskell libraries that have poor documentation and Haskell is rare enough that there aren't often answers to common pitfalls on StackOverflow etc. Ruby on Rails still has ongoing releases, but its popularity has declined and apparently so has its sources of community information beyond the official docs, which only cover so much. And then you have the immature, fast-moving JS ecosystem. Ironically for these reasons I could easily see myself choosing Java for projects in the near future; I don't like the language, but I've learned that the problems I have with Java are not my biggest problems as a professional engineer anymore.
Post reply on HN