Right now, my motive for finishing is not really to make a viable business but to just use this as a proof-of-concept. If a viable business comes from my efforts, well so be it.

The idea: I'm creating an app that will allow users to make money through the platforms they already use, such as Zoom and Instagram. Of course, there's more to it, but that's the gist.

My first stack: I started this project with a HUGE stack: Laravel and NuxtJS. In actuality, each of these technologies is full-stack. So why put them together?

Well, I love Laravel. Plus, Laravel has far superior tools with authentication and API building. Ok so why not just use Blade as your frontend?

Well, I have nothing against Blade, it's just that I hardly ever use it and I preferred to use a JavaScript framework in the frontend to make frontend logic much easier to work with.

I used NuxtJS on a previous project and wanted to use it again. It was my first serious foray into Vue and I liked it. I enjoyed building with this stack until I needed to do state management. It was then that I realized that my knowledge in Vue wasn't robust enough. I also realized how little I cared to learn more, so I decided to switch to React.

• On the flip side, it was from this stack that I wrote one of my first blog posts first blog post on Hashnode!

My second stack: I switched this project to Laravel and NEXT.js. Why NEXT?

I love React frameworks like NEXT.js and Gatsby and I've seen the power of JAMstack sites last year. I really wanted to use NEXT.js in a real-world project and I thought this would've been the perfect time. NEXT has so many great tools, including the fact that I could mix SSG and SSR pages. With NEXT I could make the website performant without much work.

To be honest, working through this stack was comparatively a breeze. However, it was here that I lost all motivation completely. The reason is pretty simple: it was too much work! One of the problems was with implementing APIs like Zoom. Zoom needs a backend to interact with, but using my Laravel API to do this would've been more work, so I ended up just using the server-side of NEXT for this. It wasn't too hard since it's basically Node, but it's a lot of work.

Translating from Vue to React was one thing, but when I realized the scale of work to implement proper authentication in both the frontend and backend and other things that make an app an app, my mind just decided to take a rest... indefinitely.

The stack now: I tried Laravel Jetstream and Laravel Breeze when they were released. Both times I tried the Inertia stack and both times I hated the experience. I hated how I had to go to multiple places to learn how to use this stack. However, in March, I watched a live stream of someone building an app with Laravel and Inertia and I decided to give it another shot (FYI, Inertia JS is the glue that connects the React/Vue/Svelte frontend with the backend without any need for an API).

I still was not a fan of the docs when I tried it again, but I understood a lot more than before. Not long after, something I thought would never happen, happened: I enjoyed it! It wasn't long until I wrote my first blog post about making a Laravel Breeze project with Inertia. This is why I decided to restart the project with this stack.

There are a few pros of using this stack:

• Natural routing with PHP. No need to install additional React libraries for that.
• No headaches with complex state and session management as PHP and Laravel have inbuilt tools for that.
• Laravel Breeze makes authentication a breeze.
• A dev can easily choose between React and Vue for the frontend. There's no more hard work to get React to fit in now because all we have to do is run $ php artisan breeze:install react.
• Laravel Mix is excellent, and we can install just about any styling system and libraries with relative ease, such as Emotion and PostCSS.

What now?: This is the first part of an n-part series detailing my journey in making this project. I like the concept of creating products in the open and I hope I can help it become mainstream. In the next few days, I will be writing a post about the advantages of the LIR stack (Laravel-Inertia-React) compared with other React frameworks and stacks. I'll also be writing part 2 soon detailing the current setup so look out for that.

Preliminaries:

• For a beginner's look into Gatsby with TypeScript, please check this article out.
• If you haven't already, install the Gatsby CLI by running $ npm install -g gatsby-cli.
• Create a new repository by running $ npx gatsby new {APP_NAME}. You could also do this by running $ npm init gatsby. Doing it this way will bring up some prompts that you could follow through to set your project up. Select None when it asks you for your preferred design system.
• Install Emotion by running $ npm install @emotion/react @emotion/styled gatsby-plugin-emotion.
  • Add gatsby-plugin-emotion to your list of plugins in gatsby-config.js.
  • Add Twin as a babel preset by going to package.json and add this snippet:

"babelMacros": {
    "twin": {
        "preset": "emotion"
    }
},

• Run $ tsc --init --jsx react to build the tsconfig.json file. You'll see a bunch of commented and uncommented lines.
  • Look for the following properties and uncomment them to get your file to look something like this:

{
  "include": ["./src/**/*"],
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "lib": ["dom", "es2017"],
    "jsx": "react",
    "strict": true,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "noEmit": true,
    "skipLibCheck": true
  }
}

• Create an empty Tailwind config file by running $ npx tailwindcss-cli@latest init.

First Steps:

• Because we're going to use the styled module from Twin Macro, we're going to have to make some adjustments so that the compiler doesn't scream at us. Let's add some types for React by running $ npm install --save-dev @types/react.
• Make a declaration file in the root called twin.d.ts and paste the following snippet in it:

import 'twin.macro'
import styledImport from '@emotion/styled'
import { css as cssImport } from '@emotion/react'

declare module 'twin.macro' {
    const styled: typeof styledImport
    const css: typeof cssImport
}

• In your tsconfig.json file, add "jsxImportSource": "@emotion/react", to "compilerOptions".
  • Change "jsx": "react" to "jsx": "react-jsx".
  • We'll then import our declaration file by changing the include line, like so: "include": ["./src/**/*", "twin.d.ts"],.

The Work Begins:

• Add a layout file making layout.tsx in src/components/ and add this snippet to it:

import React from 'react'
import { GlobalStyles } from 'twin.macro'

const Layout = ({ children, ...rest }) => (
    <div {...rest}>
        <GlobalStyles />
        {children}
    </div>
)

export default Layout

• Go to src/pages/index.js and rename it to src/pages/index.tsx. Add this snippet:

import React from 'react
import Layout from '../components/layout'

const IndexPage = () => {
    return (
        <Layout>
            <p>Hello World!</p>
        </Layout>
    )
}

export default IndexPage

• Create a Navbar component by making a Navbar folder and make an index.tsx file and a styles.tsx file.
  • We'll be importing tw and styled which will help us make styled-components with Tailwind.

The Work Continues:

• In the styles.tsx file, add this code snippet:

import tw, {styled} from 'twin.macro'

export const Nav = tw.nav`
    relative flex flex-wrap items-center justify-between px-4 py-5 
    md:px-24 lg:px-8 
`
export const InnerNav = tw.div`
    container px-4 mx-auto flex flex-wrap items-center justify-between
`
export const InnerMost = tw.div`
    w-full relative flex justify-between lg:w-auto lg:static lg:block 
    lg:justify-start
`
export const DropDown = styled.div((props: any) => [
    tw`lg:flex flex-grow items-center`,
    props.open ? tw`flex` : tw`hidden`
]) 

export const Logo = tw.a`
    leading-relaxed inline-block mr-4 whitespace-nowrap 
`
export const NavButton = tw.button`
    text-black cursor-pointer text-xl leading-none px-3 py-1 border border-solid 
    border-transparent rounded bg-transparent block lg:hidden outline-none 
    focus:outline-none
`
export const DropMenu = tw.ul`
    flex flex-col lg:flex-row list-none lg:ml-auto md:w-full md:items-center
    lg:justify-end
`
export const ListItem = tw.li`
    block
`
export const InnerItem = tw(ThisLink)`
    px-3 py-2 flex items-center font-sans font-semibold text-lg tracking-wide 
    text-gray-700 hover:text-gray-900 
`
export const ExtraButton = tw.a`
    text-black bg-transparent border border-solid border-gray-900 
    hover:bg-black hover:text-white active:bg-gray-600 font-sans font-semibold 
    uppercase text-sm px-4 py-2 rounded outline-none focus:outline-none mr-1 
    mb-1 mt-4 lg:mt-0 lg:ml-24
`
export const Bars = tw.div`
    mt-2
`
export const Bar = tw.div`
    w-8 h-1 bg-black mb-1 align-middle
`

• If you look at the code above, you'll see one styled module. This enables us to use props, which we'll need to pass our open data to.
  • NOTE: Don't pay too much to the names of these components. You can name them however you wish, as long as you can follow them and the people that will read your code can follow them.
• Now we need to get our components into index.tsx. This is where our markup will be housed.
  • If you look at the code below, you'll realize that we're using StaticImage. This component is used when we're not loading dynamic images.

import React from 'react'
import {Nav, InnerNav, InnerMost, DropDown, Logo, NavButton,
    DropMenu, ListItem, InnerItem, ExtraButton, Bars, Bar
} from './styles'
import {StaticImage} from 'gatsby-plugin-image'


const Navbar = () => {

    return (
        <>
            <Nav>
                <InnerNav>
                    <InnerMost>
                        <Logo href="/">
                        <StaticImage 
                            src="../../images/logo.png"
                            alt="logo"
                            width={180}
                            placeholder="none"
                        />
                        </Logo>
                        <NavButton
                            type="button"
                        >
                            <Bars>
                                <Bar />
                                <Bar />
                                <Bar />
                            </Bars>
                        </NavButton>
                    </InnerMost>
                    <DropDown>
                        <DropMenu>
                        <ListItem>
                                <InnerItem
                                    href="/products" 
                                    aria-label="Products"
                                >
                                    Products
                                </InnerItem>
                            </ListItem>
                            <ListItem>
                                <InnerItem
                                    href="/pricing" 
                                    aria-label="Product pricing"
                                >
                                    Pricing
                                </InnerItem>
                            </ListItem>
                            <ListItem>
                                <InnerItem
                                    href="/about" 
                                    aria-label="About us"
                                >
                                    About Us
                                </InnerItem>
                            </ListItem>
                            <ListItem>
                                <InnerItem
                                    href="/faq" 
                                    aria-label="FAQs"
                                >
                                    FAQs
                                </InnerItem>
                            </ListItem>
                            <ExtraButton 
                                href="/contact-us"
                            >
                                CONTACT US
                            </ExtraButton>
                        </DropMenu>
                    </DropDown>
                </InnerNav>
            </Nav>
        </>
    )
}

