GraphQL

Application and Data / Languages & Frameworks / Query Languages
Avatar of objmj-itminds
Senior Software Developer at IT Minds·
Shared insights
at
()

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.

READ MORE
The Leading Web stack of an IT Minds Senior Developer. - DEV Community 👩‍💻👨‍💻 (dev.to)
11 upvotes·95.1K views
Avatar of undefined
Avatar of Scrayos
CEO at Scrayos UG (haftungsbeschränkt)·

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.

READ MORE
5 upvotes·12.3K views
Avatar of undefined
Needs advice
on
NGINX
and
GraphQL

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?

READ MORE
5 upvotes·9.9K views
Replies (2)
Avatar of brunoarueira
Full-stack software developer at Atos6·
Recommends
Traefik

It depends of your architecture, but my use is pretty simple up to now. My reverse proxy using nginx only skips the hit of the location /graphql to our application server through an upstream location that handles it, but at the future it'll probably be another app or a microservice. If you want something to load balance, probably it's better to use something like traefik.

READ MORE
4 upvotes·626 views
Recommends
GraphQL

Nginx is very low level and particularly difficult to debug (the documentation is really extensive and not so readable, and debugging when configured wrong is a pain), it will give you headaches for sure ! Keep nginx as minimal as possible and use it only for bare server configuration (handling SSL, domain names, reversed proxy, and load balancing). Nginx is also very fast to serve static assets. Nginx was originally created to serve static / templated WEB Servers and never as a REST API Handler. For "sorting, querying, pagination, caching" i'd stay with GQL because it's super easy to debug, it's readable, and mostly it was created to be simple and to handle REST API.

READ MORE
3 upvotes·1 comment·626 views
Avatar of zimoony
Senior Fullstack Developer at QUANTUSflow Software GmbH·

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.
READ MORE
18 upvotes·1 comment·364.6K views
Avatar of undefined
Needs advice
on
Symfony
Node.js
and
Go

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.

READ MORE
5 upvotes·32.2K views
Replies (1)
Avatar of maxmusing
Founder & CEO at BaseDash·
Recommends
Node.js
at

Go with Node.js. There's something really satisfying about being able to use a single language across your entire tech stack. Especially once you integrate GraphQL, which is effectively JSON.

Your second best option is Go, but the ecosystem around Node.js is quite a bit stronger. This will play a big factor when you start building functionality like file management, messaging (especially in real-time), and authentication. The libraries and documentation are just stronger for Node.

READ MORE
6 upvotes·2 comments·12.6K views
Avatar of pbrudny
CTO at JobsForIT·
Needs advice
on
Next.js
Contentful
and
Apollo
in

I am building a POC in Next.js. I usually use CRA+ MobX + Contentful, but this time I want to give a try to Next and GraphQL. Any suggestions on what tool to use for state management/content management? I am looking for a modern and quick to implement solution.

READ MORE
3 upvotes·11.8K views
Replies (3)
Avatar of davidannez2154
Head of Engineering at loveholidays·
Recommends
Sanity
at

Hey Piotr,

It's hard to really give a single recommendation for the things you are looking for, generally because I think content and state are very different things and you can choose to manage both independently.

Therefore I've picked Sanity as an example of a content management platform that you could utilise with your Next.js and GraphQL implementation. I've used Contentful and Sanity and both provide direct GraphQL integrations, so ultimately it's up to you what you want to pick here. As far as CMSes go, Sanity is much more "built it yourself with a good system around you" and Contentful is more of a "here is a platform, go create some content models". You will need more infrastructure for Sanity, but you might also get flexibility from it in the future. It really depends on what your PoC becomes.

As far as state management goes, it really depends on what you are doing. Honestly my advice is don't pick a state management library or tool just yet, and make do with React context, hooks and simple management of components. If things get complicated quickly I would look at how you are architecting data flow and rendering. Having used Apollo Client extensively in the past, you can use it for local state management as well as network calls, but the lines get blurry and I don't think it's very easy to follow when you do that. Having said that, it works out of the box for GQL and will give you what you need to get started. We use URQL in production and we like the simplicity it gives us and the lack of potential caching issues you can come across with Apollo Client.

My advice for Apollo Client is: * Do not nest your queries too much and SSR, renderToString() gets expensive when traversing the DOM tree * We saw benefits of using HTTP Batching for requests, but we also saw lag in the calls * Using Apollo Client works best with Apollo Server (naturally) so anything else can be a bit problematic because it doesn't do all the magic that Apollo Client would like

