Forem: Jan Halama

Turn CV to structured data with GPT-3 and Node.js

Jan Halama — Tue, 24 Jan 2023 13:49:50 +0000

Large language models like GPT-3 are useful to simplify routine tasks. For example, we can take unstructured data, like a job applicant's resume in PDF, and turn them into structured data and fill them into our Applicant Tracking System (ATS) like Greenhouse or Workable.

In this article, I will show you a Node.js application which does that. But while GPT-3 simplifies routine data entry jobs, as developers we still need to connect all the respective APIs to download the applicant's CV, get text from the PDF, and put data to the ATS. Luckily, Superface gets us rid of this routine API wiring. We provide a unified interface across many API providers. Switching from, for example, Workable to Breezy HR, is a one line change.

Let's check what steps this application does:

Loads a CV of a candidate who applied for a given job from an Applicant Tracking System (ATS), like Workable or Greenhouse.
Converts the CV to text and parses the text into machine-readable data.
Updates the candidate in the ATS with the data obtained from the CV.

You can find the complete application in the CV Analyzer repository. It uses the following packages:

@superfaceai/one-sdk - Superface OneSDK is used to integrate with ATS, OpenAI and Cloudmersive SaaS providers.
node-fetch - NodeFetch is used to fetch the CV document.
dotenv - dotenv is used to load environment variables.
inquirer - Inquirer.js is used to build interactive user interface.

We also rely on these use cases from Superface Catalog:

In this demo we use Workable as ATS, Cloudmersive to convert a candidate's CV to plain text, and OpenAI provider for conversion of CV to structured data. But you are not limited to just this three providers. For ATS use cases you can use also Breezy HR, Greenhouse and many others.

Setting up the application

1. Clone the app repository and enter its directory.

git clone git@github.com:superfaceai/cv-analyzer.git
cd cv-analyzer

2. Install dependencies.

npm install

3. Create accounts (if you do not have them already) for the providers:

Workable offers 15 days free trial. A work e-mail address is required to create the account.
Cloudmersive has a free tier limited to 800 requests per month.
OpenAI offers a free trial with $18 in free credit usable during the first 3 months.

4. Copy the example .env file.

cp .env.example .env

5. Set credentials and integration parameters for the providers in the .env file.

Get Workable Access Token and Subdomain.
Create Cloudmersive Free Tier Key.
Create OpenAI Secret API Key.

6. Create a job position and add new candidate in Workable ATS.

7. Start the app.

npm start

Once the application starts, it will show you a list of candidates. When you pick one, it will update candidate's entry with data parsed from their CV.

How the application works

The main flow of the application is in the src/index.js file, which calls use cases defined in src/use_cases.js file.

Selecting the candidate and getting its CV

First we list open job positions and candidates for the selected position. This is handled with the List Jobs use case; once the user picks a job position, we use List Candidates use case with the respective ID of the job position:

exports.listCandidates = async (sdk, providerOptions, jobId) => {
  const listCandidatesProfile = await sdk.getProfile(
    'recruitment/list-candidates@1.0.0'
  );
  const listCandidatesResult = await listCandidatesProfile
    .getUseCase('ListCandidates')
    .perform(
      {
        jobId,
      },
      providerOptions
    );
  return listCandidatesResult.unwrap().candidates;
};

We take the ID of the selected candidate and use the Get CV use case to obtain the URL of a document with the candidate's resume (typically that's a PDF, but the ATS may accept other formats as well):

exports.getCVUrl = async (sdk, providerOptions, candidateId) => {
  const getCVProfile = await sdk.getProfile('recruitment/get-cv@1.0.0');
  const getCVResult = await getCVProfile.getUseCase('GetCV').perform(
    {
      candidateId,
    },
    providerOptions
  );
  return getCVResult.unwrap().cv.documentUrl;
};

Converting CV to text

Now we know where the candidate's CV can be downloaded, but we need to extract the text from it somehow. We use Convert Document to Text use case for that – we fetch the document and upload it to the conversion provider (Cloudmersive in this example) and get a plain text in return.

exports.convertCVToText = async (sdk, providerOptions, cvDocumentUrl) => {
  const docToTextProfile = await sdk.getProfile(
    'file-conversion/doc-to-text@1.0.0'
  );

  const fetchDocumentResponse = await fetch(cvDocumentUrl);

  if (!fetchDocumentResponse.body) {
    console.error('Failed to fetch CV document.');
    return;
  }

  const result = await docToTextProfile
    .getUseCase('ConvertDocumentToText')
    .perform(
      {
        fileName: 'cv.pdf',
        content: BinaryData.fromStream(fetchDocumentResponse.body),
      },
      providerOptions
    );

  return result.unwrap().text;
};