export default Navbar

• There are a few things that we need to do now. Currently, our navbar is responsive because of our CSS (Tailwind) styles. However, if we were to click on the hamburger button, nothing will happen. Hence, we'll need to tell React to listen for this click, and we'll need to define a method to expand our menu when clicked.
  • We'll add React's onClick event listener which will fire off our event handler, handleClick().
  • We'll then need to need to define our state that will say whether our navbar is open or not. The handleClick() method will then be in charge of facilitating our state change.
  • Finally, we'll pass our state to the extended component in our styles that has conditional styles depending on whether our navbar is open or not. We'll do this with a prop called open. Our markup will now look like this:

import React, {useState} from 'react'
import {Nav, InnerNav, InnerMost, DropDown, Logo, NavButton,
    DropMenu, ListItem, InnerItem, ExtraButton, Bars, Bar
} from './styles'
import {StaticImage} from 'gatsby-plugin-image'


const Navbar = () => {
    const [navbarOpen, setNavbarOpen] = useState(false)

    function handleClick(){
        setNavbarOpen(!navbarOpen)
    }

    return (
        <>
            <Nav>
                <InnerNav>
                    <InnerMost>
                        <Logo href="/">
                        <StaticImage 
                            src="../../images/logo.png"
                            alt="logo"
                            width={180}
                            placeholder="none"
                        />
                        </Logo>
                        <NavButton
                            type="button"
                            onClick={handleClick}
                        >
                            <Bars>
                                <Bar />
                                <Bar />
                                <Bar />
                            </Bars>
                        </NavButton>
                    </InnerMost>
                    <DropDown open={navbarOpen}>
                        <DropMenu>
                        <ListItem>
                                <InnerItem
                                    href="/products" 
                                    aria-label="Products"
                                >
                                    Products
                                </InnerItem>
                            </ListItem>
                            <ListItem>
                                <InnerItem
                                    href="/pricing" 
                                    aria-label="Product pricing"
                                >
                                    Pricing
                                </InnerItem>
                            </ListItem>
                            <ListItem>
                                <InnerItem
                                    href="/about" 
                                    aria-label="About us"
                                >
                                    About Us
                                </InnerItem>
                            </ListItem>
                            <ListItem>
                                <InnerItem
                                    href="/faq" 
                                    aria-label="FAQs"
                                >
                                    FAQs
                                </InnerItem>
                            </ListItem>
                            <ExtraButton 
                                href="/contact-us"
                            >
                                CONTACT US
                            </ExtraButton>
                        </DropMenu>
                    </DropDown>
                </InnerNav>
            </Nav>
        </>
    )
}

export default Navbar

The Work Ends:

• Let's go back to our styles.tsx file. This is where we'll get deeper into TypeScript. In React, we have the FC (Function Component) generic type which can be used on arrow functions to define and extend arrow function components. FC allows us to pass props into our component and helps us define default types for it as well. It also includes the children prop type by default, but we will be explicitly defining this in our component.
  • Next, we make a type called ButtonProps where we'll define the props that we know will be passed to our button component (type, children, onClick). For onClick, we'll define it with a function that uses React's default MouseEvent interface. TypeScript pros have a saying that you should never use the any type, but for brevity, we'll just give children an any type.
  • With the help of FC, we can then pass in our defined props to define our extended component.

import React, {FC, MouseEvent} from 'react'
import tw, {styled} from 'twin.macro'

type ButtonProps = {
    type: string,
    children?: any,
    onClick?: (event?: MouseEvent<HTMLButtonElement>) => void,
}

const ThisButton: FC<ButtonProps> = ({onClick, type, children, ...rest}) => 
    <button onClick={onClick} {...rest}>{children}</button>

...

export const NavButton = tw(ThisButton)`
    text-black cursor-pointer text-xl leading-none px-3 py-1 border border-solid 
    border-transparent rounded bg-transparent block lg:hidden outline-none 
    focus:outline-none
`

• Now in your layout.tsx file, import the Navbar component and place it right below the GlobalStyles component.

import React from 'react'
import { GlobalStyles } from 'twin.macro'
import Navbar from './Navbar'

const Layout = ({ children, ...rest }) => (
    <div {...rest}>
        <GlobalStyles />
        <Navbar />
        {children}
    </div>
)

export default Layout

Conclusion:

• If you try it out, you will notice that clicking on one of the links in the menu will bring you to a new page with the menu still open. To remedy this, in our Navbar/index.tsx file, we could pass an onClick event listener to each link component, which in our case is <InnerItem />.
  • If we need to, we can define our links like so:

import React, {FC, MouseEvent} from 'react'
import tw, {styled} from 'twin.macro'

type LinkProps = {
    href: string,
    "aria-label"?: string,
    onClick?: (event?: MouseEvent<HTMLAnchorElement>) => void,
}

const ThisLink: FC<LinkProps> = props => <a {...props} />
...

export const InnerItem = tw(ThisLink)`
    px-3 py-2 flex items-center font-sans font-semibold text-lg tracking-wide 
    text-gray-700 hover:text-gray-900 
`

• Don't feel distressed if you don't get these concepts right away. It just takes some practice, which to be honest. There are so many things that I still need to learn about TypeScript, and so far I'm liking the journey.

The Gist:

• After downloading and setting up Breeze in our project, we'll install the Inertia library for React by running $ npm install @inertiajs/inertia-react. Then we'll import it and redo our app.js file, like so:

import {InertiaApp} from '@inertiajs/inertia-react'
import React from 'react'
import {render} from 'react-dom'

const app = document.getElementById('app')

render (
    <InertiaApp
        initialPage={JSON.parse(app.dataset.page)}
        resolveComponent={name => import(`./Pages/${name}`).then(
  module => module.default
        )}
    />,
    app
)

• We'll need to import Twilio's SDK by running composer require twilio/sdk and ensure that we have our Twilio phone number, account SID, and auth token. We can get these from the Console.
• In our Twilio service, we can create a new conversation, create participants, create a new message, and return an array of the messages belonging to that conversation.
• In order for us to be able to "return back" with our data to the React frontend, we'll need to share Laravel Session data with Inertia. We do this by making a few adjustments in the AppServiceProvider.

<?php

namespace App\Providers;

use Illuminate\Support\Facades\Session;
use Illuminate\Support\ServiceProvider;
use Inertia\Inertia;

class AppServiceProvider extends ServiceProvider
{
    ...

    public function boot()
    {
        Inertia::share('flash', function(){
            return [
                'message' => Session::get('message')
            ];
        });
    }
}

• Because we're keeping this app simple without real-time capabilities, we will "cheat" by fetching our messages every three seconds. We'll track the length of our array to see when a new message was added and update accordingly.

    // Fetch messages
    async function getMessages(){
        const response = await fetch(`/convo/${chat.sid}/messages`)
        const json = await response.json()

        if (json.messages.length > arrLength){
            setMessages(json.messages)
            setArrLength(json.messages.length)
        }
    }

    // Fetch messages every three seconds and clean up once component unmounts
    useEffect(() => {
        const interval = setInterval(() => {
            getMessages()
        }, 3000)

        return () => clearInterval(interval)
    }, [])

This tutorial is just meant to show the basics of Laravel Breeze, Inertia, setting React up with Laravel and Inertia, and Twilio's Conversations API. A more detailed and real-world tutorial will be written up soon. But in the meantime, if you think you're up to it:

Click here for the full tutorial!

Prerequisites:

• Please read part 1 and part 2 of this series. Setup information can be found in those articles.
• It will be great to know what traits are, and how to make them. If you don't know already, I explain it in detail here.
• Our app will be headless (no frontend), so Postman will be needed.

First Steps:

• We'll need to make a DateTime Trait that will have all our methods concerning DateTime. Please follow the steps in the article mentioned earlier if you don't know how to create one. Name your Trait DateTimeTrait. We'll be importing the Carbon library to help us handle DateTime functions.
• Let's make a method that will get the current time in an Eastern timezone. You can use whatever timezone you wish, just make sure it's already supported by PHP. After that, we'll create a function that can convert any time that is passed to our trait to Eastern time.

<?php

namespace App\Traits;

use Carbon\Carbon;

trait DateTimeTrait {
    public function getCurrentTime(){
        $current = Carbon::now('America/New_York');
        return $current;
    }

    public function convertTimetoEastern($date, $tz){
        $newdate = Carbon::createFromFormat('Y-m-d H:i:s', $date, $tz)
                            ->setTimezone('America/New_York');
        return $newdate; 
    }
}

• For this article, the most important DateTime thing we'll need to do is to tell if the time of the event has passed the current time or not. We can do this by making a method that determines the difference between the current time and the event time.
  • In the below code, you'll see Carbon::parse(). This method is another way of instantiating Carbon and passing a time string to the object so that it can be manipulated.
  • With the new Carbon-readable date, we can use the diffInSeconds() method to get the difference in seconds. This method accepts a boolean as an optional second parameter to say whether we want an absolute value or not. Because we want our value to be positive or negative, we set it to false.

    public function getDateDifferenceFromNow($event_date, $timezone){
        $date = Carbon::parse(
            $this->convertTimetoEastern($event_date, $timezone)
        );
        $difference = $date->diffInSeconds($this->getCurrentTime(), false);
        return $difference;
    }

