The GraphQL Specification has theInt, Float, String, Booleanand ID Scalar types by default. Those scalar types help you identify the data and validate it before transferring it between client and server. But you might need more specific scalars for your GraphQL application, to help you better describe and validate your app’s data.

Validation using Scalars

For example, you have a String field but you need to validate upcoming or ongoing string data using regular expressions. So you should have this validation on each end; one in the client, the other one in the server and maybe there is another on a source. …

Designing and building modular GraphQL API may not look straight-forward the first time you start. It is hard to keep a perfect modularity with standalone and encapsulated modules.

It is really easy to appeal to the circular imports, but that’s exactly what you shouldn’t do in any case. You might say while reading this; I DON’T HAVE ANY WAY OF NOT CREATING CIRCULAR IMPORTS!

In a previous versions of GraphQL-Modules, we used to allow users to have circular imports in their GraphQL-Modules applications. …

GraphQL is everywhere! Together with Typescript it is one of those technologies everyone wants to get their hands on in 2019.

When using GraphQL on the client, the most popular library is the powerful Apollo Client. Today, Apollo currently has an official support for leading Web Frameworks like React and Angular.

But what if you don’t have to use those frameworks to create a really powerful and performant apps? Or what if you want to expose Web Components with shared logic like GraphQL data fetching to developers who use different frameworks?

Web Components and GraphQL

That’s where Stencil come in. It’s a Web Components compiler that combines some of the best features from Angular, React and Vue to create web applications or re-usable platform agnostic UI libraries based on Web Components. …

We recently released a new version of GraphQL-Modules with a new feature called Scoped Providers in the dependency injection system of GraphQL-Modules.

Dependency injection in GraphQL-Modules is optional, and you can use it according to your preference. It provides a solution for writing Providers, which are just classes, you can use to write your business-logic, and this way to separate it from your API declaration, reuse it, and communicate between modules easily.

This new feature allows you to define Providers to be used in different scopes;

Application Scope

If you define a provider in this scope which is default, the provider will be instantiated on application-start and will be same in the entire application and all the following requests. The providers in this scope can be considered as a shared state across all users’ interactions with our application. …

When designing GraphQL Modules, we tried different approaches to encapsulate modules safely. We created a solution where you won’t need to use Dependency Injection when you start, but after you are getting to a certain scale, you can make use of our separate DI library to ease the separation and make the boundaries stricter, only at the point when it really makes sense and helps you. When you get to that point, DI helps you mostly for ease of mocking providers for testing and encapsulation for less error prone implementation.

In the early stages of GraphQL-Modules, it used to have Inversify internally for Dependency Injection in GraphQL-Modules. Inversify is a platform-agnostic Dependency Injection library written in JavaScript. Unfortunately, Inversify didn’t fit our needs for modular DI (Dependency Injection) due to some critical reasons that we’ll expand on this article. …

TL;DR: If you are writing a large-scale project, it’s necessary to understand the relations between your pieces of code, and how they effect each other. Otherwise, it might be difficult to deal with changes later.

While developing a large-scale project, removing, changing and modifying parts of the project can become a very time consuming and risky task, because understanding the full side-effects of those changes is very hard.

In GraphQL-Modules, you can declare your modules in a feature-based structure, with clear enforced boundaries and avoid unexpected side-effects during development.

Each module can declare it’s own scope of the complete schema:

Last year we’ve released GraphQL-Modules — which applies modular approach to large scale, GraphQL-based applications.

We’ve also released a new version of GraphQL Code Generator which generates server-side typings and signatures for resolvers from GraphQL Schemas.

Those are two separate projects, but because we use both in production across many different applications, we wanted to write about the benefits of the tight integration of those projects and how it provides us with great development experience while implementing our projects in TypeScript.

GraphQL Code Generator can take a JS/TS export from GraphQL-Modules to generate server-side typings (or anything else that its plugins can generate). …

When starting a backend project, two of the biggest concerns will usually be the right structure of the project and authentication. If you could skip thinking and planning about these two, starting a new backend project can be much easier.

If you haven’t checked out our blog post about authentication and authorization in GraphQL Modules, please read that before!

Internally, we use GraphQL-Modules and AccountsJS to help us with those two decisions, GraphQL-Modules helps us solve our architectural problems in modular, schema-first approaches with the power of GraphQL and AccountsJS helps us create our authentication solutions by providing a simple API together with client and server libraries that saves us a lot of the ground work around authentication. …