Extracting structured data

Now it's time for some AI magic! We use OpenAI's GPT-3 model through the Text Completion use case. We provide the model with a prompt explaining we need particular data returned as JSON:

exports.analyzeCV = async (sdk, providerOptions, cvText) => {
  try {
    const generateTextProfile = await sdk.getProfile('ai/generate-text@1.0.0');

    const promptCommand = `Parse following job applicant resume and return json object with properties 
    { 
      "firstName", "lastName", "address", "phone", 
      "education":
      [{"school", "fieldOfStudy", "studiedFrom_ISO8601":"YYYY-MM-DD", "studiedTill_ISO8601":"YYYY-MM-DD"}],
    "workHistory":
      [{"company", "position", "summary", "workedFrom_ISO8601:"YYYY-MM-DD"", "workedTill_ISO8601":"YYYY-MM-DD"}]
    }. `;

    const result = await generateTextProfile.getUseCase('CompleteText').perform(
      {
        prompt: promptCommand + cvText,
        creativity: 0.8,
        approxMaxWords: 1000,
        model: 'large',
      },
      providerOptions
    );

    analyzeCVOutcome = result.unwrap();
  } catch (error) {
    console.error('Failed to analyze CV.', error);
  }
  // ...
};

If the analysis goes well and the model “completes” our prompt, we turn the returned completion to JSON:

const parsedCV = JSON.parse(analyzeCVOutcome.completions[0]);
const mappedCV = {
  ...parsedCV,
  education: parsedCV.education?.map(school => {
    return {
      school: school.school,
      degree: school.degree,
      fieldOfStudy: school.fieldOfStudy,
      startedAt: school.studiedFrom_ISO8601,
      endedAt: school.studiedTill_ISO8601,
    };
  }),
  workHistory: parsedCV.workHistory?.map(work => {
    // ...
  }),
};

return mappedCV;

Update the candidate data

Now that we have a JSON with structured data extracted from the CV, we can send the data back to the ATS to update the candidate's data using the Update Candidate use case:

exports.updateCandidate = async (sdk, providerOptions, candidate) => {
  const profile = await sdk.getProfile('recruitment/update-candidate@1.0.0');

  const result = await profile
    .getUseCase('UpdateCandidate')
    .perform(candidate, providerOptions);

  result.unwrap();

  return true;
};

Using another ATS?

If you take a look at the code, there aren't any mentions of Workable, Cloudmersive or OpenAI. That's because the use cases are designed in provider-neutral way. In case of ATS, we use a unified terminology, so if you need to use another ATS, you don't need to rewrite the whole application. Instead, you can change atsProviderOptions in src/index.js file:

// Options for Workable
const atsProviderOptions = {
  provider: 'workable',
  parameters: {
    SUBDOMAIN: process.env.WORKABLE_SUBDOMAIN,
  },
  security: {
    bearer_token: {
      token: process.env.WORKABLE_TOKEN,
    },
  },
};

And if you'd like to use, for example, Breezy HR, set atsProviderOptions like this:

// Options for Breezy HR
const atsProviderOptions = {
  provider: 'breezy-hr',
  parameters: {
    COMPANY_ID: process.env.BREEZY_HR_COMPANY_ID,
    ACCESS_TOKEN: process.env.BREEZY_HR_ACCESS_TOKEN,
  },
};

Next steps

In this demo application, we've used 6 different API use cases from 3 different API providers, without ever looking at the API docs. That's the advantage of Superface.

Do you need to integrate Applicant Tracking Systems like Workable, Lever, or SAP SuccessFactors? Check out our Applicant Tracking Systems integrations. And don't miss other integrations in the Superface catalog.

Automate npm publishing with GitHub Actions, proper changelog, and release notes

Jan Halama — Wed, 22 Jun 2022 08:55:43 +0000

If you maintain at least one Node.js package, you probably know how painful the releases can be. Maybe running npm publish works for you just fine, but there are so many little details one can forget: running tests with clean dependencies, keeping the changelog up to date, creating release notes… Maintaining high quality of releases is difficult, especially in a team. Usually, it makes sense to automate the release process.

