Isn't that equal to just returning `{ typename: "MyTypeName", id: 123 }` from a resolver and then `graphql-js` just running the field resolvers on the `MyTypeName` type as needed?
I'm an engineer on the client team, so I'm a bit fuzzy on the Apollo Server details and history, so please bear with me :)
I guess you're talking about [Safelisting Persisted Queries](https://www.apollographql.com/docs/graphos/platform/security...) here.
Afaik, if you want to use the full integration with the GraphOS platform, you'll need an account with us. The feature is supported on the free account with a rate-limit, and if you would need more, you could go with the "developer" account, which we launched this summer, which is quite reasonably priced and comes with starting credits: https://www.apollographql.com/pricing
That said, Apollo Server is open source and at no point you are locked into our platform - it's just that our platform takes a lot of work away from you, allowing you to manage those whitelists easier.
If you want to manage your whitelist yourself, it's totally doable - I just did a quick google search and have come up with more than a dozen articles describing various ways of doing it.
Just be aware that there is a lot of coordination between builds and deployments going on, quickly leading to very complex setups - which is why we offer the platform integration in the first place.
So I think the idea was not to lock anyone out of these features, just create a quick pit of success by making the GraphOS integration really easy - but I can see where your feelings are coming from. I hope we can earn back your trust over time!
Huh, that's an interesting take - honestly I don't really know what to do about that :/
It's definitely not our intention to send that message - Apollo Client should be a good fit for everybody.
The biggest adoption hurdle I could think of is that we only offer a normalized cache.
From what we're seeing everybody sooner or later has a good use for it, and switching from a non-cache solution to a normalized cache can cause a lot of pain when it's done too late, so we don't give people the "without" choice from the start.
That said, I've been looking at your docs, and you seem to make any kind of cache completely optional. That's a bold move the other direction ^^
I'll be keeping an eye out on how people start using that :)
Make sure to stop by the GraphQL Discord - most of the maintainers of the different cache libraries are over there and we're always up for a chat!
Hi there, Apollo Client maintainer here!
Great to see more GraphQL projects sprouting out there :)
If I may ask, are there any things that are currently missing in Apollo Client to be a good match for Svelte or SolidJS? If there are things we can improve, I'd be happy to know!
Hi, RTK Query author here - from taking a skim at the code, you really went deep into our documentation. Looks good! :)
Many people here tell you "study", others tell you "don't".
Both is okay.
In Germany, you probably don't need it when going into IT, and in my last job we had many people coming from both perspectives and it was a great mix. What counts in most companies more than a degree is experience - and you probably will not get happy in a company where it is the other way round.
One pro for studying is that you can get the time to learn social skills among your peers - I can only say for myself that I really needed that more than anything else.
You could of course also do both: become a Werksstudent. In the end, it's all up to you ;)
If you are looking for a job now, my old colleagues at Mayflower are always looking for promising people (and you certainly match that description). They are great developers and amazing humans. They have offices in Munich, Würzburg and Berlin, so no matter if you want to stay where you are or get out into the world a bit (which I certainly would recommend), you could work with them. Take a look at https://mayflower.de/karriere/ and even if they don't have a job as Werksstudent out there right now, just apply anyways and see.
Oh, and tell them greetings from Lenz - that's me ;)
It doesn't seem verbose to me. Have you looked into those docs above? You define a reducer and an action creator is automatically generated. String action types are an implementation detail. No manual immutable state modification, as immer is baked in.
Modern redux is maybe 20% of what you might be imagining if you only know legacy redux.
It's not much more code than writing a function, but other reducers of your state can suddenly act upon the same action, you can trigger side effects using middleware and of course watch stuff "by intent" and not "there was a modification" in the devtools. All while keeping everything separated pretty well.
With a lot of hand-written boilerplate, many required manual optimizations and performance that will in the best case be equal but often doesn't even get close. Context cannot rerender selectively. You change one property in a context object, all subscribers rerender, no matter if they access that property.
That would be the "observing" approach I described.
The upside of an action-based (signalling) approach is that you have a better time separating concerns as actions (if used correctly) represent intent, so your component emits an event and the state acts accordingly, removing state logic from your representational components. Might also be a lot easier to see in the DevTools what happened when and why.
Of course not every app needs a pattern like that, that's why I said both approaches are valid.
That page introduces one tool after another, replacing all those external tools with the officially recommended Redux Toolkit that wires all of them up for you.
In the end you are left with only
`import { configureStore, createSlice } from '@reduxjs/toolkit'`
Also, two-way-data-bindings like just `state.totals` work when you're just re-rendering your whole app on every frame, but as soon as you get away from that, there will always be either some "observing" or "signalling" involved to trigger rerendering of the correct parts of your application. Redux goes the "signalling" way, MobX goes the "observing" way, both have their benefits and drawbacks.
You are right, if all your state is "cache state", then you don't need Redux. But at that point you don't need any state management library and are already searching for the wrong tool from the beginning. If you have actual global state, you'll come very quickly to a point where an actual state management library beats writing your own though, both in developer experience as well as performance.
Or is this doing more?