GraphQL: Apollo Server

Michael Sudirman
Moodah POS
Published in
4 min readDec 5, 2019
src: codementor.io

With the never ending development of codes, we continue to strive for better and clean structured codes. In this article, I would like to show the needs of GraphQL to fulfill the clean code structures in between architecture, the library and frameworks that helps creating a better middle-ware structure.

Needs of Middleware in Moodah POS

Middleware in between front-end and back-end operations

Front-end and Back-end are essential in creating a fully functional web app. But in Moodah POS, we want to make sure that the front-end does not need to take care of the API end points, which can improve the clean code structure that way. This is where GraphQL takes into play, covering the needs to convert naming conventions and handles multiple API calls.

Apollo Server

To call these GraphQL functions, we are using Apollo Server. This serverless architecture enables response for GraphQL calls from the front-end, and calls the backend for information. To show a deeper explanation of Apollo Server, several codes will be shown. There are 2 types of functions: Query that only gives information, and Mutation that alters information

Mutation — Apollo Server Authentication to Odoo API

One form of mutation is authentication, where we asks for the server to create a token which will be used later on. This provides ease for front-end as there won’t be any needs for calling the endpoint. GraphQL will do its job for you~

Codes above are abstraction of what is going to happen during authentication. There is a code written as type: SignInType, which are the expected data written in Odoo API convention: username, isSuperuser and sessionToken(converted into camelCased due to humps convention). Also, args acts as a login credentials that will be thrown to the API during authentication. This consists of the database that we are using, as well as username and password under Odoo convention. The args will then be passed into the resolve argument.

In Moodah POS, we created configureService that requires operation, error and success expectancy as an argument. After knowing the arguments and what fields are expected as a response, we used http.d from an extension-library nodoo that calls the http simulation. with these libraries, Apollo Server will create a none authentication, that does not have any credentials, followed by createAuthenticate. These completes the arguments needed for configureService ‘s operation.

Apollo Server CRUD (Create, Read, Update, Delete)

Apollo Server also lets you to call a function that access the database under a single function. In Moodah POS, we consider this as CRUD, which are the all the necessary database actions that can be called to the Odoo API end-point.

getDataSet utility for token auth

Most databases demands authentication token because accessing its information. This can be handled with GraphQL Apollo’s context argument under the resolve function. The context will contain the sessionToken for further database access. We provide the utility getDataSet for CRUD, which calls the httpController from the http.d to create a simple http kind object and adds the needed sessionToken

Mutation — Create,Update,Delete

Create, Update, and Delete are all considered as mutations as they alter the database. They have similar algorithms and structure as the previous authentication mutation, which uses configure service to send arguments to Odoo API.

Delete function for POS Product model

The convention is similar to auth mutation. However, it uses getDataSet instead and will give the needed token. In most cases, these mutation will send modelName and ids to select specific tables. Under different access types, different function will be called.

Query — Read

Read is the only query out of all CRUD operations. Although being distinguished in types, it does have the same code structure and flow as any of the other operations. The only difference is that after bundling these independent functions, read is separated under the query value, which is mandatory in GraphQL Apollo

Separation of query and mutation in POS Product model

More on Database Operations

To create different access types for database, we use different functions as follows:

  • Create — createCreate()
  • Read — createRead()
  • Update — createUpdate()
  • Delete — createDelete()

These functions are from http.d from an library extension nodoo and is used to add a context in forms of an object to represent the types of access. For example, createDelete() will call a create interface from create.t. Looking deeper into the function, it will create an object with params of method: 'unlink’ . This helps the GraphQL to distinguish which database access types are going to be executed. Other params worth mentioning are: ‘create’,’read’and’update’ .

Http operation Creator Interface

The interface shown will redirect the function to the more complex interface such as delete interface that have predefined method value as mentioned. These will be useful if you want to use more ways of accessing the database. Although, it is okay to use the four operation types: CRUD.

GraphQL — Essential or not?

Many backend frameworks provides automated middleware services. Thus, many disregard the importance of understanding middleware. However, in a complex environment, specifically in professional work, we must keep in mind to provide a clean structured architecture and codes. By learning GraphQL and Apollo Server, logic and flow are easier to maintain throughout the flow in the software architecture.

--

--