As you are doing a PoC, do whatever you feel gets you there faster with the GQL implementation. I would say read the docs of both and see which one takes your preference. Both are actively maintained and looked after well.

If you are expecting your PoC to become a fully fledged solution at some point, things to consider about both: * Bundle size * Adaptability when you start having N different GraphQL APIs going into a gateway * Ease of use for other people to pick up. Apollo has better documentation right out of the box.

To summarise, for content management: * Contentful or Sanity

For state management: * All local state with Context and Hooks * All data fetching with Apollo or URQL. My preference here is URQL, but if it's your first time with GrapQL then Apollo will have more support.

Hope that helps!

READ MORE
4 upvotes·193 views
Recommends
Apollo

So far, I have found that the best tool to use for state management is the Apollo Client. It is easy to use on the frontend and supports new React features such as hooks. It also removes the need to do any state management because the Apollo Cache, does all the dirty work for you. The main downsides of Apollo are the difficulty manually updating the cache and setting up the Apollo Client with Next.js. Thankfully, Apollo has some great documentation showing how to update the cache and Next.js provides an example of how to use the Apollo Client with SSR.

READ MORE
2 upvotes·57 views
View all (3)
Needs advice
on
React
Node.js
and
Django

I would like to build a medium to large scale app, that has real-time operations and a good authentication system and a secure and fast API. Should I use Django with React only? Or maybe use Django for the API, Node.js for real-time operations and React for the frontend? Any suggestions? Which database should I use with those technologies? Should I use both MySQL / PostgreSQL and MongoDB together? Should I use only MongoDB or MySQL / PostgreSQL? Or is it better to go with both MySQL and PostgreSQL at the same time? Should I use also GraphQL?

READ MORE
3 upvotes·11.9K views
Replies (2)
Avatar of maxsaykov18381
Full-stack developer at Asteria·
Recommends
Django

Hey, George

TL;DR PostgreSQL + Django + React.js.

A few notes about Django: * Django includes own ORM which is able to work with SQL databases. In this case, you're able to use any SQL storage like a PostgreSQL / MySQL / etc., but you can't use MongoDB. * Django is synchronous web-framework. If you want to use asynchronous operations in the database, you have to choose another tool (aiohttp for Python or fastify.js for Node.js). * Django is stable. You don't need to worry about data consistency, etc. * Django-Rest-Framework is a great library for handling REST API requests. * django-channels is a library for handling WebSocket connections. * GraphQL is a great thing, but it requires additional knowledge for using it. (especially, performance knowledge).

A few notes about Node.js: * You have to choose Node.js web-framework. Node.js includes a lot of web-frameworks like a express.js, hapi.js, fastify.js, etc. * Node.js applications are asynchronous. It can give you additional performance. * You have to know about data consistency inside your own application. * You're able to use MongoDB or any SQL database because npm includes a lot of libraries that can work with databases. * You're able to use GraphQL because Node.js is a better choice for GraphQL. * You don't need to use additional libraries for handling REST and WebSocket connections.

So, my conclusion is using Django + PostgreSQL + React.js. For this stack, you can get more stability. If you need to get more performance, you have to think about some asynchronous languages (like a Node.js).

Take a look at Flask + SQLAlchemy + PostgreSQL + React.js. SQLAlchemy is a better ORM than Django-ORM.

I hope, it's useful for you :)

Best regards, Max

READ MORE
9 upvotes·1 comment·459 views
Avatar of maxmusing
Founder & CEO at BaseDash·
Recommends
PostgreSQL
at

Node.js is a great option for real-time applications, especially in conjunction with Socket.IO.

In terms of databases, I'd go with PostgreSQL. MongoDB has its benefits (schema-less, sharding, map-reduce), but for most CRUD-based apps, it makes sense to store the bulk of your data in a relational database (of which PostgreSQL is the best IMO). You can throw in MongoDB if you have a specific need for it. There's certainly no need to use both MySQL and PostgreSQL.

As for GraphQL, it can be nice to work with since you don't need to predefine specific data endpoints on your backend, instead shifting the power to your frontend in requesting the data it needs. It's also useful for public APIs, when you don't know what data users want (see Github's API). It can be useful at the early stage when you're prototyping and want to be able to fetch data quickly, but certainly isn't necessary.

At BaseDash we use Node.js, ExpressJS, Socket.IO, PostgreSQL, and Sequelize to fit our use case of database management and real-time operations.

