Hacker News new | ask | show | jobs
by aspett 2619 days ago
> 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.

1 comments

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

> it's super hard to optimize. It's very easy to have an N+1 query hell.

Both Postgraphile and Hasura deal with this. I have no idea about Absinthe.