DEV Community: Jose Luis Fonseca

Do you really need an API?

Jose Luis Fonseca — Tue, 29 Sep 2020 03:00:38 +0000

Disclaimer: I will not try to sell you whether or not you should build an API or not in your projects. This is an article based on my personal experience with GraphQL, JSON APIs and not API at all.

Let's start by talking about my experience with JSON APIs

I've been building this things for over 7 years, during that time I've been using many different tools to create, document and test them. Usually when building an application that needs an API, I would start by thinking about the resources we will need, users roles etc. Then I would think about the way we can store the information about them, a MySQL database? maybe a NoSQL? who knows?.

One thing has been consistent across all of the options and flavors I've tried and that is the need to build a consistent, performant and useful API for the clients that will use it and for that I always consult the mobile and front end developers who at the end of the day are the ones that will interact with it.

During the time I've been doing this, we ran into several issues with REST, issues that can be solved pretty quickly, let's talk about the most common ones one by one.

Relationships

Many times the users will need to get a list of resources that have a relation to another resource, the typical example is Posts and Authors. The post is written by an author. so every time you get a post you will need to get the author for that post. The naive way of doing this is looping through the resources and calling the authors endpoint to get the author and display it. So if you have a page with 10 posts, you will be making 11 API calls in total just for that, which is not ideal and is worse when you have pages of 50. The way we typically solve this is by using includes, meaning in your API call for the posts list you append a query string parameter to the endpoint asking to include the authors. It will look something like this:

GET /api/posts?include=authors

The API server can lazy load this relations and deliver all of the information needed in a single API call, our server is powerful enough to handle that and should not be any issue anymore.

Permissions

One other thing we usually come across is the ability to show or not show certain information depending on who is the user or entity requesting it, this is usually solved by using an Authorization system that is able to identify who is requesting the information and what is able to see, most of the times this is solved by using a combination of OAuth 2 and a permissions system tied to a role or permissions list attached to the user that we can check against.

Use Case specific endpoints

This is something that always comes up mostly when working with mobile applications that may have limited network connectivity, if we have a screen that requires information from multiple resources, we may be asked by the mobile or front end team to create specific endpoints to get all the data needed for the screen in a single network call, in this cases we may accept to create such endpoint or we can work together in a possible solution like caching or something like that.

Documentation

There are many ways to document an API, some people use Swagger or OpenAPI, others prefer using static site generators, others use API documentation tools like Readme.io or framework specific tools. I don't think there is a lot of tooling issues here other than developer laziness to properly document the endpoints and what they need.

Now let's talk about my experience with GraphQL

GraphQL has gained a lot of popularity over the last few years, I think is a great tool and specification and that it has a lot potential and use cases, the question is, Do you need GraphQL in your project?

I started working with GraphQL because a friend of mine (and my boss at the time) presented me this idea of a query language over HTTP that would allow us to build better APIs for our clients. At first I though it was unnecessary and I could not really see the benefits I would get from it instead of using a normal JSON or REST API. However we decided to give it a try and after a little bit more than 2 years of working with it I feel more confident to talk about when you should and should not use it.

The first thing you need to know about me is that I have never faced the issues GraphQL is designed to solve, so to me was really hard to reset my mindset of converting resources into queries and mutations and I was very exceptical about the idea in general.

In GraphQL you don't use HTTP status codes, because those are tied to HTTP and one of the goals of GraphQL is to be protocol agnostic in that sense. So seeing errors in the API with a 200 OK status code was shocking.

What is GraphQL

First of all, REST and GraphQL are 2 different things, they are not to be compared because you would be comparing apples and oranges, however, many people compare them because they have a use case in common. Serve and receive information between systems.

GraphQL is a query language, basically you define your data model using GraphQL SDL and then you allow your clients query or mutate the information in your backend using a typed system. If you think about it that way its great, because you can let your clients decide what they fetch and it will give you a lot of flexibility for the frontend. This also allows for smaller response bodies and depending on the engine you use to execute these queries your backend become more or less complex.
Of course I can't define every single aspect of GraphQL here but having this general idea will give us a few tools for the main topic.

How is that different from traditional APIs?

At first I did not really see any difference, it was more like a different way of doing things, our first GraphQL API was pretty much a port of the traditional CRUD operations defined on queries and mutations, so we first tried to make a 1:1 model of what we were used to do in a REST API, we ended up with something like this

// GET api/users => users: [User]

Our GET users resource became a users query, returning an array of user objects

