DEV Community: Health Place

Contextual filtering with ChatGPT

Matt Inamdar — Thu, 30 Mar 2023 21:57:13 +0000

When data is ingested into Health Place, it goes through a series of computation and transformation steps, forming an "ingestion pipeline".

One of the essential steps in the pipeline is tagging the listing with concepts from our purpose-built knowledge graph.

You can think of concepts as taxonomies, a vocabulary to give semantic meaning to your data.

For quite a while now, we've already implemented AI, specifically Natural Language Processing (NLP), into our pipeline by using a Bag-of-Words model (BoW) to extract concepts from the text provided. And for the most part, this has worked exceptionally well!

It falls short, though.

When the context surrounding the extracted concept gives it a different meaning, the BoW model doesn't care. Only if the concept is present in the text – in some cases, this can become an issue.

Take the following example:

Supporting You is a seven-week programme which equips young people with the tools to help themselves to strengthen their resilience and emotional well-being.

The programme is suitable for young people who meet the following criteria:

Aged 11-17

Beginning to exhibit behaviours, or suggest themselves that they are starting to be affected by low mood, stress or anxiety such that it is beginning to interfere with the enjoyment of life and normal activities

Have no current intervention or support in place from any other agency for emotional wellbeing or mental health issues

They do not meet the criteria for a CAMHS referral

Are able to commit to attending a 7 week Supporting You programme in their local area

Let's focus on the boldened piece of text:

They do not meet the criteria for a CAMHS referral

CAHMS is an acronym for Child and Adolescent Mental Health Services.

In this example, you can see that CAHMS is mentioned in an exclusionary context. This text mentions CAHMS but isn't relevant to CAHMS.

Our previous process couldn't consider this context and would therefore tag this listing with "CAHMS", resulting in a precision problem.

Precision and recall are like buckets in a well; by raising one, you lower the other.

Precision measures what % of results are accurate, whereas recall measures what % of relevant results were actually returned.

So we could tweak our NLP step by improving it's precision, but at the expense of lowering its recall. But only if there was another way.

Enter ChatGPT...

ChatGPT is perfect for understanding context and the use case was immediately obvious to me.

The technique I had in mind was to pass GPT the source text along with the concepts from our knowledge graph that we've extracted. We can then ask GPT to tell us which extracted taxonomies are relevant to the text and which aren't.

This allows us to engineer our previous NLP layer towards higher recall to extract as many relevant concepts as possible and, in the next layer, have GPT filter out the concepts that aren't relevant, providing us with the precision needed.

This process seemingly allows us to have our cake and eat it! Something seldom one gets to do.

Get in touch

If you have any questions, comment below, or find me on LinkedIn: linkedin.com/in/matthew-inamdar

And if you'd like to work for a tech-for-good company like Health Place, then message me for an informal chat at matt@healthplace.io – we're currently looking for a Frontend Engineer!

Image sources:

Dynamically optimising and caching images via a Node.js microservice

Matt Inamdar — Sat, 09 Apr 2022 12:43:02 +0000

At Health Place we are pushing towards a media heavy platform filled with images and videos to make it more engaging for our users, enabling them to get a better idea of the support listings they may be interested in.

Along with this comes the big challenge of keeping things fast and efficient.

In this article we'll go through: where we started along with the problems we were facing, the ideal solution we had in mind, and finally the solution we ended up with.

TL;DR: We built a microservice in Node.js to serve our images with dynamic optimisation provided via query string params. We then placed this behind a CDN to cache indefinitely.

The problem

Each listing on Health Place has support for a variety of images, not limited to:

Listing logo
Providing organisation logo
Listing gallery (there can be many images in here!)
Location image (a listing can have many locations)
Soon listings will also have a wide banner image

Let's start by discussing how these images are provided to us, and where they're stored.

All images are uploaded via our admin web app which is where organisations can login and manage their listings on the site.

