Tadeas Musil

We startup project with Apollo Client as the fronted data management library with a promise that in the short future we will have Graphql backend but for now you have to connect with standard REST. After 1 year there is no Graphql backend, classical business promises... so we switched to React query.

• you do not have to worry about merging objects
• you do not have to worry about writing custom resolvers
• you do not have to worry about writing __typename in custom resolvers
• you do not have to worry about schema description inInMemoryCache
• you do not have to worry about describing graphql schema

• you need to writing fetch keys
• you need to keep in mind fetch keys similarities

We decide to choose Gitlab as prefered Project management, code hosting and CI/CD tool because it best fit our agency needs. We love their integrations with open source tools around the dev wold. Gitlab is all in one solution but you must be on the same boat about how project development should look like. Gitlab is a lot less customizable than Azure Devops.

Bunch of prepared high quality and customizability components ready to use. Cons are lower performance at a runtime because of runtime CSSinJS

Description

Graphql fits exactly into our component-based architecture. The components control what they need for the data. It solves REST problems, such as establishing multiple connections or downloading redundant data. However, it brings other problems among other things it sends data only when it gets all the hard to set up their streaming. On the other hand, graphql has similar disadvantages as SOAP.

Plus

1. Aligned with our architecture
2. Component focused
3. Typed language - aligned with Typescript

Cons

1. Hard to work with caches
2. Hard or even impossible setup response streaming

Largest ecosystem in the programming languages in the world