// POST api/users => createUser(input: CreateUserInput!): User

Our POST users resource to create a user became a createUser mutation that receives the payload and returns a user object

// PUT api/users/:id => updateUser(id: ID!, input: UpdateUserInput!): User

Our PUT users resource to update a user became the updateUser mutation receiving a user ID and a payload, returning a User Object.

And so on...

This felt weird to be honest, however we did get a few things out of the box like the documentation and a stronger typed system to define our schemas and data model, although we could have achieved something similar with OpenAPI and JSON Schema.

As the timed passed we learned more and realized this was not really the way we should have done it, so our second API was more use case oriented, we started creating queries and mutations based on the actual need of the app instead of plain objects that mimic the database structure, we started creating queries like dashboardCountsReport or upgradeUserPlan and it felt a little better, we where creating the access to the information the frontend needed without worries that our API would be less REST like.

So this project went good and everyone was happy and we though that we were conquering the GraphQL world. Then the next question came to my mind. What if another app needs this API and we don't have the use cases developed in the schema for it? isn't the purpose of GraphQL allowing the client to fetch what they need?.

Don't get me wrong, the API works and it does what it is suppose to, it just feels weird again.

This led me to believe that "one API fits all" approach is really hard to accomplish with both GraphQL and traditional JSON or REST APIs.

I must say however that given the nature of native mobile apps and the limited connectivity they sometimes have, being able to deliver information in smaller response bodies and letting the client choose what to show including relationships in less network round trips was a huge gain for us. We really saw some of the potential GraphQL has in those situations.

So, do I need an API or not?

My answer to this questions in tech are always, "It depends". And the reason for that is that every use case is different, every problem may have different solutions and there are MANY factors to consider before choosing what to use.

So in order to alleviate a little bit this issue, I've come up with the following reasons to consider when starting a project and deciding what to use.

The first questions I ask myself are:

Is this a website or a web app?

Many times your clients will come to you saying they need an app, and after they expose their idea you realize they want to build a blog with a few sections that require some interactivity and maybe it needs to be responsive, but it does not need to be downloaded from an app store and probably needs really good SEO. In this situation I tend to run away from making an API with a React or Vue SPA, is just overkill, KISS! (Keep it simple Stunning young man/woman XD).

Is this a web app with a single point of access or client?

Let's say your client wants to build a web app with user registration, probably some Stripe integration for subscriptions and features that the client can access based on the tier of their plan, BUT, without other clients accessing this like a iOS app or a KIOSK Android app. In this situation I would think on a simple Laravel app with blade and a few Vue JS components for interactivity. I would not think of it as an SPA that needs an API. Still KISS! (Keep it simple Stunning young man/woman XD).

Is this a Mobile App that will go into a store?

So here, you are thinking about a backend that will serve the information for your App, app that will be deployed to a store and that won't persist information locally and needs to store it "In the cloud". Here is where I start asking a subset of questions about the use case to get a closer to our best solution for our use case.

How many clients will access this API?

How many of those clients have different use cases?

Is caching at the API Server level important?

To help here, I always refer to an old friend (we are not really friends, he is too famous and important to know about me XD), Phil Sturgeon who created a very effective and helping decision tree to choose the right API Paradigm. I encourage you to go read his article and come back.

https://phil.tech/2018/picking-an-api-paradigm-implementation/

Now that you are back, you may have a better idea how the answer to those questions may help you identify if you need a JSON or REST API, or if you need to create GraphQL server.

I've used both, GraphQL and REST and I can say that you can really make a mess with both, but also you can make GREAT things with both, so be wise picking your paradigm and don't forget that with a great power, comes a great responsibility, and you should ALWAYS look for your client's, the systems or people that will use your API (or not) providing them the tools and information to set them up for success. No matter the paradigm you use, if you have a great developer experience your APIs will be loved.

What about BAAS? GRPC? other protocols?

Well I've never worked with GRPC so I can't talk about it. BAAS systems like Amplify (AWS AppSync) or Firebase are also great options if you are looking for vendor locking and auto scale and you are not worried about the costs, look for this options, they may be a good fit. What I do want to make sure you do is not create an API if you don't really need it. Working in a blog in react with a headless CMS when you just want to publish some articles is overkill.

Happy Coding!

Laravel GraphQL demo app

Jose Luis Fonseca — Wed, 29 Jul 2020 02:12:59 +0000