This all goes through our primary PHP-based API which in turn, uploads the image to Amazon S3, our cloud storage service of choice.

Initially we had endpoints provided by that same API to serve the images. The API would need to download the image from S3 each time and return it. This quickly became an issue as PHP is a blocking language, meaning no other requests could be handled whilst the image was being downloaded and returned.

Another issue was present. The uploaded images were almost always not optimised. They were often large in resolution and file size, making them not friendly at all for consumption via the frontend web app.

To counter this, we implemented image optimisation at time of upload by pushing a job to optimise the image once uploaded. This worked, but we started introducing ever growing complexity and the time came to consider moving this logic out of PHP entirely...

The ideal solution

The ideal plan was to have a completely separate microservice that is responsible for the following:

Uploading images (behind auth)
Streaming images
API to confirm image exists
Dynamically optimising images via query string parameters
CDN to cache images and optimised versions

The PHP API would then return a field in the JSON response, telling the client to go to the Images Microservice to get the image, e.g.:

{
  "name": "Listing name",
  "logo_url": "https://images.healthplace.io/image-id"
}

The client could then append some query string parameters to dynamically request a version optimised for its specific use case:

<img src="https://images.healthplace.io/image-id?format=jpg&quality=80&height=250" />

Finally, this should be placed behind a CDN resulting in only the first request having to wait for the microservice to download the image from S3 and optimise it. All subsequent requests for that image with those exact optimisations would be returned immediately from the CDN.

This greatly simplifies our workflow as now an image would only need to be uploaded once in its raw and unoptimised state. All optimisations are then achieved dynamically at time of use.

The implementation

First, a quick note:

In our first iteration, we've managed to push the streaming, optimisation, and caching logic to a newly created Images Microservice. However, the uploading of new images and persistence to S3 is still achieved through our main API. Our next iteration will push this logic into the Images Microservice.

So what did we do?

First, we created a standard express app using TypeScript (nothing special here). Then we pulled in this extremely useful package called express-sharp that wraps sharp, a Node.js image manipulation library, in an express middleware.

We then setup the middleware to listen to any route invocation that began with /_/ which would use the S3 adapter to pull the image from S3. This would allow for /_/my-image-id to be passed to the adapter with a key of my-image-id, correlating to the file path in the S3 bucket.

There's also a TypeScript interface provided to write your own adapters which we utilised.

Query string parameter based optimisations are provided out of the box, so no need to do anything fancy here!

We then provided two domains for the microservice:

Origin https://images-api.healthplace.io
CDN https://cdn.images-api.healthplace.io

The CDN is setup to make downstream requests to the origin domain on cache misses, and the CDN domain is also used in our API responses. As part of the CDN config, we set the query string optimisation parameters as part of the cache key to ensure we hit the cache as much as possible.

We now have a fully working Images Microservice!

We also added further endpoints and adapters to account for other useful situations, such as returning SVG's and files from the filesystem.

Building upon this, we'd like to provide support for directly uploading images to this microservice, allowing our main API to simply accept the corresponding ID's only. The Images Microservice could then provide an endpoint for the main API to validate the image ID as existing. There's also scope to dynamically add watermarks and all sorts of other manipulations!

But that's all I have for now!

Get in touch

If you have any questions, comment below, and I'll get back to you.

And if you think you'd like to work somewhere like Health Place, then message me for a chat at matt@healthplace.io.

Photo by Warren Umoh on Unsplash

Consuming RabbitMQ Queues in Laravel

Matt Inamdar — Wed, 26 Jan 2022 14:14:18 +0000

RabbitMQ is an open-source message broker with support for queues, exchanges and topics.

It's the "most widely deployed" open-source message broker at that (according to their website).

We decided to use RabbitMQ at Health Place in order to enable asynchronous event-based systems to complete tasks, only when the previous task had completed.

Our exact scenario was to get our ingestion pipeline working, which is composed of multiple services, in different languages.

