DEV Community: Delaney S.

The Ultimate Fantasy Premier League Hack: AI-Generated Transfers Using Amazon Bedrock and RAG Agents

Delaney S. — Sun, 06 Apr 2025 17:06:30 +0000

Last weekend, while attending an AWS West Africa Meetup on "AI-Powered Innovation", I heard about Amazon Bedrock for the first time in a way that piqued my interest. Amazon Bedrock is a "fully managed service that offers a choice of high-performing foundation models (FMs) from leading AI companies". In simpler terms, it allows you build generative AI applications, with easy access to FMs like ChatGPT and Claude via an API.

I immediately knew I had to try it out, and I decided to build a Retrieval Augmented Generation (RAG) agent to recommend Fantasy Premier League (FPL) transfers. FPL is a game of strategy, data, and smart decision-making. Deciding which players to transfer in and out of their team each week is basically the biggest challenge for FPL managers.

Here's the repo, where I plan to keep evolving the agent, and a live demo.

A RAG agent is simply an AI agent with retrieval capability, allowing it to have access to current and accurate data. In this example, I'll build an agent with access to the latest FPL rules and selection guidelines. For now, the recommendation options would be given to it manually in the prompt.

You will:

Set up a rules knowledge base for your agent
Store player data and query it for recommendations
Get your agent to recommend the best possible transfers

Setting Up

After setting up your project (in this example, I am using TypeScript & Express.js), you can go ahead and set up the necessary AWS infrastructure. These are:

Amazon Bedrock: for accessing FMs and building agents
S3: for storing knowledge base resources. There are other options, such as Confluence pages and crawled web pages.
DynamoDB (specific to this option): for easy storage and retrieval of player data

DynamoDB

Create a DynamoDB table FPLPlayers with a primary key of playerId. Then, add a global secondary index (GSI) with a partition key of position and a sort key of form. This would allow you to easily query players in top form.

Amazon Bedrock

Request access to an Amazon Bedrock LLM. For this, I chose Claude 3 Sonnet, but you will have access to almost 50 others.

Once the model is available, it's time to set up your knowledge base. Create an S3 bucket and upload your documents there. For me, this was a PDF containing the rules for FPL transfers and team selections. When that is done, from the AWS Bedrock console, create a new Knowledge Base and select the path to the S3 bucket in the settings.
Next, select the embeddings model and the vector store. I used Titan Text Embeddings v2 and Amazon OpenSearch Serverless Vector Store, respectively, as they are great options.

Getting Data

We can set up some methods for our FPL data. First, we need to add some types.

export interface Main {
    elements: Player[];
}

export interface Player {
    id: number;
    web_name: string;
    element_type: number;
    team: number;
    now_cost: number;
    total_points: number;
    selected_by_percent: string;
    form: string;
    status: string;
    expected_goals_conceded: string;
    minutes: number;
    team_code: number;
    chance_of_playing_next_round: number;
}

export interface FPLTeam {
    picks: {
        element: number,
        element_type: number;
        name?: string;
    }[];
    transfers: {
        bank: number;
        limit: number;
    };
}

export interface TransferSuggestion {
    out: string;
    in: string;
    cost: number;
}

Then, we store players on DynamoDB. I added the next fixture difficulty using data from the FPL API. I also added a job to call this endpoint daily, making sure the data is up-to-date:

And retrieve them for recommendation options:

As the project evolves, we can store more statistics to enable the agent to make better decisions. But for now, we'll rely on the player's form, price, and the difficulty of the next fixture.

Let's set up our agent to make decisions using the Knowledge Base. On the AWS console, create a new agent. Select your Foundational Model,
and enter precise instructions for your agent to follow.

Then, create an Action Group. After you create the agent, you can assign a Knowledge Base and prepare the agent. After that, you can create an Alias for your agent. Note down your Agent ID and the Alias ID.

Now, we can call our agent. First, I get the user's team data (players, free transfers left, and budget) and top recommendation (players with a form equal to or greater than a set value). With those, I can create a prompt, which is then sent to my agent.

import {
    BedrockAgentRuntimeClient,
    InvokeAgentCommand,
} from "@aws-sdk/client-bedrock-agent-runtime";
import config from './config';
import {getRecommendationData} from "./dynamo";

const client = new BedrockAgentRuntimeClient({
    region: config.awsRegion,
    credentials: {
        accessKeyId: config.awsAccessKey,
        secretAccessKey: config.awsSecretKey,
    }
});

const agentId = config.awsAgentId;
const agentAliasId = config.awsAgentAliasId;