READ MORE
5 upvotes·1 comment·18.6K views
Avatar of wassimbj
Software Developer ·
Needs advice
on
JSON Web Token
and
Google Chrome

I really want to know, what are the problems that JSON Web Token solves that Sessions can't. JWT is actually more vulnerable when it comes to security. And what do other companies like Facebook or even Airbnb use to secure their API endpoint (I'm talking about GraphQL here).

Thanks!

READ MORE
4 upvotes·2.3K views
Needs advice
on
PostgreSQL
and
MongoDB

Hello everyone,

Well, I want to build a large-scale project, but I do not know which ORDBMS to choose. The app should handle real-time operations, not chatting, but things like future scheduling or reminders. It should be also really secure, fast and easy to use. And last but not least, should I use them both. I mean PostgreSQL with Python / Django and MongoDB with Node.js? Or would it be better to use PostgreSQL with Node.js?

*The project is going to use React for the front-end and GraphQL is going to be used for the API.

Thank you all. Any answer or advice would be really helpful!

READ MORE
14 upvotes·278.6K views
Replies (11)
Avatar of arhuman
Code Alchemist at DOOLTA·
Recommends
PostgreSQL

If you want safety (no data corruption/loss) Postgresql is the way to go. You can use Postgresql with python/django but also node. And as a bonus postgresql performance should match those of mongodb if properly tuned...

READ MORE
21 upvotes·1 comment·681 views
Avatar of jtwebman
Lean Software Programmer ·
Recommends
PostgreSQL

I mean what you use really comes down to your team. I would normally pick a relationship database over an object store for reporting and other things down the road that are much harder to do with a DB like MongoDB. As for language, I would pick Elixir as it does these things really well but that because that is what I know best. Python or Node.js are also sure good choices. Whoever is building should probably pick the language, framework, and database.

READ MORE
11 upvotes·1 comment·681 views
View all (11)
Needs advice
on
React
GraphQL
and
Go

I am looking to complete my stack, backend Node.js or Go, GraphQL for querying, React for frontend, and MySQL for database. I am wondering, what items would you add to this to make it complete? Trying to get the full picture. When I think of the connections from backend to frontend and back again, it would be great to see what other people see as a complete picture. Thank you =)

READ MORE
4 upvotes·3.3K views
Replies (2)

It purely depends on your app needs. Does it need to be scalable, do you have lots of features, OR it is a simple project with very simple needs - many of those parameters clarify which technologies will fit.

If you are looking for a quick solution, that reduces lot of development time, take a look at postgraphile (https://www.graphile.org/postgraphile/). You have to just define the schema and you get the entire graph-ql apis built for you and you can just focus on your frontend.

On frontend, React is good, but also need to remember that it is popular because it introduced one way data writes and in-built virtual dom + diffing to determine which dom to modify. Though personally I liked it, am recently more inclined to Svelte because its lightweightedness and absence of virtual dom and its simplicity compared to the huge ecosystem that React has surrounded itself with.

In all situations, frameworks keep changing over time. What is best today is not considered even good few years from now. What is important is to have the logic in a separate, clean manner void of too many framework related dependencies - that way you can switch one framework with another very easily.

READ MORE
4 upvotes·1 comment·447 views
Avatar of davidannez2154
Head of Engineering at loveholidays·

Generally I would advise you pick Node.js for your backend if you want to run a GraphQL service. The main reason for this is the tooling and support you get from the language around GraphQL and the native feel due to the spec being initially written in JavaScrip for JavaScript. However that isn't to say that you couldn't use Go for a service underneath your GrahpQL layer - but I would say that's probably complicating it too much to begin with.

Node.js has great support for reading from databases and using a server such as Koa will give you great performance (we operate several Node.js services in Koa with over 1000req/s). Additionally it keeps your initial simple stack in the same language so it will be easier for you to jump backwards and forwards.

If you were not to use GraphQL then I'd say it's really up to you whether you want Go in your ecosystem or not. It's a fantastic language and super performant, along with being more memory efficient than Node (if you are worried about costs at large scale).

If you're at infancy stages and haven't picked certain parts - and this is a customer facing application - then I would recommend you look at Preact instead of React and URQL (instead of Apollo Client). Both are great libraries that are very performant and don't need much advanced learning. Additional swap out MySQL for PostgresSQL (they are interop primarily, but offers you more features as you grow) for its ACID compliance, better performance at scale and support for NoSQL if you were to go that way.

READ MORE
4 upvotes·415 views