GraphQL

At IT Minds we create customized internal or #B2B web and mobile apps. I have a go to stack that I pitch to our customers consisting of 3 core areas. 1) A data core #backend . 2) A micro #serverless #backend. 3) A user client #frontend.

For the Data Core I create a backend using TypeScript Node.js and with TypeORM connecting to a PostgreSQL Exposing an action based api with Apollo GraphQL

For the micro serverless backend, which purpose is verification for authentication, autorization, logins and the likes. It is created with Next.js api pages. Using MongoDB to store essential information, caching etc.

Finally the frontend is built with React using Next.js , TypeScript and @Apollo. We create the frontend as a PWA and have a AMP landing page by default.

We use GraphQL for the communication between our Minecraft-Proxies/Load-Balancers and our global Minecraft-Orchestration-Service JCOverseer.

This connection proved to be especially challenging, as there were so many available options and very specific requirements and we tried our hardest to put as little complexity into this interface as possible.

Initially we considered designing our very own Netty based Packet-Protocol. While the performance of this approach probably would've been noteworthy, we would have had to write a lot of packets as the individual payloads would differ a lot and for the protocol specification a new project would've been needed, so we scrapped that idea.

Our second idea was to use a combination of Redis Key/Value store (in particular the ability to write whole, complex sets as the values of keys) for existing data, Redis Pub-Sub for the synchronization of new/changed/deleted data and a Vert.x based REST API for the mutation requests of the clients. While this would certainly have been possible, we decided against it, as redis offers no real other data types than strings and typing was important to us.

So we finally settled for GraphQL as it would allow us to define dynamic queries and mutations and additionally has subscriptions in store, so we would only need one component instead of three separate. The proxies register as subscribers to the server changes channel and fetch the current data set in advance. If they need to request changes, this is done through a mutation in GraphQL aswell.

The status of the invidiual servers is fetched through Docker healthchecks and a Docker client in the orchestration service, that subscribes to changed HEALTHINESS values in docker. If a service becomes unhealthy it is unregistered and synchronized through GraphQL. The healthcheck is comparable to a ping packet that expects a response in a given time frame.

Hi, we are looking to create a sports app that collects and displays player stats. It will include team chats with push notifications for upcoming games etc. We are thinking of using the standard MERN stack route with a GraphQL API or a real-time Firebase database. Any advice would be greatly appreciated.

We are currently using nginx as a reverse proxy for API mutations and GraphQL as a unified API service for all API access and fetch, where GQL has good support for caching, sorting, pagination, and querying. Is it recommended to use NGINX for all of the above purposes, and when API aggregation is not the case, not use GQL.

Or for sorting, querying, pagination, caching - is GQL always a better choice, even if there is no API aggregation involved?

Our whole Vue.js frontend stack (incl. SSR) consists of the following tools:

• Nuxt.js consisting of Vue CLI, Vue Router, vuex, Webpack and Sass (Bundler for HTML5, CSS 3), Babel (Transpiler for JavaScript),
• Vue Styleguidist as our style guide and pool of developed Vue.js components
• Vuetify as Material Component Framework (for fast app development)
• TypeScript as programming language
• Apollo / GraphQL (incl. GraphiQL) for data access layer (https://apollo.vuejs.org/)
• ESLint, TSLint and Prettier for coding style and code analyzes
• Jest as testing framework
• Google Fonts and Font Awesome for typography and icon toolkit
• NativeScript-Vue for mobile development

The main reason we have chosen Vue.js over React and AngularJS is related to the following artifacts:

• Empowered HTML. Vue.js has many similar approaches with Angular. This helps to optimize HTML blocks handling with the use of different components.
• Detailed documentation. Vue.js has very good documentation which can fasten learning curve for developers.
• Adaptability. It provides a rapid switching period from other frameworks. It has similarities with Angular and React in terms of design and architecture.
• Awesome integration. Vue.js can be used for both building single-page applications and more difficult web interfaces of apps. Smaller interactive parts can be easily integrated into the existing infrastructure with no negative effect on the entire system.
• Large scaling. Vue.js can help to develop pretty large reusable templates.
• Tiny size. Vue.js weights around 20KB keeping its speed and flexibility. It allows reaching much better performance in comparison to other frameworks.

I'm about to begin working on an API, for which I plan to add GraphQL connectivity for processing data. The data processed will mainly be audio files being downloaded/uploaded with some user messaging & authentication.

I don't mind the difficulty in any service since I've used C++ (for data structures & algorithms at least) and would also say I am patient and can learn fairly quickly. My main concerns would be their performance, libraries/community, and job marketability.

Why I'm stuck between these three...

Symfony: I've programmed in PHP for back-end in a previous internship and may do so again in a few months.

Node.js: It's newer than PHP, and it's JavaScript where my front-end stack will be React and (likely) React Native.

Go: It's newer than PHP, I've heard of its good performance, and it would be nice to learn a new (growing) language.