At Superface, we use GitHub Actions to automate the release workflow for npm packages. When we designed the process, we had the following requirements:

Start the release manually with an appropriate version bump (patch, minor, major, prepatch, preminor, premajor, or prerelease)
Support for manually maintained changelog file (using Keep a Changelog conventions)
Automatically tag the package version in the repository and publish release notes with GitHub Release
Publish the package to npm registry with appropriate distribution tags (latest for stable versions, next or beta for pre-release versions with)
Automatically publish prerelease versions on certain branches for beta testing

Since new releases cause churn for package users, we want to be certain our release notes are usable. That's why we prefer a handcrafted changelog following the Keep a Changelog convention over automatic release notes generated from commit messages.

Unlike Conventional Commits and semantic-release, we let the developer choose the release type (major, minor, patch) and the time at which the package is released.

The following steps will guide you through the setup of automated npm package releasing:

Generate a new npm access token
Save npm access token as a GitHub secret
Add GitHub Workflow to your repository
Release the npm package
- Update the changelog
- Trigger new release

Generate a new npm access token

First we need an access token for npm registry in order to publish package with GitHub Actions. Create a new access token at npmjs.com for Automation and copy it for the next step.

Save npm access token as a GitHub secret

We will store the generated token for GitHub Actions as a repository secret. In your GitHub repository settings, visit "Secrets" → "Actions", click "New repository secret", and add the npm access token created in the previous step. We will name the secret NPMJS_ACCESS_TOKEN.

Add GitHub workflow to your repository

In your project, create a new GitHub workflow file called release_package.yml, in the .github/workflows directory. Paste the following code. Optionally, you can change user.email and user.name under "Git configuration" step and uncomment the "Run tests" step along with the "Install dependencies" step.

Finally, commit the file and push the changes to your main branch.