The Work Begins:

• The first thing we'll need to do is create a separate Form Request class that will send JSON responses to our API. Please refer to the first part of this series to learn how to do that. This Form Request will be called EventRequest and it will handle our validation.

<?php

namespace App\Http\Requests;

use App\Http\Requests\APIFormRequest;

class EventRequest extends APIFormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'name' => 'required',
            'start_time' => 'required',
            'end_time' => 'date_format:Y-m-d H:i:s|after:start_time',
            'venue' => 'required',
            'price' => 'required',
            'timezone' => 'required|timezone'
        ];
    }
}

• We'll make a custom rule called TimeTooLate by running php artisan make:rule TimeTooLate. We'll then import our newly-made DateTimeTrait.
  • Our new Rule class will have a constructor, a passes() method, and a message() method.
  • The passes() method takes in two parameters, $attribute and $value. The $attribute describes the name of the field that we'll be working with, which in this case, is start_time. The $value describes the value that is attached to that field. The $value param will be used in the passes() method to determine whether the rule passes or not.

<?php

namespace App\Rules;

use Illuminate\Contracts\Validation\Rule;
use App\Traits\DateTimeTrait;

class TimeTooLate implements Rule
{
    use DateTimeTrait;

    /**
     * Create a new rule instance.
     *
     * @return void
     */
    public function __construct(string $timezone)
    {
        //
    }

    /**
     * Determine if the validation rule passes.
     *
     * @param  string  $attribute
     * @param  mixed  $value
     * @return bool
     */
    public function passes($attribute, $value)
    {
        //
    }

    /**
     * Get the validation error message.
     *
     * @return string
     */
    public function message()
    {
        return 'The validation error message.';
    }
}

The Work Continues:

• We'll also need to pass the timezone to the TimeTooLate rule, so we'll utilize our constructor. We can strictly type our parameter so that it only accepts a string.

public $tz;

public function __construct(string $timezone)
{
    $this->tz = $timezone;
}

• In our passes() method, we need to make sure that it returns false so that message() can return an error message. With the getDateDifferenceFromNow() method in our DateTimeTrait, a positive integer is returned if the event date has surpassed the current date and time.

public function passes($attribute, $value)
{
    $difference = $this->getDateDifferenceFromNow($value, $this->tz);
    return $difference >= 0 ? false : true;
}

• Once this returns false, the message() method will fire. You can put anything here. Also, usually, you could access the name of the $attribute and bind it to your returned string by using :attribute. We won't use it here, but you're free to use it if you wish.

public function message()
{
    return 'It\'s too late to add this event now';
}

The Work Ends:

• We'll now need to implement our custom rule into our Request. First, import the TimeTooLate rule. To use it in our rules, we'll change the value for start_time into an array and include TimeTooLate as an element. We'll instantiate TimeTooLate, and pass in the timezone.

<?php

namespace App\Http\Requests;

use App\Http\Requests\APIFormRequest;
use App\Rules\TimeTooLate;

class ShowRequest extends ApiFormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'name' => 'required',
            'start_time' => ['required', 
                            'date_format:Y-m-d H:i:s', 
                            new TimeTooLate(request('timezone'))],
            'end_time' => 'date_format:Y-m-d H:i:s|after:start_time',
            'venue' => 'required',
            'price' => 'required',
            'timezone' => 'required|timezone'
        ];
    }

• Instead of creating a controller, let's create an API route that will have a closure that will validate our request. So go to routes/api.php and make one route where we'll test our enhanced validation mechanism.

<?php

use Illuminate\Http\Request;
use App\Http\Requests\EventRequest;
use Illuminate\Support\Facades\Route;

Route::post('event/new', function(EventRequest $request){
    $validated = $request->validated();
    dd($validated);
});

• Run $ php artisan serve.
• Open up Postman, and enter some data into the form-data section of the Body tab that matches the fields we're trying to validate. Make sure that your start_time is some time in the past. Once you run the request, it should look something like this:

Conclusion:

• If you didn't get that error, that means you didn't do the proper setup. You'll need to make the abstract class that we discussed in our first Laravel Validation article.
• There are so many possibilities you can accomplish by extending Rule objects. They're even better when you attach Traits into the mix, a group of methods that are not bound by the classes they are in.
• There is at least one more part to come for this Laravel Validation series. In the next article, we'll discuss how you can implement After Hook validation.

The Why:

• Traits provide a very easy way for code reuse in PHP applications.
• You can use traits pretty much anywhere in your application where you use classes.
• Static methods are supported. Usually, when using Traits, you'll initialize them by placing use TraitName; in the class (usually on top). However, you can create your trait methods statically, so you can save a line and use your trait methods, eg. TraitName::method().
• Abstract methods are supported.

The How: There's no default Artisan command to create Traits in Laravel, so you'll have to create them manually. It's as simple as creating MyTrait.php in app/Traits, and setting the namespace to namespace App\Traits. However, this can be a pain if you're creating multiple Traits, so I'll show you how I automate Trait creation.

• Create your command by running $ php artisan make:command MakeTrait. This will create a file in app/Console/Commands/.
• Create a stub, which is the file template that will be used to create the Trait, by running $ php artisan stub:publish.
  • This will create a Stubs/ folder in your root with a bunch of stub files. Create a new trait.stub file and make it look like this:

<?php

namespace App\Traits;

trait {{trait_name}} 
{
    /**
    * Create regular or static methods here
    */
}

• You'll need to make a few changes to your new MakeTrait command file. Instead of extending Command, you'll be extending GeneratorCommand. Also, you'll want to delete the __construct() and handle() methods since you're not going to need them.

<?php

namespace App\Console\Commands;

use Illuminate\Console\GeneratorCommand;

class MakeTrait extends GeneratorCommand
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'command:name';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Command description';
}

• For your $signature property, make it equal to 'make:trait {name};.
• For your $description property, make it equal to 'Create a new Trait.';
• Add a new $type property and let it be equal to 'Trait'. This property is used to tell you if the class type has been successfully created or if it already exists.
• Add a getStub() method to retrieve your stub. Also, make a getDefaultNamespace() method that will get the default namespace for the class.
• Finally, add a replaceClass($stub, $name) that will override the method that's in GeneratorCommand so that Laravel knows what to do with {{trait_name}}. Usually, it will look for DummyCommand or {{class}}. So in all, your command should look like this:

<?php

namespace App\Console\Commands;

use Illuminate\Console\GeneratorCommand;

class MakeTrait extends GeneratorCommand
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'make:trait {name}';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Create a new Trait.';

    protected $type = 'Trait';

    protected function getStub(){
        return base_path('stubs/trait.stub');
    }

    protected function getDefaultNamespace($rootNamespace){
        return $rootNamespace . '\Traits';
    }

    protected function replaceClass($stub, $name){
        $class = str_replace($this->getNamespace($name).'\\', '', $name);

        return str_replace('{{trait_name}}', $class, $stub);
    }
}

• Now create a new trait by running $ php artisan make:trait FooBarTrait. You'll see your new Trait in app/Traits.

Conclusion:

• In app/Console you will see a Kernel.php file. There's a property there called $commands where you can place the path for a command that may not be found by Laravel. By default, it will look directly in the Commands folder, as you may see in the commands() method below.
• One Trait that I always make in my projects is a DayTimeTrait. In a future article, I'll show you an advanced usage with Rules.

During my 'break' I gave Inertia with Laravel another chance and ended up liking it. I'm still not a fan of how Laravel devs still have to go to multiple places for docs, but it's what we have so far until the Laravel team or someone brave puts everything in one place. When I was getting reacquainted, I needed to upload my project to production. I'm a frequent user of Heroku because of their free plan, but getting PHP and Node to work together took a bit of work. Here's how I did it.

Pre-requisites:

• Make a Heroku account. It's totally free.
• Download and install the Heroku CLI.
  • Carefully follow the instructions and ensure that you have your login credentials set. You don't have to create a repository yet.
  • You must have git installed. If you don't, do it.
• Make a new Laravel project in your projects folder by running $ laravel new laravel-inertia-project in your terminal.

First Steps: In this tutorial, we'll be using Laravel Breeze, which is the simplest way to implement a Vue or React frontend in our Laravel project.

• Install Laravel Breeze by running $ composer require laravel/breeze --dev. Then we'll install Breeze and its Inertia stack by running these two commands:

$ php artisan breeze:install --inertia
$ npm install

• Once that's done, we'll need to set up React. Laravel Breeze and Inertia will automatically install Vue, so we'll need to do a bit of work here.

  • Run:

    $ npm install react react-dom
    $ npm install @inertiajs/inertia @inertiajs/inertia-react
    

  • Go to resources/js/app.js and make some changes so that we can build our own frontend instead of using Vue.

import {InertiaApp} from ‘@inertiajs/inertia-react’
import React from ‘react’
import {render} from ‘react-dom’

const app = document.getElementById(‘app’)

render (
    <InertiaApp
        initialPage={JSON.parse(app.dataset.page)}
        resolveComponent={name => import(`./Pages/${name}`).then(
  module => module.default
        )}
    />,
    app
)