export async function invokeBedrock(modelId: string, prompt: string) {
    const sessionId = Math.random().toString(36).substring(2);
    const command = new InvokeAgentCommand({
        agentId,
        agentAliasId,
        sessionId,
        inputText: prompt,
        streamingConfigurations: {
            streamFinalResponse: true,
        },
    });

    let recommendations = "";
    const response = await client.send(command);

    if (response.completion === undefined) {
        throw new Error("Completion is undefined");
    }

    for await (const chunkEvent of response.completion!) {
        const chunk = chunkEvent.chunk!;
        const decodedResponse = new TextDecoder("utf-8").decode(chunk.bytes);
        recommendations += decodedResponse;
    }

    return recommendations;
}

/**
 * API function to get FPL advice.
 */
export async function getFPLAdvice(teamId: number, cookie: string): Promise<string> {
    const {userPlayers, recommendations, freeTransfers, budget} = await getRecommendationData(teamId, cookie);

    const prompt = `
  The user’s current team is:\n
  ${userPlayers.map((p) => `- ${p.name} (Position: ${p.position}, Team: ${p.team}) (Form: ${p.form}, Price: £${p.price}, Next Fixture Difficulty: ${p.nextFixtureDifficulty})`).join(`\n`)}.\n

 The user has only ${freeTransfers} free transfers left, and a budget of ${budget}.

 Based on the current gameweek, the best transfer options are:\n
  ${recommendations.map((p) => `- ${p.name} (Position: ${p.position}, Team: ${p.team}) (Form: ${p.form}, Price: £${p.price}, Next Fixture Difficulty: ${p.nextFixtureDifficulty})`).join(`\n`)}.

 Return nothing else but the recommendations in a readable format, clearly showing the player going out and the player coming in for each suggested transfer. For example:

 Out: [Player Name from Current Team]
 In: [Player Name from Best Transfer Options]
 Cost: [Cost to make transfer, should be negative if out > in]
  `;

    return await invokeBedrock(
        "anthropic.claude-3-sonnet-20240229-v1:0",
        prompt
    );
}

And that's it! We can connect this function to an endpoint; calling it should give us some recommendations.

But there's always room for improvement. We can add more to our Knowledge Base or even build more agents to handle other tasks, allowing multi-agent orchestration.

As you can see, the ability to build agents without almost no code and the value they can deliver makes Amazon Bedrock a powerful tool for utilising AI modes.

I hope you found this helpful and that you start building powerful RAG agents to supercharge your ideas. Happy coding!

HMAC Authentication in Laravel

Delaney S. — Sat, 05 Aug 2023 18:53:49 +0000

While working on a set of API webhooks recently, I needed to provide some security scheme that allowed the client to verify that the webhook request was being sent by the correct server, which I was working on. After a little online research, I came across the HMAC scheme for API requests. After a little explanation, I will give an example of implementing this for API endpoints in Laravel.

Hash-based Message Authentication Code (HMAC) is a code obtained using a cryptographic hash function, data and a secret. It’s used to verify the authenticity of the source and content of a request. Both the client and server share a pre-known secret key for generating HMACs.

In simpler terms, there is a secret key that is shared by and known to only the server and client. A hash function uses this key to generate a code whenever a request is made. This code is then added to the request and sent. When the receiving app gets the request, it runs the same process used to create the code, using the details from the request it just received and the secret key it has stored. If the sender is really who they’re meant to be, both the code in the request and the code that has just been generated should match, and the receiver can continue processing the request. Pretty clean, right?

It’s a simple yet effective authentication method, as the integrity checks do not allow for man-in-the-middle attacks unless they possess the secret key. However, a bad guy could resend the same request over and over, and that could cause damage to data or reveal some sensitive information. These are called Replay Attacks, and there are a number of ways to deal with those, but I won’t be talking about any as I plan to keep this as simple as possible.

Now for a quick explanation of our hash function. The values we would be using are:

URL: The full URL in lowercase, including any query parameters.
Verb: The HTTP method for the request in uppercase, e.g. POST.
Content MD5: An MD5 hash of the request body in JSON

The steps we would take to create the hash code are:

Create a signed string using our values above.
Generate a hash using the string and our secret key.
Base64 encode the hash and attach it to the request header

Other values, such as the request content type, can be used, but I’ll keep it simple. Each API’s scheme for creating the signed string used for hashing is usually described in the API’s documentation.

Setting Up

To start, spin up a new Laravel application and add a couple of controllers to add our API logic.

