DEV Community: Matsounga Jules

Wall-Eve

Matsounga Jules — Mon, 29 Aug 2022 16:56:21 +0000

Overview of My Submission

Wall-Eve is a web application looking to provide aggregated data for the market of the game Eve Online.

A quick presentation of Eve Online and its market

Eve Online is an MMORPG that provide an API to allow developers of third parties to fetch and work with a lot of data from the game. It offers a great opportunity to build fun applications that we can share with other players.

One of the core of the game, trading, has its own endpoints where we can get orders with their price currently running for the different objects that players are buying and selling.

Market is divided in regions (you can see this as state, or country) and each region contains a lot of place (like cities) where people will buy and sell.

Where do this lead us ?

Developers looking to build a market tool will mostly interact with the endpoints returning orders from a region.
The problem is that this endpoint does not return aggregated data by items, but all the orders. It's mean you may have to pull more than 300 pages of 10000 entries, then aggregate them to be able to work with them.
It can be a bit tedious as it often requires the use of concurrency, a language able to work with a lot of data.

Due to that, it has been a while since I am wondering if it is not possible to provide an API that will return the data already aggregated with the possibility to filter on it with some query parameters. Let see how Redis can help me on this.

Design of the application

The basic design is simple, we need to fetch regularly the data from the endpoints provided by the game, so I have data up-to-date. Then I just have to serve the data through an API, and filter its output with the value entered by the user in the request.

With this description, we already have 2 services defined:

an API that will display the data
an Indexer that will fetch the data for a region

Even if these 2 services can be enough, we would lack the ability to control correctly the indexation.

Let's talk about the more complex design I have in mind.
Some regions in Eve Online have a slow trading pace and are ignored by a lot of traders. That's mean that the data for these regions do not necessarily need to be updated as soon as the main marketplaces of the game. This will help reduce i/o when possible.

I want to be able to schedule indexation, so I can prioritize which regions will be pull quickly and which one will be delayed longer. With that emerge 2 new services:

a Scheduler that will determine the time for the next indexation
a Delayer that will keep the delayed jobs in queue until they are due to process I made 2 services here, so they can evolve independently of each other

But I still have a problem. How do I prioritize which region to index ?
I need to be able to determine which region is important, and to do that I will simply listen to the call made to the API. If a region is frequently accessed through the API, it indicates that the data need to be kept updated. Otherwise, we can delay a bit more the indexation, people won't notice it.
Here come another service:

a Heartbeat that will listen to the call made to the API and store them, so we can use them later

However, by doing that, if someone calls the API for a region that has a slow rate of indexation, he may have too old data that may be not updated before a long time.
I need to be able to catch up the indexation if needed, so even if the first few hits contain old data, the following hits will have fresh data. This leads to the creation of our last service:

a Refresh that will also listen to the call made to the API and determine if we need to catch up the data

I now have 6 services looking to work together.

Technical implementation

I will need to use some Redis features to be able to make this services work together. Here is a schema of the services

And below, a description of the workflow and the interaction between services.

1. Indexation

This service listen to a stream indexationAdd, and once a message arrive in it, will start the indexation.
The task can be a bit slow and require 1 or 2 minutes, so Indexer can work in group to consume the stream faster.

Indexing require fetching all the orders for a region, but also to get some other data like the name of the place where it is, the name of the items and few other names. We can get them thanks to the API of the game, but to reduce i/o with it, we will store them inside the Redis, so we can access them faster later.

Once done, the indexing will store the data into Redis. The data is basically aggregated by item and location, and we keep the highest buy price and the lowest sell price and all the other extra data. By doing that, we have the price of all items at theirs different locations.
To store this data, we use the JSON stack, so we can have an index and ease the search later.
We also set the TTL for these entries to be 24 hours. By doing this, we are sure that data not updated will be removed from Redis and also act as a stale cache in case there is a problem with the indexation workflow.

At the end, the service send an event with the region into the stream indexationFinished

2. Scheduling

The scheduler listen to the event send into the stream indexationFinished and once a message arrive it will determine at which time to start the new indexation for the region given.

To do so, it will read the data stored into a timeseries table related to the region to calculate when is due the new indexation.

For this demo, I kept the math simple. But the idea is, if there were calls on the API in the last 5 minutes, the indexation need to be schedule in 5 minutes. If there were calls on the API in last hour, the indexation need to be schedule in 10 minutes. Otherwise, we delay it of 1 hour.

This information is then stored in a sorted set with a score equal to the timestamp calculated earlier.

3. Delayer

We now have a task in a sorted set, and we need to determine when to really start the indexation. As the data in the set are sorted with the lowest timestamp, I can just take the first item and look if the time is correct to start the indexation.
If it is OK, the delayer will send an event with the region in the stream indexationAdd and remove the entry from the sorted set.

4. API

Now that background tasks are running, we can display the aggregated data to the user of the API.
To do that, we provide an endpoint /market, that requires as query parameter locationand accepts few other query parameters to help filter the data returned.

//List of query parameters
location #regionName, systemName, locationName, regionId, systemId, locationId
minBuyPrice
maxBuyPrice
minSellPrice
maxSellPrice

These entries will be used with the search engine of Redis against the following index

FT.CREATE denormalizedOrdersIx
    ON JSON
    PREFIX 1 denormalizedOrders:
    SCHEMA
        $.regionId AS regionId NUMERIC
        $.systemId AS systemId NUMERIC
        $.locationId AS locationId NUMERIC
        $.typeId AS typeId NUMERIC
        $.buyPrice AS buyPrice NUMERIC
        $.sellPrice AS sellPrice NUMERIC
        $.buyVolume AS buyVolume NUMERIC
        $.sellVolume AS sellVolume NUMERIC
        $.locationName AS locationName TEXT
        $.systemName AS systemName TEXT
        $.regionName AS regionName TEXT
        $.typeName AS typeName TEXT
        $.locationNameConcat AS locationNameConcat TEXT
        $.locationIdTags AS locationIdTags TAG SEPARATOR ","

// Search with query parameter location that is a string
FT.SEARCH denormalizedOrdersIdx @locationNameConcat:(Dodixie IX Moon 20) @buyPrice:[5000000.00 10000000] @sellPrice:[6000000 20000000] LIMIT 0 10000

