Table of Contents
One of the crucial steps in project development is choosing a technology that would be perfect for its business logic.
Business logic is the custom rules or algorithms for exchanging the information between a database and a user interface. Simply put, it’s a part of computer program with an information about how the business operates. Basically, it’s the foundation of every project.
In this article, we’ll tell about our experience with using GraphQL in our recent projects. However, this is not graphql tutorial, this is how it works in real life.
Project A
The first project was a start-up with functionality of service delivery in sales. Among the features were a few models, a CRM-admin panel, 3 mobile applications: 2 for iOS, and 1 for Android. All the communication between mobile applications were built on GraphQL API.
One of the peculiarities of the project was that one of the iOS application initiated the execution of the great part of business logic. The rest serve as an interface for the users, integrate them into the system and show the stats.
One of the challenges with API related to the users’ access authorization (depending on the users’ role). Consequently, a users’ application shouldn’t have access to the GraphQL fields’ scheme that works with a business logic. The main app, in its turn, shouldn’t have access to the specific fields of “users” scheme.
The solution we found was simple but super effective. We created several separate GraphQL schemes with independent input points for queries execution.
As a result, all the authorization logic has been executed before the query’s execution. This allowed us to avoid developing an authorization in a scheme, itself.
Project B
An application, which we developed for project B, consisted of several GraphQL API and SPA parts on React. The project’s goal was to create questionnaires for users.
We developed a flexible database structure that allowed easily storing and adapting polymorphous entities-queries within one questionnaire.
The main challenges with GraphQL API were that a little number of mutations needed to process a bunch of identical operations with a great number of GraphQL InputTypes.
ActiveRecord “dictates” a specific approach for the application’s design, where the logic of validation, data storage, and business logic is usually carried out in terms of the same classes. That’s why we decided to find another solution and came to the approach from the authors’ Trailblazer framework.
We divided all the business-logic into the concepts, inside which all other parts are described separately. This architecture turned out to be perfectly compatible with GraphQL.
Each mutation and query have a corresponding separate operation within a concept. Additionally, each mutation has a corresponding set of validations rules. Each type of returnable GraphQL data has a corresponding object, which is the result of operations.
Such an approach allowed us to reuse parts of the code, as well as adding new functionality without a risk to “ruin” something in the application’s parts, which are combined with each other.
Project C
The third project relates to the healthcare industry. There were 4 platforms: 2 SPA web-applications, 1 iOS application and 1 ReactNative application. Simply put, it’s a medical application that allows saving much time and money when it comes to the healthcare industry.
The challenge was connected with a great amount of data that were linked with each other. Moreover, it’s impossible to store the part of this data in their own database. Simply put, the main goal of the project was to accumulate data about the doctors from third-party sources, as well as filtering and processing it according to the business logic of the project. As a result, the project had a huge amount of integrations, data maps, and complicated logic of building the connection.
This influenced the API structure. In a current GraphQL scheme were data types that partly or fully used in every platform. This significantly complicated the process of adding changes or new types.
To solve the challenge, we developed an additional abstraction layer that provided backward compatibility between data types. This layer uses a great amount of dependencies
One of the issues related to the authorization system. It didn’t allow “hiding” or restricting access to users and client-applications developers to some parts of the scheme. Another API issue related to the lack of detailed description of some scheme’s parts.
Despite the fact that the additional abstraction is the most complicated and difficult in terms of support, it’s still the most thought over part.
As it was in the second project, this layer allows dividing the logic of data storage, integrations with third services and a layer for data reflection.
Based on our experience with GraphQL, we may highlight the most effective rules for working with it.
- There shouldn’t be any logic in a GraphQL scheme. All the filtration, data comparison should be executed in separate objects and structures.
- An authorization should be made with GraphQL. Control the fields’ scope as you want.
- Make sure to create scalar types for more complicated but unitary data, such as data or URL.
- Isolate the execution logic of mutations and queries. Despite the fact that Trailblazer tool is not flexible, it tuned to be highly effective.
- Set up the queries logging and their parameters at the very beginning. This will significantly simplify the debugging and analytic process.
- If your API uses 2 or more applications that execute different or mutually exclusive logic (for example, one “admin” and one “user” application), it’s better to divide the schemes (every application should get its own endpoint or its own scheme).
As you can see, GraphQL allows achieving results if you combine it with a skillful development team and a willingness to develop something “valuable.”
See you in the next episodes, where we’ll tell you about the other strategies we use.
