FeathersJS makes it really easy to write realtime web API’s. I want to talk about how you can emit data from your hooks. I had an application which had two services groups and group-access , a user could only fetch items from groups if they had a record in the group-access collection.

But what this meant was when a user was granted access via the group-access service they would have to reload the page in order to re-fetch groups to reflect the new access.

 record is created this hook will run and will load the group via a 

 and add some additional params so that we can use these within the 

Be sure to update the path so that it will emit using that path / service name.

In the above publish snippet, we are only going to publish realtime data if we have come from an internal 

, we can verify this by checking the property we added to the context in the 

 call. In a real app you would probably be emitting based on some other checks.

What this will do is filter all the channels to only that of 

 event happens the created item will be added to the list of 

 record is deleted, as such revoking the user access. We can 

 event, which if configured the client will be listening for, thus removing the record from the list.

FeathersJS Emitting

Having a smooth deployment pipeline is every developer's dream to ensure that smooth they can concentrate on developing and pushing features and that they get deployed fast and with little friction. I am going to walk through how to make that happen with Google Cloud Functions / Google Cloud Run using Gitlab CI.

First, you will need to create a service account that will have admin permission, I did this for both GoogleCloudFunction and GoogleCloudRun roles to future-proof the service account.


The next part is allowing that service account access, I ran the following to grant it access to the main service account to perform necessary operations:


gcloud iam service-accounts add-iam-policy-binding <project_id>-compute@developer.gserviceaccount.com --member serviceAccount:<service_account>@<project_name>.iam.gserviceaccount.com --role roles/iam.serviceAccountUser

Once the service account is created, you will need to create an API key which is recommended to be in JSON. This will automatically be downloaded which you will need to use later.

You can then go ahead and create the gitlab-ci.yml which will configure to create the deployment.

As you can see there are a couple variables we will need to set within the Gitlab CI settings, there are options to create a Gitlab secret as a File which we will use for the JSON service account API Key, we will create a normal variable for the Service Project.

Once you have configured the CI secrets, you should be able to push your changes and see your code get deployed and you can enjoy smooth deployments!

Gitlab CI Google Cloud Function

Let's start by talking about what a resolver is. A GraphQL Resolver is a function that is responsible for populating the data for a single field in your schema. What does this mean? Let's try to break it down, here is some data first:

We have a simple object which contains a name property and an array of hobbies. Given the following Schema and initial query resolver, we can see how these resolvers work.

 being the main entry point for all our GraphQL queries. The 

 definition, so we can now query for the "name" & "hobbies" properties. The 

 within our resolver is the data that in our instance is in memory, but this could also be a database lookup or even an API request. Given the following query:

The entire data object will be loaded, but only what was requested which was the 

But say we wanted to do something extra for the 

 property, we could do this within a resolver, for example, add an image URL. We would need to create a resolver for that property and it would look something like, which would be a specific resolver for the hobbies when queried within the person context:

Don't forget to update the type definition for 

We can also be more generic and have a resolver for the 

 definition, which would look something like:

This gives you the flexibility if you want to have the resolver for that property always do the same thing, or if you want it to do something more specific when fetched within a specific parent property context.

You can have the two resolvers together but the top-level 

 one will resolve last and as such will take precedence.

FeathersJS Emitting

Tags:

Popular Stories

Gitlab CI Google Cloud Function

Understanding GraphQL Resolvers