RabbitMQ allows us to have a single service in the ingestion pipeline complete its task, push a message to RabbitMQ, and then have the next downstream service start its task (which may then do something similar, until the data is finally ingested).

Why not just use Laravel's queue system?

This is a good question, and ideally we'd have preferred it if this was possible.

The problem is to do with how messages are stored in the Laravel queue system.

Laravel calls messages "jobs", which are represented as Plain Old PHP Objects (POPO's). These jobs are then serialised into a string and pushed onto the queue driver configured.

This implementation is fine when the publisher and consumer are the same app. This is usually the case when your Laravel app needs to asynchronously perform a task (such as sending an email).

The problem appears when you introduce several apps, as is the case with our ingestion pipeline.

Our primary API, sitting in front of our database, is our Laravel app. Further upstream in our ingestion pipeline, we have a series of Node.js microservices responsible for several things, such as normalising and validating the data.

These microservices and Laravel need a shared way to communicate with one another via asynchronous events. The way to achieve that is by using a message broker (RabbitMQ) and publishing/consuming messages in JSON.

This works great as JSON is widely used as a standard interface format and has support in almost all modern languages.

Why not used webhooks instead of a queue?

Another good question, and the answer is to do with "simplicity".

If we were to go down the webhook approach, it would require the consumer of messages to now host a HTTP endpoint, which must always be up, in order to receive messages. This is troublesome for services that aren't web-facing.

This also means that the publisher needs to invoke this HTTP endpoint as well as introducing retry logic if the endpoint is ever down. And what should happen is all retries have failed?

A queue on the other hand, allows the message to be published and then any listener can consume this message if they're interested. An added benefit is that multiple services can consume the same message, even though the publisher only published it once.

This allows for great decoupling and flexibility.

Implementation

Now for the fun part! Let's take a look at how we implemented this at Health Place.

Install the RabbitMQ package

Start by installing this package which is a Laravel wrapper for the php-amqplib/php-amqplib package.

composer install bschmitt/laravel-amqp

Once installed, make sure to register it as a service provider:

// config/app.php
return [
    //...

    'providers' => [
        //...

        Bschmitt\Amqp\AmqpServiceProvider::class,
    ],
];

And finally to publish the config file:

php artisan vendor:publish --provider Bschmitt\\Amqp\\AmqpServiceProvider

Be sure to check the newly created config/amqp.php file and add your credentials.

Creating the consumer Artisan command

In order to start consuming messages from RabbitMQ, we need to create an infinitely running Artisan command that will continuously check for messages on the exchange.

Here's a working example of such a command:

<?php

declare(strict_types=1);

namespace App\Console\Commands\HealthPlace\RabbitMQ;

use App\Exceptions\InvalidAMQPMessageException;
use App\Jobs\IngestDataJob;
use Bschmitt\Amqp\Amqp;
use Bschmitt\Amqp\Consumer;
use Exception;
use Illuminate\Console\Command;
use Illuminate\Foundation\Bus\DispatchesJobs;
use PhpAmqpLib\Message\AMQPMessage;
use Psr\Log\LoggerInterface;

class ConsumeCommand extends Command
{
    use DispatchesJobs;

    protected $signature = 'healthplace:rabbitmq:consume';

    protected $description = 'Runs a AMQP consumer that defers work to the Laravel queue worker';

    public function handle(Amqp $consumer, LoggerInterface $logger): bool
    {
        $logger->info('Listening for messages...');

        $consumer->consume(
            '',
            function (AMQPMessage $message, Consumer $resolver) use ($logger): void {
                $logger->info('Consuming message...');

                try {
                    $payload = json_decode($message->getBody(), true, 512, JSON_THROW_ON_ERROR);
                    $this->validateMessage($payload);
                    $logger->info('Message received', $payload);
                    $this->dispatch(new IngestDataJob($payload['filepath']));
                    $logger->info('Message handled.');
                    $resolver->acknowledge($message);
                } catch (InvalidAMQPMessageException $exception) {
                    $logger->error('Message failed validation.');
                    $resolver->reject($message);
                } catch (Exception $exception) {
                    $logger->error('Message is not valid JSON.');
                    $resolver->reject($message);
                }
            },
            [
                'routing' => ['ingest.pending'],
            ]
        );

        $logger->info('Consumer exited.');

        return true;
    }

    private function validateMessage(array $payload): void
    {
        if (!is_string($payload['filepath'] ?? null)) {
            throw new InvalidAMQPMessageException('The [filepath] property must be a string.');
        }
    }
}

There's a few things going on here so let's break this down:

The payload (the message content) is JSON decoded, with an exception being thrown if the JSON is malformed.
The JSON itself is then validated to ensure the that it contains the fields in the format that we expect (very similar to request validation).
A standard Laravel job is then pushed for the relevant task to be performed asynchronously.
The message is acknowledged to RabbitMQ so it is aware that the consumer has successfully consumed the message.
If the JSON fails to decode or if validation fails, the message is rejected to RabbitMQ.

You may be wondering what the purpose is for publishing a Laravel job from this command, and although it is completely possible to work the message directly in this command, it introduces some problems...

In our case, the ingestion job takes a long time, potentially hours depending on the size of the dataset. If this consume command was to process that, it would mean that we couldn't consume any further messages from RabbitMQ until the ingestion had finished.

What we opted to do instead, was to push a Laravel job from this and have a queue worker actually do the ingestion. We can even scale up our queue workers if we have a bunch of jobs waiting to be worked, all whilst our RabbitMQ consumer is actively listening for further messages.

And that wraps it up!

Get in touch

If you have any questions, comment below, and I'll get back to you.

And if you think you'd like to work somewhere like Health Place, then message me for a chat at matt@healthplace.io.

Continuous Delivery at Health Place

Matt Inamdar — Wed, 14 Jul 2021 14:39:26 +0000

We hear the terms "CI" and "CD" thrown around a lot these days, and I've worked on many projects that have implemented a CI/CD pipeline, some large with low user counts, some small with large user counts, as well as everything in-between.

I've seen what works well and what doesn't.

With this experience, we've implemented a CI/CD pipeline at Health Place that provides us with all the benefits of Continuous Delivery, wrapped up in a simple yet elegant implementation.

The goal

Before we get into it, let's quickly address the reason behind all of this:

What is the purpose of the CI/CD pipeline?

As the literature states, the crux of the CI and CD pipeline is to automate as much of the process as possible in order to get committed code up to production.

The CI pipeline

The goals of the CI pipeline are to make sure that any code committed is fit for a release candidate (code that is fit for deployment to any environment).

So, what do we do?

Trigger a CI build from any commit pushed to origin.
Build our dev Docker images.
Run automated tests.
Build our prod Docker images.
Push a release to the CD pipeline.

Yes, "Flaky Feature Tests" are present... but there is a concrete plan to eradicate them. This may even make its way into another article.

Tech stack

We use GitHub Actions, GitHub Workflows, and Github Packages. It ties in nicely with GitHub being our VCS of choice, and most importantly: it's simple.

Simplicity and explicitness are key values we hold close.

The 5-minute build

One of the tenets to follow is to ensure builds in the CI pipeline are sub 10 minutes. At Health Place, we've managed to keep our builds at around 5 minutes (that's just enough for me to brew my morning coffee... and maybe a few seconds to take that first sip).

