Hello @nilan since many big changes are happening, will graphcool framework going to stay as it is or it gets under graphql yoga or something, I really like how graphcool abstracts everything and gives me to define schema, queries but with those changes and graphql cli I feel it's may not be developer friendly anymore, please throw some thoughts on the current direction

hey @chakrihacker great question, thanks! 🙂 I answered a similar one in the Forum: https://www.graph.cool/forum/t/developer-preview-graphcool-1-0-beta/1891/11?u=nilan Would love to continue this discussion there, if you have further questions 🙂

@chakrihacker Here's my take and hopefully @nilan will correct me where needed. I've hand rolled a GraphQL server (in Elixir) and it's a ton of boilerplate. I've found boilerplate can be helpful in teams (because it's explicit) but maddening for solo and small teams. GraphCool was perfect for solo and small teams, but that same web magic made it nearly impossible for anyone else. However, there was another subtle gotcha waiting to hit the GraphCool user -- data aggregations. Say that you wanted to get yearly sales totals, displayed by month. With a database, there's the normalized and denormalized way to store / ask the question. Normalized queries all of the sales for that period and adds them up. Denormalized stores a table of the sales data. Both have their pros and cons. But in the previous GraphCool, you pretty much had to go the denormalized route. That is, make a

salesData

type and "infect" your code on

productSales

update to adjust salesData. Not so bad, right? But what if you now want the sales by day? Another type? I just gave up and had the server send the sales data down the wire and let the client aggregate it. Yikes. But now that there's a server in front, you can do all of those aggregations properly on the server. So yes, in my opinion, it's slower for small teams -- some of the magic is gone -- but the trade off in flexibility and not backing your project into a corner is well worth it!

Hey @chakrihacker, did you read this thread: https://www.graph.cool/forum/t/developer-preview-graphcool-1-0-beta/1891/11?u=nilan? 🙂 I share a couple of thoughts regarding your questions there already. In short, 1.0 is aiming to improve the developer experience when developing GraphQL apps, and we're working on a bunch of tools around the application server. This post is also quite interesting: https://www.graph.cool/forum/t/developer-preview-graphcool-1-0-beta/1891/11?u=nilan You can still leverage the easy getting started experience coming from the automatically generated DB API. @lawjolla, aggregation is actually a feature that will be implemented directly into the Graphcool API, would love to hear your thoughts on the current proposal: https://github.com/graphcool/framework/issues/1312 you can follow along our progress in the roadmap: https://github.com/graphcool/framework/pull/1318

@nilan I'd love to! I'll go check it out. I have a lot of aggregation needs. My more general point is now matter how brilliant GraphCool gets, the world still has 50 line SQL queries for a reason. So separating it into its own server is the right move!

Hey, I read thread and announcement post in medium again, and it makes sense of what you are doing, this is going to be awesome, thanks

@lawjolla gotcha, I fully agree! 👌 I'm super excited about https://github.com/graphcool/graphcool-binding, too 🙂

Welcome