// Search with query parameter location that is a number
FT.SEARCH denormalizedOrdersIdx @locationIdsTag:{60011866} @buyPrice:[5000000.00 10000000] @sellPrice:[6000000 20000000] LIMIT 0 10000

With it, we can easily serve only the data wanted by the user.
As we can see, the query parameter location accept either a string or a number. It is like that to reduce the need for the user to have the exact id of the region, system or location where he is searching.

Each called made to the API will publish an event apiEvent with the region into a pub/sub.

5. Heartbeat

This service only listen the event published into apiEvent to save into a timeseries table related to the region, when the API has been called.

6. Refresh

As we saw earlier, data from a region without a lot of access are indexer at a slow rate.
To help reduce this issue, I look if a region need a catch-up.
To do that, I look into the sorted set indexationDelayed created by the scheduler if an entry exist for the region with a score between now (when the event is received) and the next 5 minutes.
If not, I send an event into the stream indexationCatchup with the region, so the scheduler can schedule a new indexation.
To prevent too much catch-up, I also store that a catch-up as been requested for this region during 10 minutes

7. Scheduling catch-up

This part of the workflow is also made by the scheduler. It also listens to indexationCatchup and once an event is received, we directly create an entry in the stream indexationAdd so the indexation can start as soon as possible.

Submission Category:

Microservice Mavens

Language Used

Golang

Link to Code

hyoa / wall-eve

Wall-Eve

Wall-Eve is an API that provide aggregated data from the market of the game Eve-Online.

Eve-Online is a MMORPG where trading is an important aspect of the game. The developers provide a lot of endpoints to help the development of third parties tool but the endpoint for the market does not provide aggregated data, meaning that most of the developers creating market application have to pull the data, aggregate it and then work with it.

Wall-Eve is a possible solution to this problem. It aggregate the data and let people retrieve informations using the API exposed by this application. They even can filter using some query parameters.

The application will refresh the data regurarly to provide up-to-data informations.

Overview video (Optional)

Here's a short video that explains the project and how it uses Redis:

How it works

Check on dev.to to have a detailed post on how works the…

View on GitHub

Check out Redis OM, client libraries for working with Redis as a multi-model database.
Use RedisInsight to visualize your data in Redis.
Sign up for a free Redis database.

Symfony on a lambda: conclusion

Matsounga Jules — Fri, 10 Apr 2020 07:16:17 +0000

Symfony on a lambda: Conclusion

If you are lost, you can find the project on Github: link
Each branch will match a chapter.

Performance

Okay, if you did some tests you may have notice that the first hit is really slow. That's because we create the cache at each cold start. Not great (not great at all). We can do some update to reduce the time required for the cold start.

First, need to remove the modification we made in src/Kernel.php :

public function getCacheDir(): string
{
    if (getenv('LAMBDA_TASK_ROOT') !== false) {
            return '/tmp/cache/'.$this->environment;
    }

    return parent::getCacheDir();
}

Should become :

public function getCacheDir(): string
{
    return parent::getCacheDir();
}

The application will now use the cache that you provide when uploading the lambda.

Second, because Twig still want to write cache, we have to tell him to do it somewhere else.
In config/packages/twig.yaml, add the following line:

twig:
    default_path: '%kernel.project_dir%/templates'
    debug: '%kernel.debug%'
    strict_variables: '%kernel.debug%'
    cache: '/tmp/cache/twig'

With this, Twig will continue to write in the /tmp directory

This will reduce by more than 1 seconde the duration of the cold start. It could be lower if Twig was not part of the application (for an api for example) as we wouldn't have to write anything at all.

Deployement

Deployement can be simplified with a script that will run all of the others. Here an example (I'm bad with shell scripts so please be indulgent):

#!/bin/sh

echo "Creating build directory"
mkdir -p $PWD/lambda_build

echo "Cleaning build directory"
rm -rf $PWD/lambda_build/*

echo "Copying code to build directory"
cp -r $PWD/assets $PWD/lambda_build/assets
cp -r $PWD/bin $PWD/lambda_build/bin
cp -r $PWD/config $PWD/lambda_build/config
cp -r $PWD/public $PWD/lambda_build/public
cp -r $PWD/src $PWD/lambda_build/src
cp -r $PWD/templates $PWD/lambda_build/templates
cp -r $PWD/translations $PWD/lambda_build/translations
mkdir $PWD/lambda_build/var
cp $PWD/composer.json $PWD/lambda_build/composer.json
cp $PWD/composer.lock $PWD/lambda_build/composer.lock
cp $PWD/package.json $PWD/lambda_build/package.json
cp $PWD/package-lock.json $PWD/lambda_build/package-lock.json
cp $PWD/serverless.yml $PWD/lambda_build/serverless.yml
cp $PWD/symfony.lock $PWD/lambda_build/symfony.lock
cp $PWD/webpack.config.js $PWD/lambda_build/webpack.config.js
cp $PWD/postcss.config.js $PWD/lambda_build/postcss.config.js
cp $PWD/.env $PWD/lambda_build/.env

echo "CD in build directory"
cd $PWD/lambda_build

echo "Pulling dependencies"
APP_ENV=prod composer install --no-dev --optimize-autoloader
npm install

echo "Building assets"
npm run build

echo "Sync assets"
aws s3 sync public/build s3://cloud-project-eu-west-2-dev-assets --profile default

echo "Remove css and js"
rm public/build/*.js
rm public/build/*.css

echo "Remove node_modules"
rm -rf node_modules

echo "Clear cache"
php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

echo "Deploying"
serverless deploy

echo "Finished"
cd ..

Idea is to run all the commands in an other directory to not pollute the dev environment.

Conclusion

Should you run all of your application Symfony on a lambda ? Absolutely not !

Lambda are great for some task and I wanted to show here that it can also work with PHP, even with a framework used for a real website. Coding on a lambda does not change the way we code usually (except for /tmp directory) and therefore, we shouldn't be afraid to use it if it match our need.

Lambdas are of course more practical for jobs or apis. The peformance can be disturbing but with Symfony 5 (or 4.4) without twig we have a cold start below 300ms, which is really reasonable.

So try it out, have fun with them and long live to PHP :P

Symfony on a lambda: authentication

Matsounga Jules — Fri, 10 Apr 2020 07:08:51 +0000

Symfony on a lambda: connections

If you are lost, you can find the project on Github: link
Each branch will match a chapter.

Authentications

Now that we know how to handle our sessions, we can work with the authentication.

Creation of the user table

Like for the session, we need a table to store our users. Let's create one !
In our serverless.yml will add the following resource:

//serverless.yml
service: [name of your project]

provider:
    // ...
custom:
    // ...
plugins:
    // ...

functions:
    // ...

resources:
    Resources:
        // ...
    UsersTable:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: ${self:custom.prefix}-usersTable
            AttributeDefinitions:
            - AttributeName: email
                AttributeType: S
            KeySchema:
            - AttributeName: email
                KeyType: HASH
        ProvisionedThroughput:
            ReadCapacityUnits: 1
            WriteCapacityUnits: 1

We add a table to store our users, and define the field email as the index. We can now just run serverless deploy to create the table.

Once the table is created, we can now code the authentication system !

Forms

Symfony has a simple tool to produce what we need to login, lets use it. But first we need to create a class for our user.
In src/Entity, add the following class:

<?php

namespace App\Entity;

use Symfony\Component\Security\Core\User\UserInterface;

class User implements UserInterface
{
    /** @var string */
    protected $email;

    /** @var string */
    protected $password;

    /** @var array */
    protected $roles;

    public function getEmail(): ?string
    {
        return $this->email;
    }

    public function setEmail(string $email): string
    {
        $this->email = $email;

        return $this;
    }

    public function setRoles(array $roles): self
    {
        $this->roles = $roles;

        return $this;
    }

    public function getRoles(): array
    {
        return $this->roles;
    }

    public function getPassword(): ?string
    {
        return $this->password;
    }

    public function setPassword(string $password): self
    {
        $this->password = $password;

        return $this;
    }

    public function getSalt()
    {
        return null;
    }

    public function getUsername(): string
    {
        return $this->email;
    }

    /**
     * Removes sensitive data from the user.
     *
     * This is important if, at any given point, sensitive information like
     * the plain-text password is stored on this object.
     */
    public function eraseCredentials()
    {
        // TODO: Implement eraseCredentials() method.
    }
}