• To ensure that Babel can understand the little JSX code that we’ll be writing, we’ll need to install a Babel preset by running $ npm install --save-dev @babel/preset-react. We can then use this preset by creating a .babelrc file in the root with this code:

{
    "presets": ["@babel/preset-react"]
}

• We'll need to go to resources/js and delete the Pages and Components folders you see there, and just replace it with a Pages folder with a file called HelloWorld.js in it.
• In HelloWorld.js, we'll make a simple Hello World app:

import React from 'react'

const HelloWorld = () => (
   <p>Hello world!</p>
)

export default HelloWorld

• Next, go to routes/web.php, and delete the routes that you see there. Then, we'll use Inertia to render our Hello World page without sending any data.

Route::get('/', function(){
    return Inertia::render('HelloWorld', []);
}

• Finally, go to webpack.mix.js and ensure that you see mix.js('resources/js/app.js', 'public/js'. If you see .vue() attached to mix, delete it or you'll get errors. Now compile your assets by running $ npm run dev.

The Work Begins:

• Run $ git init to set git up in your project. Then add your files to git by running $ git add ..
• Create a new Heroku app by running $ heroku create.
• Before we commit and push, we need to create a Procfile. This file will tell Heroku what commands to run when the application starts up. For PHP, the file will only have one line: web: vendor/bin/heroku-php-apache2 public/. Create Procfile in your root folder and copy-paste the line in the file, or run $ echo "web: vendor/bin/heroku-php-apache2 public/" > Procfile in your terminal. NOTE: It's best to create the file first before writing to it. You'll see less errors this way.

The Work Continues:

• Before we can push our work up to Heroku, we'll need to create two buildpacks. Buildpacks are scripts that make the right environment to run a programming language. Because we have React and Inertia, we'll need a buildpack for Node as well as PHP.
  • For PHP, run $ heroku buildpacks:set heroku/php.
  • For Node, run $ heroku buildpacks:add --index 1 heroku/nodejs.
  • NOTE: The --index 1 basically states that this buildpack will run first. The buildpack for the primary language must always be run last.
• We'll need to ensure Heroku does not ignore our devDependencies in package.json, which it does by default. Run $ heroku config:set NPM_CONFIG_PRODUCTION=false.

The Work Ends:

• Now we can commit and push our project up to Heroku:

$ git commit -m "First commit to Heroku"
$ git push heroku main

• NOTE: If for some reason the heroku remote wasn't added, run $ heroku git:remote -a {APP_NAME}. Go to your Heroku dashboard to see the name if you lost it.

• For Laravel to work, we'll need an APP_KEY. One is already set locally, but we need one for Heroku. Run $ heroku config:set APP_KEY={key}.

• Run $ heroku open to open and run the app. It should open to https://{APP_NAME}.netlify.app and you should see "Hello World" on your screen.

Conclusion:

• If you need to debug, Heroku provides logs for your app. Run $ heroku config:set LOG_CHANNEL=errorlog so your stack trace errors are logged there.
• I love Heroku because it's one of the best ways to host PHP apps for free.
• If you're on the free plan of Heroku, your app will 'sleep' at different intervals. If you don't like this behavior, especially as you're building out your app, you can just subscribe to their 'Hobby' plan which costs a dollar less than a Disney Plus subscription.

Preliminaries:

• The first thing that I did was install TypeScript globally by running npm install -g typescript.
• After that, I installed my Gatsby project and set it up.
• Now I needed to get TypeScript working with Gatsby. The Gatsby CLI is able to automatically set up TypeScript, but I stupidly declined, so I had to set it up manually.
  • I installed the gatsby-plugin-typescript library for Gatsby.
  • After that I installed the typings for React by running npm install --save @types/react @types/react-dom.
  • Finally, I made the important tsconfig.json file. With compilerOptions I can override certain configurations for TypeScript's compiler. For example, I can compile my TypeScript down to an older version of ECMAScript with target.

{
    "compilerOptions": {
      "module": "commonjs",
      "target": "es5",
      "jsx": "react",
      "lib": ["dom", "es2015", "es2017"],
      "strict": true,
      "noEmit": true,
    },
  }

The Learning Begins: TypeScript offers all the features of JavaScript with the type system layered on top. This is why they call TypeScript a superset of JavaScript. TypeScript helps prevent weird things in JavaScript like below from happening.

• The various basic types that we can assign to our variables and functions are boolean, number, and string. They have a special type called any too.
• I learned that if an object has properties that are optional, we can use the ? operator after the property name so that TypeScript won't scream at us if we don't use it down the line.
• We can also set our own types as well. There are a few ways to do this:
  • With Union Types, we can combine types to tell the compiler that the value can be two or more types. For example, we can denote that an ID can be of both number and string by typing id: number | string.
  • With Type Aliases, we can define a type and use it more than once. This is very useful, especially for objects. Check out the example below:

type Pet = {
    name: string
    species: string
    age: number
    shots: boolean
}

function checkPet(pet: Pet){
    ...
    console.log(pet.age) // will be a number
}

• More:
  • Interfaces are pretty similar, but the main difference is that you can extend them by adding new properties. There are things that interfaces can do that Type Aliases can't such as being always named in error messages.

interface Pet {
    name: string
    species: string
    age: number
    shots: boolean
}
interface Dog extends Pet {
    breed: string
}

function checkPet(dog: Dog){
    ...
    console.log(dog.name) // will be a string
    console.log(dog.breed) // will be a string
}

The Learning Continues: For my project I am using Twin Macro, which is basically a way to implement TailwindCSS into React. I'm using it with Emotion, the well-known React package to implement styled-components (CSS in JS).

• The first file that I worked on was seo.tsx. For each page, the best practice is to accept some props for SEO for each webpage, which almost always includes title. Some other props like description, lang, and author won't be used much, so I knew I had to make a type where I could make those props optional.

interface SEOProps {
    description?: string,
    lang?: string,
    title: string,
    author?: string
}

const SEO = ({description, lang, author, title}: SEOProps) => {
    ...
}

• It can be tricky getting the syntax right at first. I placed my type outside of the parentheses instead of beside the object which caused the compiler to scream at me.
• The next file I worked on was layout.tsx. In this file I simply just said that my child components can be of any type. I'm sure there's a proper way to do this in React or Gatsby. I probably will talk about it when I start doing deeper dives on this.

import React from 'react'

const Layout = ({children}: any) => (
    ...
)

The Learning Still Continues:

• The way I usually set up my React projects is to have my components in folders with an index.js file and a styles.js file (the index.js file will take on the name of the component folder). I will then set up my styled-components in styles.js and import it into index.js. The process was familiar in TypeScript until I needed to include props.
• In styles.tsx, I utilized the FunctionComponent type from React so that I could give a type to a component. Also, when I defined my type, I used an array as the property because I used the spread operator for my props. I'm struggling to describe this in words, so let me show you:

import React, {FC} from 'react'
import tw from 'twin.macro'

interface ComponentProps {
    [key: string]: any
}

const ThisButton: FC<ComponentProps> = props => <button {...props} />

export const Button = tw(ThisButton)`
    bg-blue-700 hover:bg-blue-900
`

Conclusion:

• I'm having a lot of fun using TypeScript and I can see the reason for the hype. But I have a whole lot to learn.
• In some future posts, I'll make some actual deep-dive tutorials about how to make a proper Gatsby website with styled-components, TailwindCSS, and of course, TypeScript.

There's something that I've come to accept about myself recently: I'm not built to be a workaholic. But ironically, that's who I am. I'm accepting something that runs contrary to my current being: a freelancer who's always working on a billion things at once for myself and others. My week is 90% work, including weekends.

"I have to finish this."

"Oh man, I have to put this on pause. I have a deadline coming up."

"I should've finished this ages ago."

"This could be so much better."

My mind runs at a million thoughts per hour, thinking about all the stuff that I have to do and what could go right/wrong if they are finished or not. I press on, trying to do a million things at once but sometimes end up not completing anything. I then burnout, resulting in completing less than what I expected. Then I start to worry, and this worry often ends up in something that is way more daunting.

The What:

• As you may have guessed, I suffer from anxiety. It's the most common mental illness in the United States.
• My brand of anxiety differs from many others, but it usually follows the same theme: feelings of doom and gloom that can have different triggers, but most times it's from constant stress.

• I'm also addicted to something that has kept me up at night, seven days a week: "Hustle porn". Alexis Ohanian, Reddit co-founder, said it best:

  "This is one of the most toxic, dangerous things in tech right now. This idea that unless you are suffering, grinding working every hour of every day, you're not working hard enough. It's such bulls---, such utter bulls---."

• It seems that "hustle porn" is dying in the eyes of the public, especially over the past year. With COVID and the trauma of losing loved ones and losing jobs, priorities have been re-calibrated. Several years ago, every other post was about the 24/7 hustle. Now, you'll get "ratio'd" on Twitter if you even suggest it.

• There's been a movement of people, which thankfully includes men, talking about the importance of protecting their mental health. Even some of the biggest "hustle porn" stars (ha!) are starting to admit this.
  • Seriously men, we need to talk more about our mental health.
  • It really connected with me when Prince Harry spoke about the need to protect his mental health and what he did about it.

The Why: Recent events have made me re-evaluate my priorities. Working 24/7 isn't sustainable on a practical level. It causes burnout for me, and studies have shown time-and-time again that burnout causes loss of productivity. It's illogical to burn myself out in trying to be more productive.

• Deloitte conducted a survey on employee burnout and found there are three major causes: lack of support or recognition from leadership (31%), unrealistic results and expectations (30%), consistently working long hours or on weekends (29%).
  • I checked all three, so congratulations to me 🤦🏾‍♂️.
• Studies have continuously shown the benefits of a proper work-life balance. These include an increase in productivity, lower levels of illness, heightened happiness, and increased motivation.
• Anxiety is terrible and I wouldn't wish it on my biggest enemies. Keeping attacks at bay is paramount.

The How:

• Ever since that cold winter's night, I decided that I will no longer look down on rest. I will not feel guilty about listening to my body's need to rest anymore.
• The Deloitte study provides a blueprint for how I can have a proper work-life balance and prevent burnout. I need to believe in myself more, stop setting unrealistic expectations and deadlines for myself, and stop working through the wee hours of the night and weekends.
• I've decided that I will no longer work 24/7. Yes, that includes personal projects. I've put off the launch of my projects so many times already 😩. But, my mental health comes first.
• I've decided that I must do everything in my power to protect my mental health. That doesn't only include the need to rest, but to do more things that make me happy. That also includes finding new things that I'll probably enjoy.
• Yes, we're still in a pandemic. I also work remotely. But I have to find ways to get out more. Restaurants are now open and I'm sure co-working spaces are open for business too. It's time to utilize them.

Conclusion:

• I've detected a marked increase in my well-being ever since I made the decision to no longer feel guilty about taking time off. I'm a lot happier now that I refuse to feel guilty about slacking off.
• I know myself, and with this knowledge, I've decided to trust that every decision I make will be the right one for me. Once I put myself first, I trust that everything else will fall naturally in line.
• One of the things that have come as a result of this is writing about the stuff I want when I want. It's been so therapeutic, and coincidentally, has opened new doors for me. I like writing coding tutorials, but I enjoyed writing this non-technical lifestyle piece. I'm looking forward to writing more.

Preliminaries:

• Go back to the previous post to see how you should set up your project.
  • This rule will only be used for RegisterRequest, so focus on making sure that's set up properly.
• If you haven't already, download and install Postman.
• Don't forget to run your server! php artisan serve

The Work Begins:

• We'll create our custom rule by running php artisan make:rule StrongPassword.
  • You can find your new rule in app/Http/Rules/StrongPassword.php.
  • In your custom rule you will see a constructor and two methods: passes() and message(). The passes() method will check to see if the $attribute's condition in terms of the $value is met and returns either true or false. The message() method returns whatever string you want to return when passes() is false.
• The best way to ensure that a string follows a certain pattern is to use regular expressions. In PHP, we use the function preg_match() to help with that.

The Work Continues:

• I'm not a god at regex but luckily I found one that works. Here's how we'll pattern match the $attribute's $value to return a boolean:

public function passes($attribute, $value)
    {
        return preg_match("/^(?=.*?[A-Z])(?=.*?[a-z])(?=.*?[0-9])(?=.*?[#?!@()$%^&*=_{}[\]:;\"'|\\<>,.\/~`±§+-]).{8,30}$/", $value);
    }

• So if it doesn't pass (returns false), our defined error message will be returned.

public function message()
    {
        return 'Your :attribute must be at least 8 characters and must include a number, a symbol, a lower and an upper case letter';
    }

• NB: Since password is the attribute that we're making a rule for, it will replace :attribute in our string.

The Work Ends:

• Go into RegisterRequest and import StrongPassword. Now we need to instantiate it so we can use it. We'll replace the value for password in our rules() method and use an array instead.

use App\Rules\StrongPassword;
...

public function rules()
{
    return [
        'name' => 'required|string|max:255',
        'email' => 'required|string|email|max:255|unique:users',
        'password' => ['required', 'string', new StrongPassword],
    ]
}

• Now when we run it we should see something like this:

Conclusion:

• Having custom rules gives you a lot more options. You can add a lot more logic for even more robust rules. In a future post, I'll show you how I used a trait to make datetime-based custom rules.
• In our next post we'll be discussing After Validation Hooks.

Preliminaries:

• Set up your API and make a controller or two for registration and logging in. Because the actual controller methods won't be triggered, you won't need to install Sanctum or worry too much about the code behind authentication.
  • If you're using this tutorial for your project, then carry along with installing what you need.
  • Also, if you're using Blade or Jetstream, you may want to skip any API-specific instructions ahead.
• If you haven't already, download and install Postman.
• Don't forget to run your server! php artisan serve

First Steps: Because we're working with an API, we'll need to create custom validation Exceptions. As it stands now, Laravel will return HTML every time we get a validation error.

• Run php artisan make:request ApiFormRequest. This will create a file that can be found at app/Http/Requests/ApiFormRequest.php.
• In this file, we'll be overriding the failedValidation() method. However, because we want to reuse it for our other Form Requests, we'll make ApiFormRequest an abstract class. We'll remove the bodies of our authorize() and rules() methods and make them abstract so that we don't end up clashing or overriding them.

<?php

namespace App\Http\Requests;

use Illuminate\Contracts\Validation\Validator;
use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Http\Exceptions\HttpResponseException;

abstract class ApiFormRequest extends FormRequest
{
    abstract public function authorize();

    protected function failedValidation(Validator $validator)
    {
        throw new HttpResponseException(response()->json([
            'errors' => $validator->errors()
        ], 422));
    }

    abstract public function rules();
}

The Work Begins:

• Let's start with validation for our Registration controller/method. We'll create a Form Request for it by running php artisan make:request RegisterRequest.
• And if you know your PHP OOP principles and Inheritance, you probably predicted that we'll be extending ApiFormRequest instead of FormRequest to use its methods.

<?php

namespace App\Http\Requests;

use App\Http\Requests\ApiFormRequest;

class RegisterRequest extends ApiFormRequest
{
    //
}

• Within each Form Request, Laravel automatically sets authorize() to return false. Do not forget to set this to true, or you will get "Unauthorized" errors that may trip you up. NB: You can also define custom logic for your authorize() method but that's for another day.

The Work Continues:

• Now we need to set the rules. In the array, we'll place the name of each field to be validated as the key, and for the value, we'll use a variety of rules in a string. The three fields we'll be validating are name, email, and password. NB: Each value can be an array instead of a string. This comes in handy when we're making custom rules.

<?php

namespace App\Http\Requests;

use App\Http\Requests\ApiFormRequest;
use App\Rules\StrongPassword;

class RegisterRequest extends ApiFormRequest
{
    public function authorize()
    {
        return true;
    }

    public function rules()
    {
        return [
            'name' => 'required|string|max:255',
            'email' => 'required|string|email|max:255|unique:users',
            'password' => 'required|string|min:8',
        ];
    }

• In your controller, import RegisterRequest and use it to type-hint the $request parameter passed into your controller's method.

<?php

namespace App\Http\Controllers;

use App\Http\Requests\RegisterRequest;
use Illuminate\Support\Facades\Hash;
use App\Models\User;

class RegisterController extends Controller
{
    public function __invoke(RegisterRequest $request){
        $validated = $request->validated();
        ...
    }

• In the code above, we retrieved the validated data and passed it to the $validated variable. Our validated data is in an array, not an object, so to access the validated email data, for instance, we use validated['email']. NB: Laravel recommends doing it this way but you'll still be able to use the $request object if your validations pass.
• Now follow the previous steps to make another Form Request for your Login controller/method.

The Work Ends:

• Open up Postman and play around in the body of your request. You can omit values or make the password too short. Whatever you do, try to get a negative response from the API. Here's what I did and the response I got:

• You might be asking why your error messages may look different than mine. That's because I made custom error messages for my rules! You can do this too in your Form Request (only if you want to because you really don't).
  • In RegisterRequest, under your rules() method, add another method called messages().
  • The format follows the rules() method where you'll return an associative array. The difference is that the keys are named a bit differently, and your values will be the messages for each rule.

public function messages(){
    return [
        'name.max:255' => 'Your name is too long :/',
        'email.email' => 'Please ensure that your email address is in the correct format',
        'email.max:255' => 'Your email address is too long :/',
        'email.unique:users' => 'This user already exists',
        'password.required' => 'Please enter a valid password'
    ];
}

Conclusion:

• Laravel suggests that separating your validation logic should be done when it is complex. I believe that for clean and maintainable code, it's best to do it as often as possible.
• There's so much more power we can unlock with Laravel Validation and Form Requests. In the next article, we'll make a custom Rule object to help us with modern password validation.

Preliminaries:

• For some strange reason, fetch is not automatically available in our serverMiddleware (don't ask, I dunno). Hence, we'll need to import the node-fetch library into our project like so: const fetch = require('node-fetch').

First Steps:

• Let's rewrite the skeleton of the serverMiddleware we made in the previous article to include an arrow function, just for code readability.

const fetch = require('node-fetch')

const handler = async (req, res) => {
//
}

export default handler

The Work Begins: Our serverMiddleware will help us get the Access Token which will be used to get user data.

• In an async function, I prefer to use try...catch blocks because they make error and response handling easier and cleaner. So let's create one inside our handler.

const handler = async (req,res) => {
    try {
        //
    }
    catch(e){
        console.log(e)
    }
}

• To get the access token, we'll need to make a POST request to Zoom with these three parameters: grant_type, code, and redirect_uri.
  • The value for grant_type, according to the docs, is 'authorization_code'.
  • For code, we'll need to catch the value for the code param that we got from the client-side.
  • The value for redirect_uri is the same base URL that we have in our .env file.
• To get code, we'll use the URL interface that is also made available in Node. The URL interface has a property called searchParams that has all query params in an object, and we can use the get method to retrieve its value. To make use of the URL interface, we'll need to make an absolute URL, since the URL we get from the client is only partial.
  • Afterwards, we can create the URL to which we'll be making a POST request.

try {
    const url = new URL(req.url, `https://${req.headers.host}`)

    const zoomUrl = new URL('https://zoom.us/oauth/token')
    zoomUrl.searchParams.set('grant_type', 'authorization_code')
    zoomUrl.searchParams.set('code', url.searchParams.get('code'))
    zoomUrl.searchParams.set('redirect_uri', process.env.NUXT_ENV_BASE_URL)
}

The Work Continues: Zoom has a strange demand that we use a special code in our header to make our POST request. This code is special because, in pseudocode, it would look something like this: base64(CLIENT_ID:CLIENT_SECRET).

• We turn that into real code by using Node's Buffer class. This class helps in the handling of binary data. We'll create a new buffer with the concatenated string using our Zoom client ID and client secret, and then we'll convert that into base64.

const data = process.env.NUXT_ENV_ZOOM_CLIENT_ID + ':' + process.env.NUXT_ENV_ZOOM_CLIENT_SECRET
const newData = Buffer.from(data, 'utf8')
const b64string = newData.toString('base64')

• Now we can finally make our POST request. I like to define my options object first for fetch. If we await our JSON response, we should get back an object with our access token.

const options = {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'Authorization': 'Basic ' + b64string
    }
}
const response = await fetch(zoomUrl, options)
const json = await response.json()

The Work Ends:

• Sometimes, for a variety of reasons, the access token is not generated, hence we'll need to move forward only if there is an access token. To get our user, we'll make another fetch, but using the GET method this time.
  • Just like with most other token-based auth, we'll use our access token as a bearer token in the header.
• When that is done, we will await the User object, and send the data back to the client.

  if (json.access_token){
    const preUser = await fetch('https://api.zoom.us/v2/users', {
        method: 'GET',
        headers: {
            'Authorization': 'Bearer ' + json.access_token
        }
    })
    const user = await preUser.json()
    res.setHeader('Content-Type', 'application/json')
    res.end(JSON.stringify(user))
  }
  else {
    throw new Error('Something went wrong!')
  }
  

• In our last article, the method that we used to fetch user data was getZoomUser. In the last line of that method, just log user to the console, open your browser and you'll see what you get.
  • You will see an object with properties that look unrelated at first glance. Open the object and you will see the user that you got permission from to use their data (it'll most likely be your account).

Conclusion:

• In just about every frontend framework that you use, persisting the data you get from the API is hard work. In a future article, we'll discuss state management and persisting state with cookies.

Preliminaries:

• Make sure you have a Zoom account and register your app in Zoom's Marketplace. More details on how to do so can be found here.
• Download and install Ngrok. We'll need it because Zoom doesn't allow redirects to localhost.
  • Run Ngrok by using your terminal and running ngrok http 3000 wherever your Ngrok executable file is stored.
• Presuming that you already have Nuxt downloaded and set up, you'll need to set up your environment variables.
  • Create a .env file. Here we will house our Zoom Client ID and Client Secret. You should place your Ngrok URL here too.
  • For this tutorial, we'll name our variables thusly: NUXT_ENV_ZOOM_CLIENT_ID, NUXT_ENV_ZOOM_CLIENT_SECRET, and NUXT_ENV_BASE_URL. NB: We use the prefix NUXT_ENV_to inject it straight into the process environment, so we don't have to do anything extra in nuxt.config.js.
• Insert the Ngrok URL into 'Redirect URL for OAuth' and 'Whitelist URL' fields on the App Credentials page of your Zoom app.
• Scopes are extremely important so don't forget to add them to your app dashboard!
• Run npm run dev!

The Work Begins: Here we're going to make a simple link that when clicked will help kick off the whole process.

• In your pages folder, create index.vue if it's not already there. We will put link as a property so we can manipulate it and bind it to our a tag via v-bind:href. We need the link to be available when our page is mounted, so we'll use Vue's mounted hook.
• We'll also be using the URL interface which should be available to all modern browsers.

<template>
    <a :href="link">Create Zoom link</a>
</template>

<script>
export default {
    data(){
        return {
            link: '',
        }
    }, 
    mounted(){
        this.getZoomLink()
    },
    methods: {
        getZoomLink(){
            let url = new URL('https://zoom.us/oauth/authorize')
            url.searchParams.set('response_type', 'code')
            url.searchParams.set('redirect_uri', process.env.url)
            url.searchParams.set('client_id', process.env.zoomclient)
            this.link = url.href
        }, 
    }    
}
</script>

• When you click the link, a page describing your app and the info that it's requesting will show up (if you're logged in). Once you click on the 'Authorize' button, it will redirect you to the redirect_uri that you set.

The Work Continues: You should now see code in the query string in your browser's URL bar. We'll need to use this string to get our access code.

• To get our code, we'll use this.$route.query. It returns an object, so we'll first check to see if it is empty with Object.keys() to ensure we only run it when this query string is set. We'll pass it on to a property called code so that we can use its value elsewhere.
  • We'll be using the created lifecycle hook instead of mounted for this part. This hook is usually used for fetching data on initialization and fires right before the mounting of our component.

data(){
    return {
        link: '',
        code: ''
    }
},
created(){
    const obj_length = Object.keys(this.$route.query).length
    if (obj_length > 0){
        this.code = this.$route.query.code
    }
},
mounted(){
    this.getZoomLink()
},

• Now we'll create a method that will send this data to our serverMiddleware. It will run immediately after we get the code string.

  created(){
    const obj_length = Object.keys(this.$route.query).length
    if (obj_length > 0){
        this.code = this.$route.query.code
        this.getZoomUser()
    }
  },
  ...
  methods: {
    async getZoomUser(){
        let options = {
            method: 'GET',
            headers: {
                'Content-Type': 'application/json'
            }
        }  
        let response = await fetch(`/api/access-token?code=${this.code}`, options)
        let user = await response.json()
    },
  }
  

The Work Ends: All Zoom API endpoints will need to be accessed from the server-side, hence, we'll need to use Nuxt serverMiddleware. Seriously, don't even try using the client. You'll get a lot of CORS issues. Our serverMiddleware will act as an API that will communicate with Zoom's API.

• The first thing we'll need to do is create an api/ folder in the root, then create a file that will house our serverMiddleware. I've named it zoom-token.js.
• Now we'll register our serverMiddleware in our nuxt.config.js file. We'll set a proxy for our API, and tell Nuxt where exactly the API's handler function is.

serverMiddleware: [
    {path: '/api/access-token', handler: '~/api/zoom-token.js'},
]

• Now we can begin work on our serverMiddleware. If we log our request to the console (in our terminal, not the browser), we'll see all the related properties, methods, and data, including our query string.

export default function(req, res){
    console.log(req)
}

Conclusion:

• In our next post, we'll go deeper into serverMiddleware and show how we can return our data to the client-side.

Preliminaries:

• In your terminal, navigate to your Laravel project and install Lighthouse by typing composer require nuwave/lighthouse.
• Next, run php artisan vendor:publish --tag=lighthouse-schema. This will create the schema in our new graphql folder.
• If you want type-checking and autocompletion in your IDE, run php artisan lighthouse:ide-helper and it will create three other files in your root: _lighthouse_ide_helper.php, programmatic-types.graphql, and schema-directives.graphql.
  • NB: If you're using git, please add these files to your .gitignore file.
• Finally, no GraphQL project is complete without a GUI. Lighthouse recommends that we use the GraphQL Playground library for Laravel: composer require mll-lab/laravel-graphql-playground.
  • We'll be able to access it in our browser with/graphql-playground.
  • Personally, I would've preferred if there was a GraphiQL library for Laravel that was recently updated. GraphiQL is what I use for my Gatsby projects.

First Steps: Before we get to work, we'll need to set up our database and do some seeding. Let's create a tiny and simple e-commerce platform where a seller can only create one item at a time. We'll also make each item have multiple sales.

• Each user will have one Item at a time. We'll also be type-hinting our model so we can have an easier time creating our GraphQL schema.

<?php 
...
class CreateItemTable extends Migration
{
    public function up()
    {
        Schema::create('item', function (Blueprint $table) {
            $table->id();
            $table->string('name')->nullable(false);
            $table->dateTimeTz('expiry_time')->nullable(false);
            $table->string('description', 140)->nullable(false);
            $table->float('price')->nullable(false);
            $table->bigInteger('seller_id')->nullable(false)->unsigned();
            $table->timestamps();
        });
    }
    ...
}

<?php

...
use Illuminate\Database\Eloquent\Relations\HasMany;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class Item extends Model
{
    use HasFactory;

    protected $table = 'item';

    public function sales(): HasMany
    {
        return $this->hasMany('App\Models\Sale');
    }

    public function seller(): BelongsTo
    {
        return $this->belongsTo('App\Models\User', 'seller_id');
    }
}

• Next, we'll create the Sales migration and model with similar type-hinting.

<?php
...
class CreateSalesTable extends Migration
{
    public function up()
    {
        Schema::create('sales', function (Blueprint $table) {
            $table->id();
            $table->integer('quantity')->nullable(false);
            $table->float('amount')->nullable(false);
            $table->bigInteger('item_id')->nullable(false)->unsigned();
            $table->bigInteger('seller_id')->nullable(false)->unsigned();
            $table->timestamps();
        });
    }
    ...
}

<?php
...
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class Sale extends Model
{
    use HasFactory;

    public function item(): BelongsTo
    {
        return $this->belongsTo('App\Models\Item');
    }

    public function seller(): BelongsTo 
    {
        return $this->belongsTo('App\Models\User', 'seller_id');
    }
}

• Finally, we can define our User model.

<?php

...
use Illuminate\Database\Eloquent\Relations\HasOne;
use Illuminate\Database\Eloquent\Relations\HasMany;

class User extends Authenticatable
{
    ...
    public function item(): HasOne
    {
        return $this->hasOne('App\Models\Item', 'seller_id');
    }

    public function sales(): HasMany
    {
        return $this->hasMany('App\Models\Sale', 'seller_id');
    }
}

• Now we'll need to seed our tables (if you don't want to enter data manually). I don't have time to go through Seeders and Factories here so please check out the docs.
• We can now test our GraphQL configuration. Open GraphQL Playground and let's retrieve the first user in our database:

  {
    user(id: 1){
        name
        email
    }
  }
  

The Work Begins: Here we will be defining our schema. It's important that you have some grasp of the types used in a GraphQL schema. We'll only brush up on this, so for a deeper understanding, I'd advise you to check out GraphQL's docs on the subject.

• Open the graphql/schema.graphql file and you will see the definitions for two custom scalar types, Date and DateTime. GraphQL's default scalar types are Int, Float, String, Boolean, and ID.
• Near the top, we define the root Query type. In it, we'll add the query for finding the user, which both Item and Sale models are attached to.
  • NB: Our Laravel models are 'Object Types' in GraphQL. Again, please remember to visit the GraphQL docs for a deeper understanding.

type Query {
    user(id: ID @eq): User @find 
}

The Work Continues:

• Now we'll define our object types by giving them fields and defining each field with types. Let's start with the User object type.

type User {
    id: ID!
    name: String!
    email: String!
    item: Item @hasOne
    sales: [Sale] @hasMany
    created_at: DateTime!
    updated_at: DateTime!
}

• A few notes about the code above:
  • An exclamation point simply means that the field can't be null. An error will be returned if the query returns a null value.
  • When a type is between square brackets, that means we can expect a List.
• Now let's define the Item object type:

type Item {
    id: ID!
    name: String!
    expiry_time: DateTime!
    description: String!
    price: Float!
    sales: [Sale] @hasMany
    seller: User! @belongsTo
    created_at: DateTime!
    updated_at: DateTime!
}

• See how easy it is? Now you should be able to do the Sale object type on your own.

The Work Ends:

• Go to GraphQL Playground and run a query. Here's one that should work wonderfully if the database is seeded correctly and relationships are properly defined.

  {
    user(id: 1){
        name
        email
        item {
            name
            price
            description
            expiry_time
            sales {
                quantity
                amount
            }
        }
    }
  }
  

• For any troubleshooting, read the error message on the right of the screen. Most times it will tell you exactly what you need.

Conclusion:

• There are so many more things you can do with GraphQL queries. One of the most important things we can do is authentication, which we'll discuss in another post. We will also discuss mutations in the future.
• If you want to get ahead on your own with Lighthouse, please refer to the Lighthouse docs.
• I prefer Lighthouse because of its ease-of-use and the ability to edit the schema directly. However, if you want to make a GraphQL API the PHP/Laravel way, then I recommend you check out Rebing's library.

Background:

• Clubhouse was founded on March 15, 2020, by Paul Davison and Rohan Seth.
• Their latest funding round, a Series B, was led by Andreessen Horowitz and raised $100 million. They are now valued at $1 billion.
• They now have 2 million WAUs, according to Statista and have surpassed 8 million downloads.
• Spotify is a global behemoth in audio. They went public in 2018 after raising a total of $2.6 billion in funding. They are now currently valued at $72 billion.

The What:

• Funnily enough, Daniel Ek was asked just recently about Clubhouse. On Monday, January 22, 2021, Spotify held a 90-minute event where they showed off new audio products and podcast ad technology.
• About Clubhouse, Ek told The Verge that he's not surprised at Clubhouse's success as it follows the same format that has worked very well for podcasts.
  • He went on to say that it's an interesting space that his team is "keeping an eye on."
  • But he pointed out a weakness of Clubhouse that Spotify is strong in, and that is people want media-on-demand, which they can't get on Clubhouse.

The Why:

• Spotify loves social.
  • Spotify has dabbled in social over the years, enabling users to discover, follow, and interact with other users, artists, and podcasts. Clubhouse's discovery features are also great; they help users know who to follow and what rooms may interest them.
  • They have many features that are social in nature and that drive their success, such as seeing what friends are listening to, user profiles, and a new party mode.
  • Spotify has shown that it's not afraid to try social features that seem a bit "out there". Remember the news about them testing Stories?
• Clubhouse may want to move past (some of its) ephemerality in the future.
  • Currently, after a talk is finished on Clubhouse, it is gone forever. 'Live' can be monetized, but just like other platforms with live features such as Instagram, YouTube, and Twitch, users are able to save these live shows for further viewing.
  • When Facebook and Twitter follow through on their plans to release their Clubhouse competitors, they will most likely integrate them into their Stories features. Stories (in Twitter's case, Fleets) are ephemeral, yes, but they last for 24 hours. That brings more eyes and ears for ad dollars.
• There is increased competition.
  • Twitter's and Facebook's moves to compete with Clubhouse could eventually enable them to disrupt the podcasting space.
  • Can you imagine a new kind of podcast that lasts only 24 hours? Spotify can't afford huge competitors other than Apple in the podcasting space.
  • Also, Clubhouse surely can't afford to compete against giants like Facebook and Twitter right now. Sure, Clubhouse has money to burn, but they're not going to win against companies with the infrastructure, talent, money, influence, and established networks like Facebook and Twitter have.
  • Oh, and if they acquire Clubhouse, they could stop them from being a likely and formidable competitor.
• Their marriage would be beautiful.
  • Spotify's podcasts don't have the magic of a live discussion. I think podcasts and live audio should be merged, and it would be a beautiful thing.

The How:

• Clubhouse is "cheap" now, and it's my hunch that their valuation will be quadrupled by this summer.
• Spotify spent nearly $600 million in 2020 on acquisitions and other investments, but they still have over $1.3 billion in the bank. A cash plus stock deal doesn't look farfetched.
  • AND AMAZINGLY, there was news released today that said Spotify took on $1.3 billion in debt for acquisitions. Hmm 🤔
• I made some imperfectly fleshed-out tweets a while back on how I think an acquisition could go. One of them went like this:

  Prediction: Spotify will buy Clubhouse amid competition from Twitter and make it run independently. It will scale with the help of Spotify's infrastructure.

  — The Lloydinator (@lloydmiller) January 29, 2021

  • The alternate thing that could happen is Spotify immediately brings them in-house and renames the app Spotify Clubhouse. They may let it operate as a separate app but Clubhouse's features will get deeply entwined with Spotify's. Spotify would have more powerful ways to get ads into more ears.

Conclusion:

• Why aren't more people begging for this to happen? To be fair, I'm just a layman, so it could be a very bad idea, or impossible. However, I am also a very logical person, and I highly doubt it would be a terrible or impossible move.
• I do see arguments against a quick move, though. One could say that Spotify would be throwing its weight around too quickly and lose sight of its podcasting goals.
• But wouldn't it be prudent to buy Clubhouse while they're cheap, and give them a year or more of leeway to grow with Spotify's resources? They could do this while Spotify consolidates its position in podcasting and only fully integrates Clubhouse when it's ready. Wasn't that Facebook's playbook with Instagram?

How it happened: In constructing my Laravel API, I needed to test out the ability to add a post by a certain time. So I whipped out Postman, put in my date, and hit Enter. I swore it was error-proof; my API was working well earlier and the minor changes I made shouldn't have broken it. But alas, I got an error saying the date was in the wrong format. :/

What really happened: Biggest duh moment of my life. If you haven't seen the error yet, look carefully. Ignore the error message because it will throw you off. If you haven't seen it yet, I'll give you a clue: 2021 isn't a leap year. I spent about 90 minutes trying to find what was causing this issue when the answer was literally right there.

What I learned: Don't just look at the obvious. The real solution to our problems is often hidden in plain sight.

Preliminaries:

• Download the Twilio SDK by opening your terminal and typing composer require twilio/sdk in your project.
• Ensure that you're all set up with Twilio and that you have your Twilio number, Account SID and Auth Token ready.
• Place your SID, token, and number as separate values in your .env file. For this tutorial, I'll just name these variables TWILIO_SID, TWILIO_TOKEN, TWILIO_NUMBER.

First Steps:

• In your project's config folder, go to services.php. This is where we will define our new third-party Twilio service.

<?php

return [
    ...
    'twilio' => [
        'sid' => env('TWILIO_SID'),
        'token' => env('TWILIO_TOKEN'),
        'phone' => env('TWILIO_NUMBER')
    ]
]

The Work Begins:

• In your app folder, create a Services folder. It is there that you'll create a file called Twilio.php.
• Our service will only need to authenticate the client and send text messages, so we'll only be using Twilio\Rest\Client. We'll also need to set the namespace for our file so that we can access it elsewhere.

<?php

namespace App\Services;

use Twilio\Rest\Client;

• The first thing that we'll do is define some properties so that we can plug in the values that are in our .env file.
  • After that, we'll use the constructor to pass the values to our properties.

<?php

namespace App\Services;

use Twilio\Rest\Client;

class Twilio {
    protected $sid;
    protected $token;
    protected $phone;

    function __construct(){
        $this->sid = config('services.twilio.sid');
        $this->token = config('services.twilio.token');
        $this->phone = config('services.twilio.phone');
    }
}

The Work Continues:

• Twilio demands that every request be authenticated with the use of our SID and Auth Token. So instead of calling a separate method to authenticate for every request that we make, we'll just house our client authentication code in our constructor. We'll instantiate the client, and pass it to a property so that we can use it later.

...
protected $client;

function __construct(){
    $this->sid = config('services.twilio.sid');
    $this->token = config('services.twilio.token');
    $this->phone = config('services.twilio.phone');

    $this->client = new Client($this->sid, $this->token);
}

• Finally, we'll just define one method to send our text messages.

...
function __construct(){
    $this->sid = config('services.twilio.sid');
    $this->token = config('services.twilio.token');
    $this->phone = config('services.twilio.phone');

    $this->client = new Client($this->sid, $this->token);
}

public function send($recipient_phone, $message){
    $sms = $this->client->messages->create($recipient_phone, [
        'from' => $this->phone,
        'body' => $message
    ]);

    return $sms;
}

The End:

• Now, when you want to use this service, like in an Event Listener, all you'll need to do is import the service, instantiate the service, and use the method!

<?php

namespace App\Listeners;

use App\Events\SomeEvent;
use App\Services\Twilio;

class DoThisAfterSomeEvent
{
    ...
    public function handle(SomeEvent $event){
        ...
        $twilio = new Twilio();
        $twilio->send($recipient_phone, $message);
    }
}

First Steps:

• In your terminal, go to where your project's API is located, and type php artisan make:middleware LogRoute. This will create a file in app/Http/Middleware.
• If you haven't already, download Postman. It will help you to test your API without having to go through your frontend.

The Meat:

• In your LogRoute.php, import the Log Facade by typing use Illuminate\Support\Facades\Log at the top of your file.
• Next, in our handle() function, we'll need to first ensure that our request can pass unimpeded between handlers.

  public function handle(Request $request, Closure $next){
    $response = $next($request)
    ...
  }
  

• Next, we'll need to tell our Middleware to stop running if our app environment isn't local. We'll do that with an if statement: if (app()->environment('local')).

• Now we can finish up our middleware by making an array of our request and response and logging that data. Our response is what's most important, as it will have a stack trace to help us debug.

  public function handle(Request $request, Closure $next){
    $response = $next($request);
  
    if (app()->environment('local')){
        $data = [
            'request' => $request->all(),
            'response' => $response->getContent()
        ];
        Log::info(json_encode($data));
    }
  
    return $response;
  }
  

Finishing Up:

• To use our middleware, we first have to register it. Go to Kernel.php in your app/Http folder and scroll all the way down to $routeMiddleware. When you're there, add this line: 'log.route' => \App\Http\Middleware\LogRoute::class,.
• Now go to your API routes and place ->middleware('log.route') at the end of the route that you want to test.

The End:

• Test your API by making a request with Postman.
• Go to storage/logs/laravel.log to see what's happening.

One More Thing:

• You can add more methods in your middleware to test requests, such as $request->getMethod() which will tell you the type of request method that hit the API (POST, GET, etc.) and $request->getUri() which will tell you the source of the request.

Preliminaries:

• Register your app in Zoom's Marketplace. More details on how to do so can be found here.
• Open your terminal, go to the folder where your code is stored, and install your Next.js app by running: npm init next-app my-next-app && cd my-next-app. Of course, you can rename 'my-next-app' into anything you choose.
• Download and install Ngrok. We'll need it because Zoom doesn't allow redirects to localhost. You can choose to edit your Host file instead, but this is much easier.

Further setup:

• Create a .env.development or .env.local file in your project's root.
• Using your terminal, go to the folder where you installed Ngrok, and run ngrok http 3000. Change '3000' to whatever port your Next app will be listening on.
• Copy the secure Forwarding address to your project's .env file.
  • NB: If you're using a .env.local file, ensure that you have 'NEXT_PUBLIC' appended to every variable for this guide.

• Finally, insert the Forwarding address into 'Redirect URL for OAuth' and 'Whitelist URL' fields on the App Credentials page of your Zoom app.

  • 
  • Scopes are just as important as the 'Redirect URL for OAuth' and 'Whitelist URL' fields so don't forget to add them to your app dashboard.
• You may also want to place your Client ID and Client Secret in your .env file as a more secure way of using them in your app.

The Job Begins:

• We need to direct the user to the address https://zoom.us/oauth/authorize with a few params.
• On your index.js page (or the page you plan to start the Zoom auth process from), we'll use the React Hook useEffect to mount this address when the page loads. We'll also be using the hook useState.

import React, {useEffect, useState} from 'react'

const IndexPage = () => {
    const [url, setUrl] = useState(null)

    const makeLink = () => {
        const thisUrl = new URL('https://zoom.us/oauth/authorize')
        thisUrl.searchParams.set('response_type', 'code')
        thisUrl.searchParams.set('redirect_uri', process.env.NEXT_PUBLIC_NGROK_URL)
        thisUrl.searchParams.set('client_id', process.env.NEXT_PUBLIC_ZOOM_CLIENT)
        setUrl(thisUrl.href)
    }

    useEffect(() => {
        makeLink()
    }, [])

    return (
        <a href={url}>Start Zoom OAuth Process</a>
    )
}

export default IndexPage

• If you look at the code snippet you'll see we've used JavaScript's powerful URL Browser API. We'll be using it throughout this guide to help us manipulate URLs.
• Now when we click the link, we should see something like this:
• 
  • NB: Please remember to put the same redirect URL into both 'Redirect URL for OAuth' and 'Whitelist URL' fields. And don't forget your Scopes! That's how the customer will know what your app will do with their permission.

The Job Continues:

• When it's redirected back to your site, you will see a code param followed by a random string in the URL. We'll capture that using a data fetching feature called 'getServerSideProps'. This feature is used for pre-rendering with Next SSR. If you're familiar with writing Node, you won't have much of an issue here.
• First, we will generate a full URL from our request:

...
export const getServerSideProps = async ({req, res}) => {
    const thisUrl = new URL(req.url, `http://${req.headers.host}`)
    ...
}
export default IndexPage

• Next, Zoom demands that in order for us to get the access token to the user's account, we'll be making a POST request with a special code in our header to Zoom's servers. We'll generate our code like this: base64(CLIENT_ID:CLIENTSECRET). That's pseudocode of course, so let's turn that into real code. We'll be using Node's Buffer class, which helps in the handling of binary data.

if (thisUrl.searchParams.get('code')){
        const urlParam = thisUrl.searchParams.get('code')

        const data = process.env.NEXT_PUBLIC_ZOOM_CLIENT_ID + ':' + 
            process.env.NEXT_PUBLIC_ZOOM_CLIENT_SECRET
        const newData = Buffer.from(data, 'utf8')
        const b64string = newData.toString('base64')
...

• We're almost there. In order to get our access token, we should generate the URL for our POST request using the same URL API that is also a part of Node.

const zoomUrl = new URL('https://zoom.us/oauth/token')
zoomUrl.searchParams.set('grant_type', 'authorization_code')
zoomUrl.searchParams.set('code', urlParam)
zoomUrl.searchParams.set('redirect_uri', process.env.NEXT_PUBLIC_NGROK_URL)

• Above you can see that the string we captured from the code param is passed into the new URL in its code param.
• Now, let's make the POST request to the URL we've made above. I like using try-catch blocks, as I can handle errors a lot better and the code is more organized using async-await.

try {
    const options = {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': 'Basic ' + b64string
        }
    }
    const response = await fetch(zoomUrl.href, options)  
    const json = await response.json()
    ...
}
catch(e){
    console.log(e)
}

• If we click our link again (which by the way is totally fine), it will skip the permission page and you will see a new code generated. We'll pass that code into the 'code' param in our new URL, and use the base-64 string we generated in our header. We wait for a response using the Fetch API (not naturally a part of Node but included with Next) and convert the response to JSON.
• If all goes well, we can then retrieve the user using the access token retrieved from the JSON object that we received from the last request. So the complete try-catch block should look like this:

try {
    const options = {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': 'Basic ' + b64string
        }
    }
    const response = await fetch(zoomUrl.href, options)  
    const json = await response.json()

    if (json.access_token){
        const newOptions = {
            method: 'GET,
            headers: {
                'Authorization': 'Bearer ' + json.access_token
            }
        }
        const preUser = await fetch('https://api.zoom.us/v2/users', newOptions)
        const zoomUser = await preUser.json()

        return {
            props: {zoomUser}
        }
    }
}
catch(e){
    console.log(e)
}

• Since this is basically Node, you should look for errors in your console and not in the browser. However, if you've been following along perfectly, you shouldn't have any issues. Now we need to get this data to the client-side.

The Job Ends:

• If you look at the snippet above, you'll realize that we're returning our Zoom user object in props. So just like with any React app, we can pass our data into the client like so:

const IndexPage = ({zoomUser}) => {
    console.log(zoomUser)
    ...
}

• Now what happens next is all up to you. It is advised that you try to persist your data so that it doesn't disappear if the user refreshes the page or navigates to another page. Access tokens last for an hour, so keep that in mind.

Conclusion:

• If you want to do more with Zoom OAuth, such as refreshing the token, you can learn more in the Zoom docs.
• If you're wondering how you can persist your data, one good and secure way to do so is through the use of cookies. In another blog post I will discuss how I persist Zoom user data. Ciao for now.