Talk about gyzerok/adrenaline

[stubailo]

I think this has a lot of really great developer UX goals in mind, specifically around debugging, optimistic UI, and mutations.

https://github.com/gyzerok/adrenaline

@gyzerok, we're working on a GraphQL and Relay-based system, you can check out some info here:

• Read the blog post about our goals for the project.
• Read about the high-level design of the system.

Curious what you think about our ideas!

Also, of note is that you decided to implement a new store rather than using the Relay one - I wonder what the tradeoffs were there.

[gyzerok]

Hey guys!

I'm excited to see that more people tries to adopt such cool ideas like GraphQL. I really like your intent and think the goals you set are amazing. I've heard that Meteor is now on some kind of stagnation. So if that's true your project may become some kind of adrenaline injection :smiley_cat: to the technology.

I am not really familiar with Relay store since I've started Adrenaline before Relay was released as a set of helpers for using GraphQL with Redux. And now I think that my library is really over-engineered. Personally I found that I don't really need stuff like optimistic updates, efficient caching and all that cool stuff. It brings complexity to my system while I just don't need it. I think the Relay is a technology for huge systems and small, medium and even large systems should prefer maintainability over optimisations. That's why now after a month of thinking I'm going to cut Adrenaline edges and make it as simple and as little as possible.

If you want to check internals you should check this branch. But I think I would remove stuff like adapters and other internals.

So my recommendation to you would be to imagine consumers of your technology as a big products with as least 20-30 millions of users per month and up to maybe 50 developers working on it. So maybe you should provide Flow and TypeScript interfaces prebuilt (since static typing is necessary in such products) or recommend how to structure code according to your library in a cookbook. Also it would be good to think on how to reduce size of your library because huge projects use huge sets of dependencies and they need to keep resulting bundle at least not much bigger.

Good luck, have fun and feel free to ping me over here with the news :)

[gyzerok]

Oh, one more thing. If huge projects are your audience try to avoid boilerplate as much as possible, while keeping your API as explicit as possible. It's not orthogonal things so you would need to discover some kind of balance.

[stubailo]

I'm excited to see that more people tries to adopt such cool ideas like GraphQL. I really like your intent and think the goals you set are amazing.

Thank you!

Personally I found that I don't really need stuff like optimistic updates, efficient caching and all that cool stuff. It brings complexity to my system while I just don't need it.

There are a couple of reasons we want a fancy store like Relay, rather than having something simple that just stores the query results directly.

Optimistic updates are a big part of making mobile apps or any app that needs to deal with a less-than-perfect connection feel fast. One of the biggest reasons native mobile apps feel so much better than web pages is that they are often built offline first - this means that there is a first-class data store on the client which is synced from the server. If every operation in your app needs to do a server round trip, it always feels like a website rather than a real app. I think many systems make implementing optimistic UI much harder than it needs to be - I hope that in Apollo it will be so trivial everyone will do it for the UX benefit to their app.

Another big priority for us is reactivity. For reactivity, you need to be able to refetch just part of the data you are looking at. So you need to be able to load some new data and merge that into the cache, updating any query results that depend on it. It looks like this is very easy to do with the Relay store.

small, medium and even large systems should prefer maintainability over optimisations.

I agree with this - do you think the above requirements put a huge burden on maintainability?

So maybe you should provide Flow and TypeScript interfaces prebuilt (since static typing is necessary in such products) or recommend how to structure code according to your library in a cookbook.

Very good idea - I think we might actually want to adopt Flow for this project, just like Facebook does in Relay. But we can't require it for people to use the library, since not everyone is on board with these tools. But it should be easy and recommended to use with types. I wonder if we can generate TypeScript definitions from Flow. As for a cookbook, we've done something similar just recently with the Meteor Guide - I think best practices should be baked in and documented from the start.

If huge projects are your audience try to avoid boilerplate as much as possible, while keeping your API as explicit as possible.

Totally agree, boilerplate makes life hard. Having the right explicit API is good, over-configuration is bad.

Really appreciate the feedback and thoughts. Having more clients for a standard GraphQL transport makes everyone's life better, and I hope that our Apollo server extensions can also work with Adrenaline someday!