In the last few months i've been working on a series of videos (18 in total) where I talked about how to create a GraphQL server with Laravel and then I added a Vue JS frontend, the videos are in Spanish and they were part of a small series of screencast I was doing at the time due to the Covid lockdown.

I've decided to finish the demo app and put it online for anyone who wants to see a way of doing this kind of work and maybe it can also be education material some who ever wants to start writing GraphQL APIs with Laravel.

I hope this is useful for some people!

The code is in Github!

joselfonseca / contable

Contable

This is just an example app with a GraphQL server and a Vue JS client.

Credits

View on GitHub

Happy Coding!

GraphQL Auth with Passport and Lighthouse PHP

Jose Luis Fonseca — Fri, 02 Aug 2019 02:49:45 +0000

Writing a GraphQL API with Lighthouse PHP and Laravel is really fun, but something that you always have to do is add authentication. This is a common task that Laravel already covers with Passport, but what if you want to have your login and refresh token endpoints as mutations? That is actually a good idea since you don’t really have to document your authentication mechanisms apart from your GraphQL API. You can have it with mutations as well. This is what inspired me to write a little package called Lighthouse GraphQL Passport Auth which at first seems like a long name and to tell you the truth, it is. But let’s dive into how to use it and we worry about the name later XD.

Installation and configuration

First thing we need to do is install the package, now please keep in mind that Lighthouse PHP is required as well as passport, so why don’t we install it in one shot? In a brand new laravel app please enter:

composer require nuwave/lighthouse laravel/passport joselfonseca/lighthouse-graphql-passport-auth

Now let’s configure each of the packages starting with Laravel Passport, for that we are going to first run the migrations.

php artisan migrate

Then we should run the passport Install command.

php artisan passport:install

Then add the HasApiTokens trait to your user model


namespace App;

use Laravel\Passport\HasApiTokens;
use Illuminate\Notifications\Notifiable;
use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable
{
    use HasApiTokens, Notifiable;
}

Now we should register the passport routes as we still need them to be able to get tokens internally.

namespace App\Providers;

use Laravel\Passport\Passport;
use Illuminate\Support\Facades\Gate;
use Illuminate\Foundation\Support\Providers\AuthServiceProvider as ServiceProvider;

class AuthServiceProvider extends ServiceProvider
{
    /**
     * The policy mappings for the application.
     *
     * @var array
     */
    protected $policies = [
        'App\Model' => 'App\Policies\ModelPolicy',
    ];
    /**
     * Register any authentication / authorization services.
     *
     * @return void
     */
    public function boot()
    {
        $this->registerPolicies();
        Passport::routes();
    }
}

Once we have this let’s add the passport driver to the API guard in the config/auth.php file.

'guards' => [
    'web' => [
        'driver' => 'session',
        'provider' => 'users',
    ],
    'api' => [
        'driver' => 'passport',
        'provider' => 'users',
    ],
],

This should conclude the passport configuration.

Now let’s configure and install the Lighthouse PHP package. since it was already pulled from composer we just need to run the following commands to publish the default schema.

php artisan vendor:publish --tag=lighthouse-schema

This command will create a file in graphql/schema.graphql with the following schema

"A datetime string with format `Y-m-d H:i:s`, e.g. `2018-01-01 13:00:00`."
scalar DateTime @scalar(class: "Nuwave\\Lighthouse\\Schema\\Types\\Scalars\\DateTime")

"A date string with format `Y-m-d`, e.g. `2011-05-23`."
scalar Date @scalar(class: "Nuwave\\Lighthouse\\Schema\\Types\\Scalars\\Date")

type Query {
    users: [User!]! @paginate(type: "paginator" model: "App\\User")
    user(id: ID @eq): User @find(model: "App\\User")
}
type User {
    id: ID!
    name: String!
    email: String!
    created_at: DateTime!
    updated_at: DateTime!
}

If you have this file you should be ready to continue with the Lighthouse GraphQL Passport Auth package.

To get the values you need to open your database client and grab the password oauth client from the oauth_clients table, get the client id and secret and put them in the .env file

PASSPORT_CLIENT_ID=2
PASSPORT_CLIENT_SECRET=69YJomGV9plchWIkGD2PyKBBTHfkNA7H83iYGc6j

Once you do that, publish the package configuration and default schema.

php artisan vendor:publish --provider="Joselfonseca\LighthouseGraphQLPassport\Providers\LighthouseGraphQLPassportServiceProvider"