name: Release package
on:
  workflow_dispatch:
    inputs:
      release-type:
        description: 'Release type (one of): patch, minor, major, prepatch, preminor, premajor, prerelease'
        required: true
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      # Checkout project repository
      - name: Checkout
        uses: actions/checkout@v2.3.4

      # Setup Node.js environment
      - name: Setup Node.js
        uses: actions/setup-node@v2
        with:
          registry-url: https://registry.npmjs.org/
          node-version: '14'

      # Install dependencies (required by Run tests step)
      #- name: Install dependencies
      #  run: yarn install

      # Tests
      #- name: Run tests
      #  run: yarn test

      # Configure Git
      - name: Git configuration
        run: |
          git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git config --global user.name "GitHub Actions"

      # Bump package version
      # Use tag latest
      - name: Bump release version
        if: startsWith(github.event.inputs.release-type, 'pre') != true
        run: |
          echo "NEW_VERSION=$(npm --no-git-tag-version version $RELEASE_TYPE)" >> $GITHUB_ENV
          echo "RELEASE_TAG=latest" >> $GITHUB_ENV
        env:
          RELEASE_TYPE: ${{ github.event.inputs.release-type }}

      # Bump package pre-release version
      # Use tag beta for pre-release versions
      - name: Bump pre-release version
        if: startsWith(github.event.inputs.release-type, 'pre')
        run: |
          echo "NEW_VERSION=$(npm --no-git-tag-version --preid=beta version $RELEASE_TYPE
          echo "RELEASE_TAG=beta" >> $GITHUB_ENV
        env:
          RELEASE_TYPE: ${{ github.event.inputs.release-type }}

      # Update changelog unreleased section with new version
      - name: Update changelog
        uses: superfaceai/release-changelog-action@v1
        with:
          path-to-changelog: CHANGELOG.md
          version: ${{ env.NEW_VERSION }}
          operation: release

      # Commit changes
      - name: Commit CHANGELOG.md and package.json changes and create tag
        run: |
          git add "package.json"
          git add "CHANGELOG.md"
          git commit -m "chore: release ${{ env.NEW_VERSION }}"
          git tag ${{ env.NEW_VERSION }}

      # Publish version to public repository
      - name: Publish
        run: yarn publish --verbose --access public --tag ${{ env.RELEASE_TAG }}
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPMJS_ACCESS_TOKEN }}

      # Push repository changes
      - name: Push changes to repository
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          git push origin && git push --tags

      # Read version changelog
      - id: get-changelog
        name: Get version changelog
        uses: superfaceai/release-changelog-action@v1
        with:
          path-to-changelog: CHANGELOG.md
          version: ${{ env.NEW_VERSION }}
          operation: read

      # Update GitHub release with changelog
      - name: Update GitHub release documentation
        uses: softprops/action-gh-release@v1
        with:
          tag_name: ${{ env.NEW_VERSION }}
          body: ${{ steps.get-changelog.outputs.changelog }}
          prerelease: ${{ startsWith(github.event.inputs.release-type, 'pre') }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Release the npm package

Update the changelog

Before you proceed to trigger a new release, add notable changes to the changelog file. Our workflow requires that you stick with the Keep a Changelog convention.

You can start with this empty CHANGELOG.md file:

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added

- Changelog

As you commit changes to your project, write them down into the [Unreleased] section. Once you trigger a new release, unreleased changes are automatically moved under the new version heading.

Trigger new release

You can find the “Run workflow” button in your GitHub repository under “Actions” → “Release package”.

Our worfklow_dispatch event takes a single parameter named release type (major, minor, patch, …). The parameter is passed to the npm version command in order to bump version of the package.

Once you press the “Run workflow” button, all the magic will happen, and your npm package will be released.

Conclusion

Our workflow automates the boring parts, while keeping us in control regarding when and how to release new packages' versions. Support for the Keep a Changelog convention and GitHub Releases help us communicate changes to developers.

You can see the workflow in action in most of our package repositories, for example OneSDK for Node.js and Superface CLI.

We are curious about how you manage your releases.
Is your process fully automated, or do you just run npm publish locally? Do you maintain a changelog manually or generate it from commit messages? Share your approach in the comments! 👇

Lessons learned integrating AppSignal APM with NestJS

Jan Halama — Fri, 20 May 2022 13:05:53 +0000

At Superface, we use NestJS framework for backend, and AppSignal APM for monitoring and error tracking. While AppSignal provides a Node.js integration, getting it up and running with NestJS proved to be somewhat tricky.

In this blog post, I will share how we managed to get AppSignal to work with NestJS.

Code snippets used in this blog post are part of our example project.

AppSignal initialization and configuration

AppSignal uses auto-instrumentation which attaches hooks into Node.js tools and frameworks (Express, Koa, PostgreSQL, Redis, …) and observes for certain functions to be called. Once the functions are called, the instrumentation automatically collects trace spans on behalf of your application.

AppSignal has the following requirements (taken from AppSignal docs) to make auto-instrumentation work:

To auto-instrument modules, the Appsignal module must be both required and initialized before any other package.

The standard way to instantiate objects in NestJS is using the Dependency Injection (DI) Container.

To fulfill the requirement, we cannot use NestJS DI Container to instantiate AppSignal. AppSignal has to be instantiated as a global variable, which also means that we cannot take advantage of NestJS ConfigModule.

Example of AppSignal instantiation and configuration using environment variables:

//source file: src/appsignal.ts

const name = process.env.APPSIGNAL_NAME;
const pushApiKey = process.env.APPSIGNAL_PUSH_API_KEY;
const active =
  process.env.APPSIGNAL_ACTIVE === '1' ||
  process.env.APPSIGNAL_ACTIVE === 'true';

export const appsignal = new Appsignal({
  active,
  name,
  pushApiKey,
});

source code

You also need to register the AppSignal middleware when initializing Express in NestJS application bootstrap code:

//source file: src/main.ts

async function bootstrap() {
  const app = await NestFactory.create<NestExpressApplication>(AppModule);

  app.use(appsignalExpressMiddleware(appsignal));

  await app.listen(3000);
}
bootstrap();

source code

That's it, once you set APPSIGNAL_PUSH_API_KEY environment variable to valid AppSignal key and configure APPSIGNAL_NAME, APPSIGNAL_ACTIVE environment variables, AppSignal will start collecting metrics from all HTTP requests handled by your application.

Error tracking

Nest comes with a built-in exceptions layer, which is responsible for processing all unhandled exceptions across an application. See Nest Exception filters docs for details.

To track errors handled by Nest exception filters, we have created AppsignalExceptionFilter which implements Nest ExceptionFilter interface.

//source file: src/exception_filters/appsignal_exception.filter.ts

@Catch()
export class AppsignalExceptionFilter<T extends Error>
  implements ExceptionFilter
{
  catch(error: T, _host: ArgumentsHost) {
    let status: number;
    const tracer = appsignal.tracer();

    if (!tracer) {
      return;
    }

    if (error instanceof HttpException) {
      status = error.getStatus();
    }

    if (error && (!status || (status && status >= 500))) {
      tracer.setError(error);
    }
  }
}

source code

The AppsignalExceptionFilter tracks HttpException exceptions with status code 5xx and any other exception types.

You can use AppsignalExceptionFilter by extending it in your custom exception filter implementation and register your exception filter in Nest app.

Example of extending AppsignalExceptionFilter:

//source file: src/exception_filters/all_exception.filter.ts

@Catch()
export class AllExceptionFilter extends AppsignalExceptionFilter<Error> {
  catch(error: Error, host: ArgumentsHost) {
    super.catch(error, host);

    const ctx = host.switchToHttp();
    const req = ctx.getRequest<Request>();
    const res = ctx.getResponse<Response>();

    const status = 500;

    const problem = {
      status,
      title: 'Internal server error',
      instance: req.path,
    };

    res.status(status).contentType('application/problem+json').json(problem);
  }
}

source code

Example of global filter registration:

//source file: src/main.ts

async function bootstrap() {
  const app = await NestFactory.create<NestExpressApplication>(AppModule);

  app.use(appsignalExpressMiddleware(appsignal));
  app.useGlobalFilters(new AllExceptionFilter());

  await app.listen(3000);
}
bootstrap();

source code

Monitoring `@nestjs/bull` processes

In addition to NestJS we also use Bull for background jobs processing. NestJS provides @nestjs/bull package as a wrapper of for Bull.

AppSignal doesn't trace Bull jobs automatically. Fortunately, we can use Appsignal custom instrumentation to handle tracing ourselves.

To trace Bull jobs, we have created a Bull process decorator ProcessMonitor:

//source file: src/bull/process_monitor.decorator.ts

export function ProcessMonitor(): MethodDecorator {
  return function (
    target,
    propertyKey: string,
    descriptor: PropertyDescriptor
  ) {
    const method = descriptor.value;

    descriptor.value = async function (...args: any) {
      const tracer = appsignal.tracer();

      const span = tracer.createSpan({
        namespace: 'worker',
      });
      span.setName(`JOB ${this.constructor.name}.${propertyKey}`);
      span.setCategory('job.handler');

      const job = args[0];

      if (job) {
        span.setSampleData('custom_data', { jobId: job.id });
      }

      let result;
      await tracer.withSpan(span, async span => {
        try {
          result = await method.bind(this).apply(target, args);
        } catch (error) {
          span.setError(error);
          throw error;
        } finally {
          span.close();
        }
      });

      return result;
    };
  };
}

source code

The ProcessMonitor method decorator creates new span in worker namespace, collects job ID, sets span with the error in case an exception occurs.

Once you add ProcessMonitor decorator into your code base, start using it by decorating your Bull queue processor method:

export const MAILING_QUEUE = 'mails';
export const SEND_EMAIL = 'send_email';

@Processor(MAILING_QUEUE)
export class MailingProcessor {

  @Process(SEND_EMAIL)
  @ProcessMonitor()
  async sendEmail(job: Job) {
    ...
  }
}

Graceful AppSignal stopping

By default, @appsignal/nodejs starts minutely probes, which keep track of Node.js V8 heap statistics. This feature gives you insights about Node.js internals.

Unfortunately, with minutely probes enabled, you have to explicitly stop the probes by calling the stop method. Otherwise your application process won't stop gracefully.

Nest comes with the onApplicationShutdown lifecycle event, which is the right place to call AppSignal stop method. See example of AppsignalShutdownService implementation below:

//source file: src/appsignal_shutdown.service.ts

@Injectable()
export class AppsignalShutdownService implements OnApplicationShutdown {
  onApplicationShutdown(_signal: string) {
    appsignal.stop();
  }
}

source code

Do not forget to add AppsignalShutdownService in your Nest application module.

//source file: src/app.module.ts

@Module({
  providers: [AppsignalShutdownService],
})
export class AppModule {}

source code

Reliable IP Geolocation with Superface

Jan Halama — Mon, 21 Mar 2022 08:43:54 +0000

This blog post will help you understand what is IP Geolocation, and how can Superface help with the reliability of selected IP Geolocation providers.

What is IP Geolocation?

IP Geolocation is a way to obtain the approximate location, time zone, or country of a computer, or mobile device connected to the internet. IP Geolocation uses IPv4 or IPv6 addresses to get the geolocation data.

IP Geolocation accuracy is limited and gives you very raw information about the location of the device. For example, ipgeolocation.io provider is 99% accurate at the country level and around 75% accurate at the city level according to their FAQ.

Anyway, the advantage of IP Geolocation is that you do not need the user’s consent to get the location compared to methods like HTML5 Geolocation API.

There are various use-cases where you can take advantage of IP Geolocation:

Fraud prevention by alerting users of suspicious activity around login or purchases.
Offer customers customized products, for example, online lessons for distant customers and offline lessons for those living in your place.
Display relevant business opening hours to your customers.
Redirect users to the localized page in a language they understand.

The pitfalls of integrating third party providers

When you decide to use IP Geolocation in your project, you can choose whatever IP Geolocation provider you find on the market and integrate with it. But this integration has its drawbacks:

Your project will gain a dependency on a specific provider API. This dependency might not be easy to change in the future.
The provider becomes a single point of failure of your project. When the provider’s service is not working your service functionality will be limited or not working at all.

This is where Superface strengths can be utilized. Superface OneSDK helps with securing resiliency of your Node.js service and losing the dependency on concrete Geolocation API provider.

IP Geolocation providers compared

Currently you can use these providers with Superface (if you miss your favorite one, let us know):

ipgeolocation

free plan with 1K free requests per day
pricing details

ipbase

free plan with 150 requests per month
pricing details

ipdata

free plan with 1.5K requests per day
free plan is restricted to non-commercial use
pricing details

ipstack

free plan with 100 requests per month
ssl encryption and timezone not available in free plan
pricing details

FreeGeoIp

FreeGeoIp has changed its name to ipbase
FreeGeoIp is still available in Superface catalog for backward compatibility

Integrate IP Geolocation provider using Superface OneSDK

Follow these steps to integrate with ipgeolocation provider in your Node.js application using the Superface OneSDK:

In the root folder of your project install address/ip-geolocation profile.
```
npx @superfaceai/cli install address/ip-geolocation
```

Configure ipgeolocation provider.

npx @superfaceai/cli configure ipgeolocation -p address/ip-geolocation

Install Superface OneSDK package.
```
npm install @superfaceai/one-sdk
```

Use the following code in your Node.js application:

const { SuperfaceClient } = require('@superfaceai/one-sdk');

const sdk = new SuperfaceClient();

async function getIPGeolocation(ipAddress) {
  // Load the installed profile
  const profile = await sdk.getProfile('address/ip-geolocation');

  // Use the profile
  const result = await profile.getUseCase('IpGeolocation').perform({
    ipAddress,
  });

  return result.unwrap();
}

Get a free API key by registering on ipgeolocation.io web. Then set the key as an environment variable IPGEOLOCATION_API_KEY:
```
export IPGEOLOCATION_API_KEY=<your-key-from-ipgeolocation>
```

You can find the instructions for configuring other providers in the Superface registry.

Once you install at least two IP Geolocation providers and provide valid access keys you can enable automatic failover between providers.

Use it

Call getIPGeolocation function with IP address argument in your code and you will receive geolocation data in the response. Example result data:

{
  "ipAddress": "8.8.8.8",
  "addressCountryCode": "US",
  "addressCountry": "United States",
  "timeZone": "America/Chicago",
  "latitude": 37.751,
  "longitude": -97.822
}

Forem: Jan Halama

Turn CV to structured data with GPT-3 and Node.js

Setting up the application

How the application works

Selecting the candidate and getting its CV

Converting CV to text

Extracting structured data

Update the candidate data

Using another ATS?

Next steps

Automate npm publishing with GitHub Actions, proper changelog, and release notes

Generate a new npm access token

Save npm access token as a GitHub secret

Add GitHub workflow to your repository

Release the npm package

Update the changelog

Trigger new release

Conclusion

Lessons learned integrating AppSignal APM with NestJS

AppSignal initialization and configuration

Error tracking

Monitoring @nestjs/bull processes

Graceful AppSignal stopping

Reliable IP Geolocation with Superface

What is IP Geolocation?

The pitfalls of integrating third party providers

IP Geolocation providers compared

ipgeolocation

ipbase

ipdata

ipstack

FreeGeoIp

Integrate IP Geolocation provider using Superface OneSDK

Use it

Relevant Superface guides

Monitoring `@nestjs/bull` processes