php artisan make:controller UsersController
php artisan make:controller ClientController

Add a few routes for the endpoints in routes/api.php

Route::prefix('/')->middleware('auth.hmac')->group(static function () {
    Route::get('/users', [App\Http\Controllers\UsersController::class, 'getAll']);
    Route::get('/users/{id}', [App\Http\Controllers\UsersController::class, 'getOne']);
    Route::post('/users', [App\Http\Controllers\UsersController::class, 'create']);
    Route::put('/users/{id}', [App\Http\Controllers\UsersController::class, 'update']);
});

I’ve assigned a middleware auth.hmac to the routes, and I'll return to this later. Next, save the example public and secret keys in the .env file and reference them in a config file config/hmac.php. The public key here is the intended request header key for the HMAC.

# .env
HMAC_PUBLIC_KEY="X-MEN-SIGNATURE"
HMAC_SECRET_KEY="Xavier's School for Gifted Youngsters"

<!-- hmac.php -->
<?php
    return [
        'public' => 'X-MEN-SIGNATURE',
        'secret' => "Xavier's School for Gifted Youngsters"
    ];

Next, a few methods in the controllers to create, get and edit users for the simple context of this tutorial. The User model comes with the Laravel install; we don’t need to change anything.

use App\Models\User;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Facades\Validator;

class UsersController extends Controller
{
    public function getAll(Request $request)
    {
        $users = User::all();
        return response()->json($users);
    }

    public function getOne(Request $request, $id)
    {
        $user = User::findOrFail($id);
        return response()->json($user);
    }

    public function create(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'name' => 'required',
            'email' => 'required|email|unique:users',
            'password' => 'required|min:6'
        ]);
        if ($validator->fails()) {
            return response()->json($validator->errors()->first(), 400);
        }
        extract($request->all());
        $password = Hash::make($password);
        $user = User::create(compact('name', 'email', 'password'));
        return response()->json($user);
    }
    public function update(Request $request, $id)
    {
        $user = User::findOrFail($id);
        $data = [
            'name' => $request->name ?? $user->name,
            'email' => $request->email ?? $user->email,
            'password' => Hash::make($request->name) ?? $user->password
        ];
        $user->update($data);
        return response()->json($user);
    }
}

Hash It Up

Now, we have working controller logic for a simple API. However, making a call to it would result in an error due to the missing middleware. Let’s come back to that. This middleware is going to be the location for the HMAC authentication. Before the controller handles the request, we will confirm that it contains the correct HMAC header.

Add a new middleware:

php artisan make:middleware HmacAuth

And register it by adding it to $routeMiddleware in App\Http\Kernel.php

protected $routeMiddleware = [
    ...
    'auth.hmac' => \App\Http\Middleware\HmacAuth::class,
    ...
];

Now, for the real work. Remember the scheme used for creating the signed string. Let’s go ahead and implement it. First, we check if the header we need is even on the request and abort it if it isn’t.

$header = config('hmac.public');
$request_hash = $request->headers->get($header);
if (!$request_hash) {
    $message = 'Header `' . $header . '` missing.';
    abort('403', $message);
}

If it is, we get our string, which is the concatenation using newlines, of the HTTP method, URL and the MD5 hash of the request body in JSON. Using the secret key, we then run the HMAC SHA-256 hashing algorithm on the string. This value is finally Base64 encoded using UTF8 and compared with the value in our HMAC header. If they match, we can keep processing the request, or else, we abort.

Here’s what the final code should look like:

class HmacAuth
{
    /**
     * Handle an incoming request.
     *
     * @param  \Closure(\Illuminate\Http\Request): (\Symfony\Component\HttpFoundation\Response)  $next
     */
    public function handle(Request $request, Closure $next): Response
    {
        $header = config('hmac.public');
        $request_hash = $request->headers->get($header);
        if (!$request_hash) {
            $message = 'Header `' . $header . '` missing.';
            abort('403', $message);
        }

        $body = $request->all();
        $url = config('hmac.webhook');
        $verb = $request->method();
        $md5 = md5(json_encode($body));

        $string = $verb . PHP_EOL . $url . PHP_EOL . $md5;

        $hash = hash_hmac('SHA256', $string, config('hmac.secret'));
        $base64_hash = base64_encode($hash);

        if ($base64_hash !== $request_hash) {
            $message = 'Invalid `' . $header . '` Header';
            abort('403', $message);
        }

        return $next($request);
    }
}

And that’s all. HMAC signature verification is one of the simplest and most powerful methods for API requests and webhook authentication.