This command should publish 2 files, the config/lighthouse-graphql-passport.php and graphql/auth.graphql file. For convenience and to be able to have better control over the auth schema lets update the config file to use the published schema by changing the value for the schema property to the path to the published file like this:

'schema' => base_path('graphql/auth.graphql')

This will allow us to manipulate the schema if we need to extend it or make changes to the resolvers.

Now let’s remove the user type from the auth schema since we already have it in the default one exported before. Go to the graphql/auth/graphql file and remove the following type

type User {
    id: ID!
    name: String!
    email: String!
}

Once we do that, we need to add a default mutation to the schema so the auth can extend it or we can simply move the auth mutations to the Mutation type in the main schema file. So look for this code in the graphql/auth.graphql file and move it to graphql/schema.graphql file

extend type Mutation {
    login(input: LoginInput @spread): AuthPayload! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\Login@resolve")
    refreshToken(input: RefreshTokenInput @spread): RefreshTokenPayload! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\RefreshToken@resolve")
    logout: LogoutResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\Logout@resolve")
    forgotPassword(input: ForgotPasswordInput! @spread): ForgotPasswordResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\ForgotPassword@resolve")
    updateForgottenPassword(input: NewPasswordWithCodeInput @spread): ForgotPasswordResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\ResetPassword@resolve")
    register(input: RegisterInput @spread): RegisterResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\Register@resolve")
    socialLogin(input: SocialLoginInput! @spread): AuthPayload! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\SocialLogin@resolve")
    verifyEmail(input: VerifyEmailInput! @spread): AuthPayload! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\VerifyEmail@resolve")
    updatePassword(input: UpdatePassword! @spread): UpdatePasswordResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\UpdatePassword@resolve") @guard(with: ["api"])
}

Then remove the extend word

type Mutation {
    login(input: LoginInput @spread): AuthPayload! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\Login@resolve")
    refreshToken(input: RefreshTokenInput @spread): RefreshTokenPayload! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\RefreshToken@resolve")
    logout: LogoutResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\Logout@resolve")
    forgotPassword(input: ForgotPasswordInput! @spread): ForgotPasswordResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\ForgotPassword@resolve")
    updateForgottenPassword(input: NewPasswordWithCodeInput @spread): ForgotPasswordResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\ResetPassword@resolve")
    register(input: RegisterInput @spread): RegisterResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\Register@resolve")
    socialLogin(input: SocialLoginInput! @spread): AuthPayload! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\SocialLogin@resolve")
    verifyEmail(input: VerifyEmailInput! @spread): AuthPayload! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\VerifyEmail@resolve")
    updatePassword(input: UpdatePassword! @spread): UpdatePasswordResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\UpdatePassword@resolve") @guard(with: ["api"])
}

You should now have your schema files like this

graphql/auth.graphql

input LoginInput {
    username: String!
    password: String!
}

input RefreshTokenInput {
    refresh_token: String
}

type User {
    id: ID!
    name: String!
    email: String!
}

type AuthPayload {
    access_token: String
    refresh_token: String
    expires_in: Int
    token_type: String
    user: User
}

type RefreshTokenPayload {
    access_token: String!
    refresh_token: String!
    expires_in: Int!
    token_type: String!
}

type LogoutResponse {
    status: String!
    message: String
}

type ForgotPasswordResponse {
    status: String!
    message: String
}

type RegisterResponse {
    tokens: AuthPayload
    status: RegisterStatuses!
}

type UpdatePasswordResponse {
    status: String!
    message: String
}

enum RegisterStatuses {
    MUST_VERIFY_EMAIL
    SUCCESS
}

input ForgotPasswordInput {
    email: String! @rules(apply: ["required", "email"])
}

input NewPasswordWithCodeInput {
    email: String! @rules(apply: ["required", "email"])
    token: String! @rules(apply: ["required", "string"])
    password: String! @rules(apply: ["required", "confirmed", "min:8"])
    password_confirmation: String!
}

input RegisterInput {
    name: String! @rules(apply: ["required", "string"])
    email: String! @rules(apply: ["required", "email", "unique:users,email"])
    password: String! @rules(apply: ["required", "confirmed", "min:8"])
    password_confirmation: String!
}

input SocialLoginInput {
    provider: String! @rules(apply: ["required"])
    token: String! @rules(apply: ["required"])
}

input VerifyEmailInput {
    token: String!
}