This allows for extremely rapid feedback to be informed when a build has failed, allowing our engineers to fix the problem and commit without ever having to twiddle their thumbs.

Humans shouldn't do machine things

Everyone at Health Place is a talented human. So why would we ever want to waste their time doing mundane tasks they don't want to do?

Well, we don't.

We automate them, leaving our talented people to do the things they find interesting, the things that humans are better than machines at doing.

That's why our unit tests, code style tests, feature tests, integration tests, and any other possible tests we decide to implement in the future are all automated.

That means reviews left on PR's have no mention of code style or test coverage but focus purely on the human aspect. Things such as: if there may have been a more elegant way of implementing this or some design pattern that could have been leveraged, etc.

The CD pipeline

The first thing to get out of the way (which I know you're all wondering): we mean "Continuous Delivery" when we talk about CD. Continuous Deployment is somewhere we'd like to get to, but for now, Continuous Delivery is where we're at.

The goal of the CD pipeline is to deploy a release pushed by the CI pipeline to the specified environment.

This is a single click-of-a-button affair that any of our engineers are trusted to do (Octopus Deploy is our tool of choice).

There's not much else to say about this, as it is supposed to be simple by nature.

There's scope to include further tests in the CD pipeline, such as deployment tests, smoke tests, canary deployments, etc.

We will be implementing these supplementary automations down the line.

The entire workflow

Let's take a step back. We've deep-dived into both our CI and CD pipeline, but now let's look at the entire workflow from commit to deployment:

An engineer creates short-lived feature branch based off of trunk/master/main for a ticket.
The engineer makes a commit and pushes it to origin.
The CI pipeline runs build.
- If there's a failure, then the engineer is notified within 5 minutes.
the CI pipeline creates and publishes a release to the CD pipeline.
The release appears in the CD pipeline.
The engineer can now deploy this release with a single-click to any environment.

The summary

I hope this gave you a good insight into how a CI/CD pipeline can be effectively implemented into a project.

If you want to do some further reading into the topics covered in this article, I can highly recommend these books:

Get in touch

If you have any questions, comment below, and I'll get back to you.

And if you think you'd like to work somewhere like Health Place, then message me for a chat at matt@healthplace.io.

Photo by Quinten de Graaf on Unsplash

Tech debt explained

Matt Inamdar — Wed, 16 Jun 2021 22:43:09 +0000

After a colleague I'm working with questioned me on "why we need to address tech debt", I found myself responding with a technical justification that helped nobody.

After great reflection on that interaction, this article was born. I hope this helps you understand what tech debt is, how it's formed, and the implications of leaving it unaddressed.

The analogy

Let's start with a familiar concept: the mighty combustion engine car.

The year is 2021 and you've just purchased your new petrol car. This isn't just any car though, this car is special and you plan for it to last you at least 20 years.

But wait! It's now the year 2030 and all of a sudden the combustion engine has been banned shock and horror.

So you now decide to upgrade the car by making it electric (this is actually a thing).

Here's the problem, you've only got 2 months before the combustion engine ban comes into effect, but the entire EV conversion is going to take at least 4 months.

So what do you do? You cut corners...

You remove the combustion engine and replace it with an electric motor and a battery. However, the important thing to note is that the rest of the mechanisms supporting the combustion engine remain; things such as the fuel tank and the exhaust pipe.

You're now driving this hybrid Frankenstein around and loving life. But disaster strikes! Global warming has caused temperatures to rise and now you're sweltering in your iron tomb of a car with no hopes of happiness.

So you take it to the garage to get a sweet new AC system installed.

The problem is, the mechanic has quoted you 3 times the usual estimate, simply because it's going to be a pain in the arse to navigate around this beast. She also notices that your fuel tank which you left from your half-completed job has started leaking onto the battery.

By this time it's too late, the cost to get this sorted is going to require you to remortgage your house...

You should have completed the job sooner.

The summary

Hopefully you enjoyed this epic novel and it made the story of tech debt more relatable.

For the sake of clarity:

The car is your product
The combustion engine/mechanism is your existing functionality that needs to be decommissioned
The electric motor/battery is your new functionality
The mechanic is your developers
Global warming is real

Get in touch

If you have any questions, comment below, and I'll get back to you.

And if you think you'd like to work somewhere like Health Place, then message me for a chat at matt@healthplace.io.

Photo by Eddie Jones on Unsplash