3 ms·
my experience is just ok. as someone here puts it, great for frontend devs but bad for backend devs. if you have db schemas on the backend if using orm, get re
by jaequery 8y ago
my experience is just ok. as someone here puts it, great for frontend devs but bad for backend devs.
if you have db schemas on the backend if using orm, get ready to duplicate them again for graphql.
and on the frontend, get prepared to write out every songle fields you need from the backend. i can imagine it may be brutal for those who have a lot of changes in their schemas.
my conclusion is that, since im a fullstack who does both frontend and backend, i feel myself getting a bit more fatigued than when i was doing rest style api. i find myself wanting rest time to time, esp at times i dont feel like writing out all the fields i need back that i cant remember off top of my head.
- spinningarrow 8y ago> and on the frontend, get prepared to write out every songle fields you need from the backend. i can imagine it may be brutal for those who have a lot of changes in their schemas. Wouldn’t you need to do this in some form anyway (since those fields would be displayed or used in some way)?
- jaequery 8y agowell, it won't be just a simple GET /user/1 anymore. it will be like: user { id name role status age sex address group { id name } etc etc }
- spinningarrow 8y agoRight - what I meant was more like when you get some data you probably want to display it in the UI and would already be doing something like ‘Hi ${user.name}, your age is ${user.age}’. This is affected by schema changes irrespective of the way the API is invoked.
- valw 8y ago> if you have db schemas on the backend if using orm, get ready to duplicate them again for graphql. I would consider this a weakness of ORMs, not of GraphQL.
- kimdotcom 8y agoThe Vietnam of CS.