input UpdatePassword {
    old_password: String!
    password: String! @rules(apply: ["required", "confirmed", "min:8"])
    password_confirmation: String!
}

graphql/schema.graphql

"A datetime string with format `Y-m-d H:i:s`, e.g. `2018-01-01 13:00:00`."
scalar DateTime @scalar(class: "Nuwave\\Lighthouse\\Schema\\Types\\Scalars\\DateTime")
"A date string with format `Y-m-d`, e.g. `2011-05-23`."
scalar Date @scalar(class: "Nuwave\\Lighthouse\\Schema\\Types\\Scalars\\Date")

type Query {
    users: [User!]! @paginate(type: "paginator" model: "App\\User")
    user(id: ID @eq): User @find(model: "App\\User")
}

type Mutation {
    login(input: LoginInput @spread): AuthPayload! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\Login@resolve")
    refreshToken(input: RefreshTokenInput @spread): RefreshTokenPayload! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\RefreshToken@resolve")
    logout: LogoutResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\Logout@resolve")
    forgotPassword(input: ForgotPasswordInput! @spread): ForgotPasswordResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\ForgotPassword@resolve")
    updateForgottenPassword(input: NewPasswordWithCodeInput @spread): ForgotPasswordResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\ResetPassword@resolve")
    register(input: RegisterInput @spread): RegisterResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\Register@resolve")
    socialLogin(input: SocialLoginInput! @spread): AuthPayload! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\SocialLogin@resolve")
    verifyEmail(input: VerifyEmailInput! @spread): AuthPayload! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\VerifyEmail@resolve")
    updatePassword(input: UpdatePassword! @spread): UpdatePasswordResponse! @field(resolver: "Joselfonseca\\LighthouseGraphQLPassport\\GraphQL\\Mutations\\UpdatePassword@resolve") @guard(with: ["api"])
}

type User {
    id: ID!
    name: String!
    email: String!
    created_at: DateTime!
    updated_at: DateTime!
}

Lastly we need to install the GraphQL playground we will use to send queries and mutations to our GraphQL server, for that run the following command

composer require mll-lab/laravel-graphql-playground

This is ready for tenting now!

Testing the auth mutations

Let’s start by running the PHP dev server

php artisan serve

This will open the port 8000 in our localhost for us to run the project, let’s navigate to http://127.0.0.1:8000/graphql-playground and you should see the playground like this

Now let’s create a user using a simple console command so we can log in using our graphql API. In the routes/console.php file enter

Artisan::command('user', function () {
    \App\User::create([
        'name' => 'Jose Fonseca',
        'email' => 'myemail@email.com',
        'password' => bcrypt('123456789qq')
    ]);
})->describe('Create sample user');

Then run the command in the console

php artisan user

Now that we have a user to test with, lets run the following mutation in the GraphQL Playground

mutation {
  login(input: {
    username: "myemail@email.com",
    password: "123456789qq"
  }) {
    access_token
    refresh_token
    expires_in
    token_type
    user {
      id
      email
      name
      created_at
      updated_at
    }
  }
}

This should give you the following response

