 asking how they can customize the LocalAuth to implement some additional user verifications and throw their errors. I thought I would walk through how easy it is in v4 to do this by extending the 

. The LocalStrategy refers to the auth strategy which is used for a username/email & password authentication, as opposed to JWT or OAuth.

 will verify the username/email and password combination. It will throw an error if the password and username/email combination do not match. But sometimes you may want to do more than verify the username/email & password.

 shows, you can customize how the user is looked up so that you can restrict to only active users:

In the above snippet, we can see that to create our custom strategy we extend the 

 which is used to do the email lookup. This should either return a valid user which will then be used to compare passwords or return no users which will by default throw a 

 error. You can change the message of the error by configuration which can be found 

To extend it even further, we might want to throw a different error or a custom error then we can do the following:

 so that we can use the existing implementation of fetching the user. Then we can check the user that is returned to see whether they are in support of coffee.

Both of the above methods can be used in combination together also!

FeathersJS Customise Local Auth Strategy

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 Customise Local Auth Strategy

Tags:

Popular Stories

Gitlab CI Google Cloud Function

Understanding GraphQL Resolvers