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

91–100 of 155 posts

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

#91

Post by progx »

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 agree! You must not use all fancy new things to build your application, just because they exists.

We also took a step back and removed GraphQL-stack and use simple clean REST-Api only, it has increased our productivity and we don't have to divide our time for an other module, which must be maintained too. Before we used REST and GraphQL, becuase it make no sense to put everything into GraphQL.

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

#92

Post by regularfry »

lame88 wrote: post #41
stephan83 wrote: post #36

Elixir and OTP are really nice, but I'm frustrated by the type system, even with typespecs. I finally gave in and started learning Haskell. I would still choose Elixir/Phoenix for some web apps though.

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 written. Cloud Haskell is an example of this: the tutorial docs are incomplete (the very first command they have you write is wrong, among other things), and they don't specify a stack version so the Hello World example doesn't build with the current snapshot and there's a really odd change to a public API I just can't get my head round.

I've had the same experience with Yesod and Scotty too, although not recently - every time I decide it's been long enough for the ecosystem to mature a bit more, I bounce off issues like this which I just don't get elsewhere, and decide to give it another couple of years.

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

#93

Post by aspett »

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

> 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 more tedious. I particularly enjoy how easy it is to modify the schemas once it's set up too. If we ever need to expose more data, it is usually done within minutes. There is a massive benefit in the forced standardization of GraphQL too. Being rigorous about standardizing APIs and how you do filtering, sorting, embedding, nesting and so on is tiring and a waste of time - you end up writing mini frameworks. Absinthe and GraphQL reduce this pain for us considerably.

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

#94

Post by TN1ck »

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?

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

#95

Post by maitredusoi »

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

This the best part "Main reason is the absurd amount of complexity with costs heavily outhweighting benefits gained from the solution." Couldn't agree sooooooooo much ! thx xlii.

I will remember that one "Right now we’re disassembling app to a classic REST-app and we’re seeing development speed increase on week-to-week basis" . thx

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

#96

Post by xlii »

fouc wrote: post #81
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 assume you're keeping Elixir/Phoenix as RESTful api, and then React on the front-end? I've heard Redux suffers from similar issues with complexity, so what will you do?

Yes. Elixir and Phoenix are wonderful and still my favorite language/framework and they are still backing things.

For front end I wanted to move back to Ember since I had a lot of positive experience with it but that was impossible due to the business requirements.

As for Redux I try to stay away from it utilizing philosophy “you don’t need it unless you know you need it”. Cargo cult made Redux default piece of stack and it’s another very complex and sensitive to mis-design piece.

Instead of using Redux we rolled our own adapter since we had to work with some data outside Apollo and it’s we are rather happy with it. Not sure how it will scale to RN though.

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

#97

Post by xlii »

y4mi wrote: post #85
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,…

> * Right now we’re disassembling app to a classic REST-app* still with elixir/phoenix or did you scrap even that part?

Nah. Elixir stays ;)

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

#98

Post by xlii »

aspett wrote: post #93
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,…

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

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

#99

Post by slashdotdash »

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

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

#100

Post by benwilson-512 »

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

We've also felt the complexity of React and Apollo. It works best when, as others mentioned, you've got distinct teams that can focus on each part. In situations where that isn't the case the same decouplings that make it easier for teams to operate independently just add overhead and complexity.

We're in a similar boat these days so in fact our latest projects are back to simple server side rendering, but we're still making the data retrieval calls with GraphQL. It ensures that that the mobile app and reporting tools we're also developing will have parity, and we don't need to write ad hoc query logic for each use case. The built in docs and validations have simply proven too useful to pass up, and you really don't need a heavy weight client to make requests.

Post reply on HN