Now, run the command php bin/console make:auth, then type 1, LoginFormAuthenticator and press enter for the other questions.

One small problem is, the template used for login has no style. Let's add some (so we can at least see the fields). Because I'm lazy (and that I have no idea for the design of this exercise), I will borrow what has been done on the landing page.

Here is my template:

{% extends 'base.html.twig' %}

{% block title %}Log in!{% endblock %}

{% block body %}
    <section id="landing">
        <div id="landing-background">
        </div>
        <section class="w-1/2 mx-auto -mt-10 bg-white shadow-md py-2 px-4 rounded">
            <form method="post">
                {% if error %}
                    <div class="alert alert-danger">{{ error.messageKey|trans(error.messageData, 'security') }}</div>
                {% endif %}

                {% if app.user %}
                    <div class="mb-3">
                        You are logged in as {{ app.user.username }}, <a href="{{ path('app_logout') }}">Logout</a>
                    </div>
                {% endif %}

                <h1 class="h3 mb-3 font-weight-normal">Please sign in</h1>
                <label for="inputEmail">Email</label>
                <input
                    type="email"
                    value="{{ last_username }}"
                    name="email" id="inputEmail"
                    required
                    autofocus
                >

                <label for="inputPassword">Password</label>
                <input
                    type="password"
                    name="password"
                    id="inputPassword"
                    required
                >

                <input type="hidden" name="_csrf_token"
                       value="{{ csrf_token('authenticate') }}"
                >

                {#
                    Uncomment this section and add a remember_me option below your firewall to activate remember me functionality.
                    See https://symfony.com/doc/current/security/remember_me.html

                    <div class="checkbox mb-3">
                        <label>
                            <input type="checkbox" name="_remember_me"> Remember me
                        </label>
                    </div>
                #}

                <button class="bg-blue-400 text-white p-2 rounded-sm mt-2" type="submit">
                    Sign in
                </button>
            </form>
        </section>
    </section>
{% endblock %}

To style the input, create assets/scss/components/form.scss with the following style:

form {
  input[type="text"], input[type="email"], input[type="password"] {
    @apply block border border-gray-400 p-2 w-full;
  }
}

And dont forget to import it in assets/scss/app.scss

We will now do the same for the registration.
Run php bin/console make:registration-form, just answer no to Do you want to add a @UniqueEntity validation annotation on your User class to make sure duplicate accounts aren't created? (yes/no) [yes], we will handle that ourself. For this one we will also change the design, here is my template

{% extends 'base.html.twig' %}

{% block title %}Register{% endblock %}

{% block body %}
    <section id="landing">
        <div id="landing-background">
        </div>
        <section class="w-1/2 mx-auto -mt-10 bg-white shadow-md py-2 px-4 rounded">
            Please register
            {{ form_start(registrationForm) }}
                {{ form_row(registrationForm.email) }}
                {{ form_row(registrationForm.plainPassword) }}
                {{ form_row(registrationForm.agreeTerms) }}

                <button class="bg-blue-400 text-white p-2 rounded-sm mt2">Register</button>
            {{ form_end(registrationForm) }}
        </section>
    </section>
{% endblock %}

Great, now that we have some visual, let's work connect everything !

Registration

First thing we want to work with is the registration.
We need an encoder to encode our password. Let's add it, open config/packages/security.yaml and add the following lines:

security:
    //....
    encoders:
        Symfony\Component\Security\Core\User\UserInterface: auto

Now, because we don't use an SQL database we can't use doctrine to persist our user. Let's create our own repository to work with.
In src/Repository/UserRepository.php add the following lines

<?php

namespace App\Repository;

use App\Entity\User;
use App\Services\AwsClient;
use Aws\DynamoDb\Marshaler;

class UserRepository
{
    protected $dynamoDbClient;

    protected $tableName;

    public function __construct(AwsClient $awsClient, string $tableName)
    {
        $this->dynamoDbClient = $awsClient->dynamoDbClient();
        $this->tableName = $tableName;
    }

    public function insert(User $user): User
    {
        $item = (new Marshaler())
            ->marshalJson((string) json_encode([
                'email' => $user->getEmail(),
                'password' => $user->getPassword(),
                'roles' => $user->getRoles()
            ]));

        $this->dynamoDbClient->putItem([
            'TableName' => $this->tableName,
            'Item' => $item,
        ]);

        return $user;
    }
}

We just create a service with the dynamoDbClient we used for our session handling. We also pass the table name to the constructor as it change depending of the stage and project name. Because of that we need to update our config/services.yaml

//...

App\Repository\UserRepository:
    arguments:
    $tableName: '%env(APP_AWS_RESOURCE_PREFIX)%-usersTable'

To come back to our repository, we just create a simple insert function. DynamoDb has its own format so we have to transform the data with the help of Marshaler .

We should now update the RegistrationController.php to use this repository. The function register should now look like this:

    public function register(
        Request $request,
        UserPasswordEncoderInterface $passwordEncoder,
        GuardAuthenticatorHandler $guardHandler,
        LoginFormAuthenticator $authenticator,
        UserRepository $userRepository
    ): Response {
        $user = new User();
        $form = $this->createForm(RegistrationFormType::class, $user);
        $form->handleRequest($request);

        if ($form->isSubmitted() && $form->isValid()) {
            // encode the plain password
            $user->setPassword(
                $passwordEncoder->encodePassword(
                    $user,
                    $form->get('plainPassword')->getData()
                )
            );

            $user->setRoles(['ROLE_USER']);
            $userRepository->insert($user);

//            return $guardHandler->authenticateUserAndHandleSuccess(
//                $user,
//                $request,
//                $authenticator,
//                'main' // firewall name in security.yaml
//            );
        }

We pass our repository and use it. We also give a role to our user so once login it can do something. As we don't have connect the authentication, we comment the rule that auto-connect once logging. We will uncomment it later.

Login

We now have a user in the database, so we can connect. Still, because we don't use a SQL database, we will need to have or own user provider that will fetch our user from our dynamoDb table.

Create a new class src/Security/UserProvider.php:

<?php

namespace App\Security;

use App\Entity\User;
use App\Repository\UserRepository;
use Symfony\Component\Security\Core\Exception\UsernameNotFoundException;
use Symfony\Component\Security\Core\User\UserInterface;
use Symfony\Component\Security\Core\User\UserProviderInterface;

class UserProvider implements UserProviderInterface
{
    /** @var UserRepository */
    protected $userRepository;

    public function __construct(UserRepository $userRepository)
    {
        $this->userRepository = $userRepository;
    }

    public function loadUserByUsername($username): UserInterface
    {
        $user = $this->userRepository->findOneByEmail($username);

        if ($user === null) {
            throw new UsernameNotFoundException();
        }

        return $user;
    }

    public function refreshUser(UserInterface $user)
    {
        return $user;
    }

    public function supportsClass($class)
    {
        return User::class === $class;
    }
}

The class does not do a lot of thing:

loadUserByUsername will get our user using the repository (don't worry, we will implement the method just after).
refreshUser is used once the page change and that we are logged, we can refresh some data if we want.
supportsClass is only use to determine if this provider can be use with the entity we retrieved.

Let's create our method find in the repository.

// src/Repository/UserRepository
public function findOneByEmail(string $email): ?User
{
    $key = (new Marshaler())
        ->marshalJson((string) json_encode(['email' => $email]));

    $userDocument = $this->dynamoDbClient
        ->getItem([
          'TableName' => $this->tableName,
          'Key' => $key,
        ])
        ->get('Item')
    ;

    if ($userDocument === null) {
        return null;
    }

    $userArray = (new Marshaler())->unmarshalItem($userDocument);

    return (new User())
        ->setEmail($userArray['email'])
        ->setPassword($userArray['password'])
        ->setRoles($userArray['roles'])
    ;
}

Here, we search the user using its email. Because we set email as the index of the table, we can query on it easily.
If we don't have any user we just return null, otherwise we hydrate a new User object.

We can now tell Symfony to use our custom provider. To do that, we have to edit src/config/packages/security.yaml:

security:
        providers:
        user_provider:
            id: App\Security\UserProvider
    //...

Now it's time to update src/Security/LoginFormAuthenticator.php. Once create using the make command, some methods are let empty, so we have to complete them.

First, we have to update the constructor:

protected $userPasswordEncoder;

public function __construct(
    UrlGeneratorInterface $urlGenerator,
    CsrfTokenManagerInterface $csrfTokenManager,
    UserPasswordEncoderInterface $userPasswordEncoder
) {
    $this->urlGenerator = $urlGenerator;
    $this->csrfTokenManager = $csrfTokenManager;
    $this->userPasswordEncoder = $userPasswordEncoder;
}

We will use the UserPasswordEncoderInterface to check that the password entered in the login form match the user that we found in the table.

Next, let's edit the checkCredentials method:

public function checkCredentials($credentials, UserInterface $user)
{
    return $this->userPasswordEncoder->isPasswordValid($user, $credentials['password']);
}

The method talk for itself.

Then, we have to edit onAuthenticationSuccess to have a correct redirection once the user is authenticated:

public function onAuthenticationSuccess(Request $request, TokenInterface $token, $providerKey)
{
    if ($targetPath = $this->getTargetPath($request->getSession(), $providerKey)) {
        return new RedirectResponse($targetPath);
    }

    return new RedirectResponse($this->urlGenerator->generate('app_user_index'));
}

app_user_index is a new route, we will have to create it. To do so, create a new class src/Controller/UserController :

<?php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class UserController extends AbstractController
{
    /**
     * @Route("/user", name="app_user_index")
     * @IsGranted("ROLE_USER")
     */
    public function index(): Response
    {
        return $this->render('user/index.html.twig', ['user' => $this->getUser()]);
    }
}

And then create the template templates/user/index.html.twig:

{% extends 'base.html.twig' %}

{% block body %}
    <main id="landing" class="w-screen h-screen bg-blue-100">
        <div id="landing-background">
        </div>
        <section class="w-1/2 mx-auto -mt-10 bg-white shadow-md py-2 text-center rounded">
            <h1 class="text-4xl">Welcome {{ user.email }}</h1>
        </section>
    </main>
{% endblock %}

You can now log in, you will be redirect to the template above.

It's time to uncomment the lines that we commented in src/Controller/RegistrationController.php, now, once we register we will be automatically log in.

You can logout with the /logout route, it has been created automatically earlier.

Thanks to the session, we can now navigate without losing the connection. See you in the last chapters for some tips and information that can be helpful.

Symfony on a lambda: sessions

Matsounga Jules — Mon, 20 Jan 2020 07:20:47 +0000

Symfony on a lambda: sessions

If you are lost, you can find the project on Github: link
Each branch will match a chapter.

Sessions handling

Handling session is quite important when dealing with a website. It can be used to store many data that we will be able to use easily everywhere on the site.
Sessions are generated by the server, send to the client through a cookie that the client will reuse to authenticate on the application.

By default, Symfony save the session in memory on the server. But lambda don't last forever, so sessions stored on the lambda could disappear at any moment.

Fortunately, we can store sessions on database. In our case, DynamoDB. DynamoDB is a key-value and document database provided by AWS.

Creation of the session table

We will need new resource on our cloudformation, a table to store our sessions.
Let's edit our serverless.yml file to add this new resource.

//serverless.yml
service: [name of your project]

provider:
    // ...
custom:
    // ...
plugins:
    // ...

functions:
    // ...

resources:
    Resources:
        // ...
    SessionsTable:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: ${self:custom.prefix}-sessionsTable
            AttributeDefinitions:
            - AttributeName: id
                AttributeType: S
            KeySchema:
            - AttributeName: id
                KeyType: HASH
        ProvisionedThroughput:
            ReadCapacityUnits: 1
            WriteCapacityUnits: 1

As I said earlier, DynamoDB is a key-value document database. That's mean we will have to define the key that we will use to retrieve our document. Unlike SQL database, we don't have to define a entire structure as we will store document. See more information here.

We create a new resource of type: AWS::DynamoDB::Table. This table will have the name sessionsTable prefixed by the custom prefix we created on the previous chapter.
Then we define our HASH key that we will use to get our document: id and say it is of type string S.
We also define the ProvisionedThroughput, that define the number of read by second that we can achieve. As it's only a exercise, 1 is enough. (More information here: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html)

We can now create our new table on AWS using serverless deploycommand.

Storing session in the table

Now that our table is created, let's change the way Symfony store our session.
At first, we need to install the SDK provided by AWS to interact with the table. Type composer require aws/aws-sdk-php ^3.112 to install it.

We will then create a service that will handle our sessions.
In src/Services create a file DynamoDbSessionHandlerFactory.php that will contain the following class:

<?php

namespace App\Services;

use Aws\DynamoDb\DynamoDbClient;
use Aws\DynamoDb\SessionHandler;

class DynamoDbSessionHandlerFactory
{
    public static function build(DynamoDbClient $dbClient): SessionHandler
    {
        return SessionHandler::fromClient($dbClient, ['table_name' => 'sessionsTable']);
    }
}

We will use this factory to create our service.

In src/Services create a file AwsClient.php that will contain the following class:

<?php

namespace App\Services;

use Aws\DynamoDb\DynamoDbClient;
use Aws\S3\S3Client;
use Aws\Sdk;

class AwsClient
{
    /** @var Sdk */
    protected $sdk;

    public function __construct(
        string $region,
        string $version,
        string $dynamoDbCredentialKey,
        string $dynamoDbCredentialSecretKey
    ) {
        $this->sdk = new Sdk([
            'region'   => $region,
            'version'  => $version,
            'Dynamodb' => [
                'credentials' => [
                    'key' => $dynamoDbCredentialKey,
                    'secret' => $dynamoDbCredentialSecretKey
                ]
            ]
        ]);
    }

    public function dynamoDbClient(): DynamoDbClient
    {
        return $this->sdk->createDynamoDb();
    }
}

This service handle the connection to AWS and create the required client, here the client for DynamoDB.

We can now define both of this services so Symfony can use them correctly. Edit config/services.yaml:

// ...

services:
    // ...
  App\Services\AwsClient:
    arguments:
        $region: '%env(resolve:APP_AWS_REGION)%'
        $version: '%env(resolve:APP_AWS_VERSION)%'
        $dynamoDbCredentialKey: '%env(resolve:APP_AWS_DYNAMODB_CREDENTIAL_KEY)%'
        $dynamoDbCredentialSecretKey: '%env(resolve:APP_AWS_DYNAMODB_CREDENTIAL_SECRET)%'   

    App\Services\SessionHandler:
        factory: ['App\Services\DynamoDbSessionHandlerFactory', 'build']
    arguments:
        - "@=service('App\\\\Services\\\\AwsClient').dynamoDbClient()"
        - '%env(resolve:APP_AWS_RESOURCE_PREFIX)%'
    calls:
        - method: register

Our AwsClient require some environment variables. Let's define them.
Edit .env at the root of your folder and add the following lines:

APP_AWS_REGION=''
APP_AWS_VERSION=''
APP_AWS_DYNAMODB_CREDENTIAL_KEY=''
APP_AWS_DYNAMODB_CREDENTIAL_SECRET=''
APP_AWS_RESOURCE_PREFIX=''

Do not put your credentials in this file ! As it will be committed and push to your repository. You don't want to have your secrets expose to internet.

Now create .env.local at the root of your projects and add the previous lines. This files is ignored thanks to .gitignore, so you can put your information here.
APP_AWS_RESOURCE_PREFIX is the custom prefix define in serverless.yml: [service-name]-[region]-[stage]

We can now edit the handler of session of Symphony. Edit config/packages/framework.yaml

framework:
    secret: '%env(APP_SECRET)%'
    session:
        handler_id: App\Services\SessionHandler
        cookie_secure: auto
        cookie_samesite: lax
    php_errors:
        log: true

Our handler_id refer to our service created with the factory.

As a quick test to see if it's working. Edit src/Controller/HomeController.php

// ...    

public function homeAction(SessionInterface $session): Response
{
    $session->set('foo', 'bar');
    return $this->render('home/index.html.twig');
}

Now, go in the AWS Console, search for DynamoDB, click on the link. At the left, select Tables then your session table. In elements, you should see the data stored.

Making it work on the lambda

Almost everything is already set to have it working on a lambda, except that we don't have any of the environments variables that we just added.

We will have to add them in our serverless.yml

service: // ...

provider:
    // ...
    environment:
            // ...
        APP_AWS_REGION: 'eu-west-2'
        APP_AWS_VERSION: 'latest'
        APP_AWS_DYNAMODB_CREDENTIAL_KEY: ''
        APP_AWS_DYNAMODB_CREDENTIAL_SECRET: ''
        APP_AWS_RESOURCE_PREFIX: ${self:custom.prefix}

As said earlier, we cannot store our keys on files that are committed to our repository. This one is, so we can't put our key here neither. But we still need to have this information to be passed to serverless and we can't make a .local this time.

We will use AWS Systems Manager to secure our keys. Visit the AWS Console, search for Systems Manager and select Parameter Store in the left panel.
We can now create our 2 keys, click on create parameter:

Name: [service]/[stage]/key
Description: Add what you want
Tier: Standard
Type: String
Value: Put your key here

Then click on Create parameter
Repeat the operation for the secret (name: [service]/[stage]/secret)

We can now reference both of this parameter in serverless.yml

service: // ...

provider:
    // ...
    environment:
        APP_ENV: prod
        APP_AWS_REGION: 'eu-west-2'
        APP_AWS_VERSION: 'latest'
        APP_AWS_DYNAMODB_CREDENTIAL_KEY: ${ssm:/${self:service}/${self:provider.stage}/key}
        APP_AWS_DYNAMODB_CREDENTIAL_SECRET: ${ssm:/${self:service}/${self:provider.stage}/secret}
        APP_AWS_RESOURCE_PREFIX: ${self:custom.prefix}

ssm will interact with the Systems Manager to get the data at the path specified.

By default, a lambda cannot interact with other resource for security purpose. So will have to give it the right to interact with DynamoDB, otherwise we will get a fancy error about permission.
Still in serverless.yml, add the following lines:

service: // ...

provider:
        // ...
    iamRoleStatements:
        - Effect: Allow
          Action:
              - dynamodb:Query
              - dynamodb:Scan
              - dynamodb:GetItem
              - dynamodb:PutItem
              - dynamodb:UpdateItem
              - dynamodb:DeleteItem
          Resource: "arn:aws:dynamodb:[your region]:*:table/*"

This will give the lambda the ability to do the action defined in all the table. Of course, we can be more precise on which table we want to give permission and what permission we want but I prefer to keep it simple here.

With all of this, we can deploy the solution again with serverless deploy.
If you go back in the DynamoDB console, and then you browse the application through the link in the output at the end of the deploy command, you should see a new entry in the table. Well done !

Cleanup

First, let's remove the $session->set from HomeController.php, we don't need that anymore.
In a second time, we now have sessions working on lambda, but for local development we want to use the default storage method. We use our computer so we don't need to store our sessions in DynamoDB. To do so, we will have to override the session handling when we are in dev.

Create a file framework.yaml in config/packages/dev

framework:
    session:
        handler_id: null

This will prevent Symfony to use our new service and use the default method.

Now that our session are working, it's possible to deal with authentication ! See you in the next chapters

Symfony on a lambda: assets

Matsounga Jules — Mon, 18 Nov 2019 10:48:32 +0000

Symfony on a lambda: assets

If you are lost, you can find the project on Github: link
Each branch will match a chapter.

Webpack Encore

We saw in the previous chapter how to deploy our application on a lambda. We now have a site that is working on AWS, but it doesn't have any design.

Symfony offer to its developer Webpack Encore that package CSS and JS easely without touching the Webpack configuration.

It is really easy to install, you just have to type composer require symfony/webpack-encore-bundle then npm install.
This two commands will add the required files and dependencies.

The most important file here is webpack-config.js that you can find at the root of your project. Its define tasks performed by Webpack when you will run it (the location of your assets, the destination of the builded files, if there is versioning and much more).

First asset

When we installed Webpack Encore it has also created an app.js and a app.css in the folder assets.
We have to import them in the twig !

Our templates/home/index.html.twig herits from the base template. We will import the assets in this one.

In templates/base.html.twig, we will add:

<head>
    ...
  {% block stylesheets %}
    {{ encore_entry_link_tags('app') }}
  {% endblock %}
</head> 
<body>
    ...
  {% block javascripts %}
    {{ encore_entry_script_tags('app') }}
  {% endblock %}
</block>

This blocks will import the assets that Webpack will have package.

We can now run the command to launch Webpack: npm run build.
If you now look in public/build, you will see your assets created and a manifest.json and also an entrypoints.json.

If you look closely, you will see that your app.js and app.css have a hash in their file name. That what we called versioning.
To improve user experience, browsers cache websites assets (js, css, images, videos, ...) to avoid that the user download them again.
The cache is, among others, based on the file name. So by changing the file name at each build, we ensure that the browser download the latest version of our assets !

Now, if you launch your application (php bin/console server:run), you will see modification (a grey background and Hello Webpack Encore! Edit me in assets/js/app.js in the console).

Webpack Encore put at your disposal different commands:

build: create your production assets with versioning
dev: create your development assets
watch: look the at the modification in assets file and rebuild when necessary
dev-server: used for hot reloading. It refresh your browser when a change is detected in your js files.

Tailwindcss

Like a majority of sites, we need some visual customization. Here, we won't write a lot of CSS but work with Tailwindcss instead. It is a CSS framework based on utility-first. Its mean that we add class on our html element to stylise them. It can look a bit tedious but it is really easy to use.

Installation

Run npm install tailwindcss
Then we need to create an app.scss in assets/scss and add the following lines:

  @tailwind base;

  @tailwind components;

  @tailwind utilities;

Change require('../css/app.css')by require('../scss/app.scss'); in assets/js/app.js
Create a postcss.config.js file at the root of your project with the following configuration:

  module.exports = {
    plugins: [
      require('tailwindcss'),
    ]
  };

In webpack.config.js, add enablePostCssLoader() and enableSassLoader():

  Encore
        //...
      .enablePostCssLoader()
      .enableSassLoader(function (options) {}, {
        resolveUrlLoader: false
      })
  ;

Run npm install postcss-loader@^3.0.0 --save-devand npm install sass-loader@^7.0.1 node-sass --save-dev
Relaunch Webpack Encore (npm run dev-server or npm run watch ou npm run dev)

Its look like we installed a lot of thing but there is not so much to explain. It's the requirements to run Tailwindcss on our project.

Let's design

As I explained, Tailwindcss is utility-first, that mean we will use utility class that define the css that will be applied to our elements. The Tailwindcss documentations is impressive and has everything you need to work.

We will create the scss file of our page: assets/scss/components/landing.scss

#landing {
  #landing-background {
    background-color: #2b6cb0;
    background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='152' height='152' viewBox='0 0 152 152'%3E%3Cg fill-rule='evenodd'%3E%3Cg id='temple' fill='%23aee4e0' fill-opacity='0.4'%3E%3Cpath d='M152 150v2H0v-2h28v-8H8v-20H0v-2h8V80h42v20h20v42H30v8h90v-8H80v-42h20V80h42v40h8V30h-8v40h-42V50H80V8h40V0h2v8h20v20h8V0h2v150zm-2 0v-28h-8v20h-20v8h28zM82 30v18h18V30H82zm20 18h20v20h18V30h-20V10H82v18h20v20zm0 2v18h18V50h-18zm20-22h18V10h-18v18zm-54 92v-18H50v18h18zm-20-18H28V82H10v38h20v20h38v-18H48v-20zm0-2V82H30v18h18zm-20 22H10v18h18v-18zm54 0v18h38v-20h20V82h-18v20h-20v20H82zm18-20H82v18h18v-18zm2-2h18V82h-18v18zm20 40v-18h18v18h-18zM30 0h-2v8H8v20H0v2h8v40h42V50h20V8H30V0zm20 48h18V30H50v18zm18-20H48v20H28v20H10V30h20V10h38v18zM30 50h18v18H30V50zm-2-40H10v18h18V10z'/%3E%3C/g%3E%3C/g%3E%3C/svg%3E");
    height: 50vh;
  }
}

Then will will update our template templates/index.html.twig

{% extends 'base.html.twig' %}

{% block body %}
    <main id="landing" class="w-screen h-screen bg-blue-100">
        <div id="landing-background">
        </div>
        <section class="w-1/2 mx-auto -mt-10 bg-white shadow-md py-2 text-center rounded">
            <h1 class="text-4xl">Freelancer Tools</h1>
            <p>
                Enhance your productivity with some tools !
            </p>
        </section>
        <section class="w-1/2 flex mx-auto">
            <section class="w-1/2 p-4">
                <div class="border shadow bg-white rounded">
                    <header class="text-2xl text-center mb-2 pt-2 bg-blue-600 text-white rounded-t">
                        <h3>FREE</h3>
                    </header>
                    <main>
                       <ul class="px-4 text-center">
                           <li class="border-b border-gray-400 py-2">Manage your clients</li>
                           <li class="py-2">Create invoice</li>
                       </ul>
                    </main>
                </div>
            </section>
            <section class="w-1/2 p-4">
                <div class="border shadow bg-white rounded">
                    <header class="text-2xl text-center mb-2 pt-2 bg-blue-600 text-white rounded-t">
                        <h3>PREMIUM</h3>
                    </header>
                    <main>
                        <ul class="px-4 text-center">
                            <li class="border-b border-gray-400 py-2">All free features</li>
                            <li class="border-b border-gray-400 py-2">Send emails</li>
                            <li class="py-2">Notifications</li>
                        </ul>
                    </main>
                </div>
            </section>
        </section>
    </main>
{% endblock %}

I let you change this file as your need to have something with a better look :p

On the cloud

We now know how to build our asset, but we need them available on the cloud. We can't let them on the lambda, it is not their purpose to deliver assets. AWS has a service designed for that: AWS S3.

In a first place, we need to create a Bucket S3. Then we will be able to upload our assets on it and have access from a browser.

Bucket creation

We still wont use the AWS ui to create our bucket but use the serverless.yml instead.

//serverless.yml
service: [name of your project]

provider:
  // ...
custom:
  prefix: ${self:service}-${self:provider.region}-${self:provider.stage} #Prefix that change depending of the service name, the region where is deployed the application and the environment.
plugins:
  // ...

functions:
  // ...

resources:
  Resources:
    Assets: #Name of the resource on CloudFormation
      Type: AWS::S3::Bucket #Type of the resource
      Properties:
        BucketName: ${self:custom.prefix}-assets
    AssetsPolicy:
      Type: AWS::S3::BucketPolicy
      Properties:
        Bucket: !Ref Assets #Reference of the bucket above
        PolicyDocument:
          Statement:
            - Effect: Allow
              Principal: '*'
              Action: 's3:GetObject' #Only read right
              Resource: arn:aws:s3:::${self:custom.prefix}-assets/* #arn of the bucket

This modification allow us to define a S3 Bucket totally public on which we will be able to read documents that are inside.

Let's run serverless deploy to launch the creation.

Push assets

Now that our bucket is created, we need to deploy the assets on it. We wont do it manually, aws-cli provide a command to do it.

We need to run npm run build then aws s3 sync public/build s3://[bucket name].

To obtain the name of the bucket, you can run aws s3 ls that will display all the bucket on your account. You just have to pick the right one.

Link the assets

But it is not done. We know have to tell to Symfony the location of our assets, because by default it use the current domain as a path.

We will update webpack.config.json to change the public path when we run a production build. The public path is the url of our bucket.

// ...

if (Encore.isProduction()) {
  Encore.setPublicPath('https://[name of bucket].s3.eu-west-2.amazonaws.com');
  Encore.setManifestKeyPrefix('build/');
}

module.exports = Encore.getWebpackConfig();

Now, if you run npm run build and aws s3 sync public/build s3://[name of bucket], you should see on your local application (in the network tab of the console) that the assets are pulled directly from the S3.

Everything is ready, we can run again all the commands to see the change online:

npm run build && aws s3 sync public/build s3://[nom du bucket] && serverless deploy

We now have functional assets on the cloud !

Going further

Lambda have a limited space, so we shouldn't push what it is not required on it. We can specify exclude files and directories in serverless.yml.

//serverless.yml

service: [nom du projet]

package:
    exclude:
        - node_modules/**
        - var/log/**
        - public/build/**
        - var/cache/**
        - '!var/cache/prod/**' #We want to keep the warmup of Symfony
        - assets/**
        - tests/**
    include:
        - public/build/manifest.json
        - public/build/entrypoints.json

Ignoring this files reduce the size of our package.

It is also recommended to ignore dev dependencies by running composer install --optimize-autoloader --no-dev but this command will break your development environment. A good practice is to run this command on a other directory. We will talk about this in an other chapter !

We now know how to work with assets. We will see in the future chapter how to manage sessions and connections !

Symfony on a lambda: first deployment

Matsounga Jules — Fri, 08 Nov 2019 07:27:54 +0000

Symfony on a lambda: first deployment

English isn't my first language, help me improve my posts by pointing my mistakes

We can run serveless on many platforms, and same goes for cloud functions. As Bref only support AWS, we will focus on this platform.

As mentioned, we will use Bref. It help run PHP on a AWS Lambda.

We will use it with Symfony, a popular PHP framework.

If you are lost, you can find the project on Github: link
Each branch will match a chapter.

Requirements

Have the requirements to run Symfony on your computer (PHP and some extensions)
Have an AWS account(you can create one here: registration). We will stay below free tier limit, so no worries for your wallet.
Create an access key:
- Create a new user here
- Add a user name
- Enable Programmatic access
- Click Attach existing policies directly, search for **AdministratorAccess **and select it.
Warning: it is recommended to only select right that you really need. But too keep this presentation simple, we will use a full access key.
- Finish creating the user
- Take note of keys generated, we will need them after
Install serverless: npm install -g serverless
Create the configuration of serverless: serverless config credentials --provider aws --key <key> --secret <secret> where key and secret are from the keys generated earlier

Symfony

We now have everything we need to start our development. Let's go !

Installation of Symfony

In your terminal, type the following command at the root of your projects composer create-project symfony/website-skeleton [my_project_name] (remember to replace [my_project_name] with yours)

Once the installation done, you can go in the folder where is your Symfony application.

We can now install Bref, which is required to deploy PHP on a lambda. To do so, once in the project, type composer require bref/bref

Creation of the serverless.yml

This file will define the architecture that we will deploy on AWS, that will be called CloudFormation. It's in this file that we will define services and resources and their configurations that we want on AWS.

To create this file, Bref give us a command that will help init a project. Type vendor/bin/bref init et select HTTP application.

The command create our serverless.yml file and an index.php file at the root of our project. You can delete index.php we wont use it.

The serverless.yml should look like this:

service: app #Name of your application

provider:
    name: aws #Provider used by Serverless
    region: us-east-1 #Region where you will deploy your CloudFormation
    runtime: provided

plugins:
    - ./vendor/bref/bref

functions:
    api: #Name of the function
        handler: index.php
        description: ''
        timeout: 28 # in seconds (API Gateway has a timeout of 29 seconds)
        layers:
            - ${bref:layer.php-73-fpm}
        events:
            -   http: 'ANY /'
            -   http: 'ANY /{proxy+}'

The most interesting part is functions where we will be able to define our functions that we need (it can be commands, apis, crons, etc...).

handler: the php file used by the lambda
description: well, a description ?
timeout: maximum execution time of the function
layers: Layers are environment used by the lambda to run, you can have multiple layers to add other extensions, dependencies etc. Here, we use the layer of Bref, that run PHP with the layer of Node (more on layers)
events: events that will trigger the function. On this function, the HTTP event will trigger the lambda, but there is a lot of other events triggered by AWS that we can listen. We will see an other one later

Now that we have a better understanding of our file, lets changed it to run Symfony.

service: cloud-project

provider:
    name: aws
    region: eu-west-2
    runtime: provided
    stage: dev
    environment:
        APP_ENV: prod
plugins:
    - ./vendor/bref/bref

functions:
    website:
        handler: public/index.php
        timeout: 28
        layers:
            - ${bref:layer.php-73-fpm}
        events:
            -   http: 'ANY /'
            -   http: 'ANY /{proxy+}'

    console:
        handler: bin/console
        timeout: 120
        layers:
            - ${bref:layer.php-73}
            - ${bref:layer.console}

Not too many change. I changed the name of the application in cloud-project (you can put whatever you want). I also add a stage that define the environment publish.
In environment we have the environment variables used by our functions.
I also create 2 functions:

website that is the same than the api function we had in the file. We only change the handler that now target the index.php of Symfony.
console used to run Symfony command

Symfony configuration

We will have to change some files in Symfony to make it work on a lambda.

System file is readonly except /tmp, we have to change where are stored cache and logs.
In src/Kernel.php, we need to add 2 methods:

// src/Kernel.php
...

public function getLogDir(): string
{
  if (getenv('LAMBDA_TASK_ROOT') !== false) {
    return '/tmp/log/';
  }

  return parent::getLogDir();
}

public function getCacheDir(): string
{
  if (getenv('LAMBDA_TASK_ROOT') !== false) {
    return '/tmp/cache/'.$this->environment;
  }

  return parent::getCacheDir();
}

We also need to change index.php.

Once deployed, the lambda that use API Gateway have a domain that is created and that end with th stage deployed (ex: https://lamnda/dev). It can create some issue with PHP framework. You can easily solve this by creating a custom domain that get ride of this suffix (more information](https://bref.sh/docs/environment/custom-domains.html)). But to keep this presentation accessible, we won't do it.
We have to change some servers variables so the Symfony routing wont break.

// public/index.php

$_SERVER['SCRIPT_NAME'] = '/dev/index.php';
if (strpos($_SERVER['REQUEST_URI'], '/dev') === false) {
    $_SERVER['REQUEST_URI'] = '/dev'.$_SERVER['REQUEST_URI'];
}

You need to put this line before new Kernel(...). /dev is the stage defined in serverless.yml. If you create your own application, you should really create your own domain. It can be a bit long (propagation of DNS) but otherwise it's quite simple.

We don't need anything else. Let's code a bit.

Building a homepage

We will create a simple landing page si we have something to deploy. But we will keep it simple:

Create a file HomeController in src/Controller

<?php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class HomeController extends AbstractController
{
    /**
     * @Route("/", name="home")
     */
    public function homeAction(): Response
    {
        return $this->render('home/index.html.twig');
    }
}

Create a file index.html.twig in templates/home

{% extends 'base.html.twig' %}

{% block body %}
    <h1>Symfony and lambdas</h1>
{% endblock %}

Yes, it's really simple but we don't really need anything else.

To see if it's working, type: php bin/console server:run and go to the url displayed. You should see your page.

Now, let's deploy it !

Deploy in the cloud

It might disappoint you, but you just need to run serverless deploy. The command will package your project, create the required resources on AWS. After few minutes, the endpoints of your function will be displayed. Use the first one, and you should see your site deployed !

You can see your CloudFormation on AWS here. You can also see the resources created by selecting Model then Display in Designer.

We now have a Symfony application running on AWS. Of course we are only at the beginning, but we will discover more in the next chapters.

In the next chapter we will talk about assets. Because without assets, there is no CSS or JS !