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

101–110 of 155 posts

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

#101

Post by glun »

anthony_doan wrote: post #66
sk5t wrote: post #53

Earlier quoted context omitted.

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

Java will get lightweight threads soon. You can google "java fibers".

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

#102

Post by andrewingram »

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…

Hm, I disagree on the last point. GraphQL's utility has nothing to do with whether you have a graph-oriented database. The "graph" part is merely talking about the means by which queries traverse the type system. Since REST APIs can easily be modelled as a GraphQL schema, they have a lot of overlap in utility.

Basically, if you need "API-driven" front-end, the only thing that might make harder than REST for a given language is lack of libraries. If you don't need API-driven, then just do things the traditional way, or try Phoenix LiveView.

The one caveat is that GraphQL (especially with Relay) maps exceptionally well do the component-based way of building things. So if you've chosen that paradigm, GraphQL might still be a good fit, even if you're just building a website.

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

#103

Post by srndh »

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

> Stack described above is the one I’ve been working on for professionally for the last year and I wouldn’t recommend it.

Any alternatives that you would like to suggest?

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

#104

Post by srndh »

ngngngng wrote: post #74
hliyan wrote: post #69

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 / i…

I'm actually writing a tutorial series aimed at programming beginners where we implement things in multiple languages/frameworks side by side. I think it's a great way to learn concepts of software engineering instead of just memorizing conventions.

> we implement things in multiple languages/frameworks side by side.

please do post the link.

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

#105

Post by srndh »

simonw wrote: post #40
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…

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"?

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

#106

Post by Draiken »

xlii wrote: post #98
aspett wrote: post #93

Earlier quoted context omitted.

> Maybe if I had more specialized team members it would get easier It really would be easier. We are using this stack, and have separate backend and frontend devs. Each love their side of the stack. Being backend myself, I don't find the it too time consuming to get new entities going. However, I imagine if you were doing the whole stack and repeating ecto schema, absinthe schema, apollo queries, then it might get mo…

That was one of the reasons I choose this stack. The plan was hiring team just after stack was set. Unfortunately financial plans toppled and we (2 full stacks + front end UX) were stuck with very complex architecture designed for ~10. If I would be to working on only 1 part it would be great, but instead of parallelizing effort it was sequenced which kind of sucked.

It's early optimization at the architecture level. I've seen it happen so many times.

On top of all you said, the GraphQL stack is horrible for caching. You will not have this problem until you reach really high traffic, but once you do, it will eat you alive.

Unlike a rest endpoint, you can't cache a URL. You can't use HTTP headers. You don't know beforehand what GQL query will come and even with batch queries for different types it's super hard to optimize. It's very easy to have an N+1 query hell.

The lesson I learned is to use the boring stuff until it really needs to scale up. A REST API with static HTML and some sprinkles of JS will get you to the phase where you actually need to start using React, GQL, etc.

GQL trades a lot of things for flexibility, but 99% of the apps don't need that in the first place.

But hey, on the upside everyone can put in their resumes that they used all the new hot shit :)

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

#107

Post by namelosw »

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 want to say Any sufficiently complicated REST API contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL API.

Although complex, GraphQL (done right) is much easier than REST (done right).

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

#108

Post by sickcodebruh »

hakanito wrote: post #87
sickcodebruh wrote: post #39

Earlier quoted context omitted.

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.

Makes sense. Thank you!

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

#109

Post by ryanbrunner »

namelosw wrote: post #107
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 want to say Any sufficiently complicated REST API contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL API. Although complex, GraphQL (done right) is much easier than REST (done right).

The real key part of this phrase is "sufficiently complicated". GraphQL shines in certain scenarios, but not every API needs this complexity.

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

#110

Post by ryanbrunner »

jypepin wrote: post #90
dafrie wrote: post #86

Earlier quoted context omitted.

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

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

I won't disagree that this is a popular opinion, but there's little practical benefit to storing state that's truly local to a single component (or a very small tree) in Redux just because it's there.

Even the maintainers of Redux maintain that it's perfectly acceptable to use local state - https://redux.js.org/faq/organizing-state#do-i-have-to-put-a...

Post reply on HN