{
  "data": {
    "login": {
      "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6Ijk3NDE3MTI1YjBmNjQyZDNkZDljMDkwOGJiNTM2NDQ5YTYwZWU5ZTQ0ZTBkYzEzY2E5M2FhNGFjODI5ZWRiNzkwMWZhZmY5NzVhZTc5MjRiIn0.eyJhdWQiOiIyIiwianRpIjoiOTc0MTcxMjViMGY2NDJkM2RkOWMwOTA4YmI1MzY0NDlhNjBlZTllNDRlMGRjMTNjYTkzYWE0YWM4MjllZGI3OTAxZmFmZjk3NWFlNzkyNGIiLCJpYXQiOjE1NjE0MDkyMDMsIm5iZiI6MTU2MTQwOTIwMywiZXhwIjoxNTkzMDMxNjAzLCJzdWIiOiIxIiwic2NvcGVzIjpbXX0.CZOpXN0mFHXAQexpA4-FPMOcV-bdZRJD7zUK7guzethg9KUMrALhzgwfQZJv3w74Gnj54aAbdswHBwZEt9DREyEer7Ht0c8108amOllPqb-ydLET1RL1oYCE9H9vvUK0ZafLp09pMrXKot6UcViGOy97KF7YilAvaFfyGxSOmTTZyn0noe9F2ztIOPd3u9XuPuTR5yL-NqHufTTtyJkdQ2xPo03bF4tRfpMXQ5prnIJi4rxmBkpASwMwVraL4lVSZg_9STWMxXWWFdvmXydkNUtQSAftQyHmwMy33OOTxRtFRDN_1Y9wW7U9okVRM-gindkx0o_EB7ekcP1mvHc2PwxwWPMfFxezex98wYX3jTo8y7CN4vDrgUdXqrKkFc6JzwBgn8q_f7c5SzbzxR824h6ujFzSgMaUk_8zKtHX_qgDqaqPVzTebazQ0Pu9PNoYcCkQi5bNldCGuuaMsMxz3H-CWstR4_pAj9_jeKdvC5MA0OkQ30b3RlSmhSqb65LfZEU-y3wG62FKHD49JxBOpPh_Ga8SOQvfOCIL3SzURX9uOvSgcprQqLBYkhJNJC0gobAFgrKHbDhrBVvGH5U4BbIPVX-gnhR44aoyIf8sXFJQkPJJ7-p8HrCqDqjahrlDXsf4DRZGaVJJFhX2VcWAkCcQA2yJ1LSS1XpNU5oL-x4",
      "refresh_token": "def502004531ba2a174546464239e59c3d07332f8aec44bf95db59ba578bcb58c1986dd494d887c79282daf7379d2959b35816e07245ad237e5fa5e6b3ea1ff19ca0058aa82abc4d0abad427eb045b894c7591e4e248d684ea0c6772011ac1723d3d63805e0e148ec0875277072e39d9ecafcbe55d29b28607dc3ea9f85bdc0ca88aadca41b97e8f061b9b326dc922708f6826aee7e2e3296891e923fd9b5386b4c99d46e9832cb8e191c63bb31394a3dc92a8fc1b907925e9c1888d8b0c4d8c30ea330785dd429623e93979670856fdb5bf80c6c8cac08dc7d040d796e535aa082e241dd38b4ab7a4b0055d554cd85888533c76af594bed20dddcded751bfecd0ffdb741169f204c732cef0e2c49c26ec81de9dd8099b5ab1a481283f70c9685a11ca7018c259688601359722aee0f527c95b8b48062be81d414ce3e10a334d8b5c4f64c25b248c0b76bc40596b99580e38310e7d3a4e82c910276645101d821f",
      "expires_in": 31622400,
      "token_type": "Bearer",
      "user": {
        "id": "1",
        "email": "myemail@email.com",
        "name": "Jose Fonseca",
        "created_at": "2019-06-24 20:43:53",
        "updated_at": "2019-06-24 20:43:53"
      }
    }
  }
}

That is IT! you can now use the token in your GraphQL API!

Testing a protected query

Let’s modify the users query to require authentication with passport, for that open the graphql/schema.graphql file and update the users query with the following

users: [User!]! @guard(with: ["api"]) @paginate(type: "paginator" model: "App\\User")

Now try to run the a users query

{
  users(count: 20){
    data {
      id
      email
    }
  }
}

This should give you an authentication error like the following

{
  "errors": [
    {
      "debugMessage": "Unauthenticated.",
      "message": "Internal server error",
      "extensions": {
        "category": "internal"
      },
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "users"
      ],
      "trace": [
...
}

This means the query needs to have the access token in the request. To do that in the GraphQL Playground add the authorization header with the token we generated before

Re run the query and you should have the result just fine!

As you can see the query is protected and you can now use authentication in your GraphQL API.

Now go a head and try the rest of the mutations available to like refresh the token or reset a password.

If you like this little package please start it in Github and let me know if you run into any issues.

joselfonseca / lighthouse-graphql-passport-auth

Add GraphQL mutations to get tokens from passport for https://lighthouse-php.com/

Lighthouse GraphQL Passport Auth (Laravel ^7.0 / Lighthouse ^4.0)

GraphQL mutations for Laravel Passport using Lighthouse PHP.

Tutorial

You can see this tutorial for installation and usage.

Documentation

Find the detailed documentation in the documentation site

Change log

Please see the releases page https://github.com/joselfonseca/lighthouse-graphql-passport-auth/releases

Tests

To run the test in this package, navigate to the root folder of the project and run

    composer install

Then

    vendor/bin/phpunit

Contributing

Please see CONTRIBUTING for details.

Security

If you discover any security related issues, please email jose at ditecnologia dot com instead of using the issue tracker.

Credits

License

The MIT License (MIT). Please see License File for more information.

View on GitHub

Happy Coding!