DEV Community: Diogo Kollross

Dynamically required fields in Joi

Diogo Kollross — Thu, 26 Jan 2023 01:12:47 +0000

Introduction

Joi is a popular JavaScript validation library. Its fluent and compact interface makes it easy to describe large, complex, validation schemas. Here's a small example:

import Joi from 'joi';

const schema = Joi.object({
  user: Joi.string().required(),
  pass: Joi.string().required(),
  address: Joi.object({
    street: Joi.string(),
    number: Joi.number(),
  }),
});

const result1 = schema.validate({ user: 'joe', pass: '123' });
// { value: { user: 'joe', pass: '123' } }

const result2 = schema.validate({ user: 'joe', pass: false });
// { error: ValidationError('"user" is required') }

The Problem

Joi has support for conditionally changing parts of the schema based on (for example) the value or presence of some of the other object fields using the when method.

The following example requires pass only when user is present in the object:

const schema = Joi.object({
  user: Joi.string(),
  pass: Joi.string().when('user', {
    is: Joi.exist(), then: Joi.required()
  }),
});

const result1 = schema.validate({});
// { value: {} }

const result2 = schema.validate({ user: 'joe' });
// { error: ValidationError('"pass" is required') }

But what if you want to change some field validation rules based on a condition external to the validated data? You could duplicate the schema and only change whatever is different in each case.

In this example, fields such as pass and address.street are only required when validating the payload of version 2 of our API (because they were optional in version 1):

if (apiVersion === 2) {
  schema = Joi.object({
    user: Joi.string().required(),
    pass: Joi.string().required(),
    address: Joi.object({
      street: Joi.string().required(),
      number: Joi.number(),
    }).required(),
  });
} else {
  schema = Joi.object({
    user: Joi.string().required(),
    pass: Joi.string(),
    address: Joi.object({
      street: Joi.string(),
      number: Joi.number(),
    }),
  });
};

This works for small schemas, but it can get wild when working with huge objects wit differences scattered along several nested fields.

The Solution

I was almost giving up when I found the fork method. It creates a modified schema by running a custom callback over the schema fields you specify.

The following example is just like the previous one, but uses the fork method to modify the schema:

schema = Joi.object({
  user: Joi.string().required(),
  pass: Joi.string(),
  address: Joi.object({
    street: Joi.string(),
    number: Joi.number(),
  }),
});

if (apiVersion === 2) {
  const makeRequired = (x) => x.required();

  schema = schema.fork(
    ['pass', 'address', 'address.street'],
    makeRequired
  );
}

I'm no specialist in Joi, but hope that this helps you. Drop a comment if you know a different way to handle this use case!

Fixing CloudFormation SSM parameter drift

Diogo Kollross — Fri, 19 Aug 2022 14:35:41 +0000

Edit: I've created a small shell script that downloads the original template and creates a new local template file that you can upload directly to the CloudFormation console.

Introduction

AWS CloudFormation is a tool that helps provisioning infrastructure and deploying resources to Amazon Web Services. It's common to use AWS SAM (Serverless Application Model), a tool that builds upon CloudFormation to ease development of serverless applications and describe their resources.

SAM uses a template file, encoded in either YAML or JSON. It contains the definitions of the Lambda functions, what triggers them, DynamoDB tables, API gateways, and any other AWS resource needed by the application stack. When deploying the app, SAM compares what is already present in the cloud with the content of the template: if there are any differences, it creates a changeset and apply the required changes to the resources.

SSM Parameter drift

Introduction to SSM Parameters

AWS Systems Manager provides features to visualize and manage applications and other AWS resources. One of these features is the Parameter Store: a way to define custom application parameters that can be referenced from the SAM template (and then consumed by the Lambda functions as operating system environment variables).

It's easy to define and modify SSM parameters. When accessing the AWS Console, open Systems Manager and then Parameter Store under Application Manager.

From this page you can add, modify, and delete parameters freely.

After defining the parameters, one can refer to them in the SAM template.

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  ChangeClientPassword:
    Type: AWS::Serverless::Function 
    Properties:
      Handler: src/ChangeClientPassword.handler
      Environment:
        Variables:
          SENDGRID_API_KEY: '{{resolve:ssm:/app2/sendgrid/api-key}}'
          SENDGRID_API_SECRET: '{{resolve:ssm:/app2/sendgrid/api-secret}}'
      ...

During stack deployment, SAM gets the current SSM parameter values and injects them in each Lambda that uses them.

How to break the stack

There's a very innocent operation that can "break" an application stack: deleting and recreating a SSM parameter that is being used by a deployed application.

If you do that and try to sam deploy again, it will fail to create the changeset:

Error: Failed to create changeset for the stack: 
app2, ex: Waiter ChangeSetCreateComplete failed: 
Waiter encountered a terminal failure state: For 
expression "Status" we matched expected path: 
"FAILED" Status: FAILED. Reason: Parameters: 
[ssm:/app2/sendgrid/api-key:1:1638185826080] 
last modified date does not match with the last 
modified date of the retrieved parameters.

This happens because, after a successful deployment, CloudFormation saves the processed template so it can be compared to new templates by tools like SAM. The processed template is just like the original one, but it has some external references replaced. One of these references are SSM parameters.

Remember how was the original reference to the /app2/sendgrid/api-key SSM parameter?

SENDGRID_API_KEY: '{{resolve:ssm:/app2/sendgrid/api-key}}'

All SSM parameters are versioned and the last modification time is managed too. So, after deploying, CloudFormation stores this in the processed template:

SENDGRID_API_KEY: '{{resolve:ssm:/app2/sendgrid/api-key:1:1638185826080}}'

To create the changeset, SAM gets the version and timestamp of the parameter as saved in the processed template and searches for it in the parameter's change history. If it can't find it there, the changeset cannot be created.

Solution

1. Get the processed template

To workaround this, you'll have to update the timestamps of the affected SSM parameters in the template.

First, open the stack in CloudFormation console and view the Template tab. Click View in Designer.

Wait until the Designer loads fully and shows the template in JSON format in the bottom of the page. Copy the processed template entirely and save it to a file (you'll have to edit and upload it later).

2. Get the new parameter timestamp

Get the new timestamp for the parameter using AWS CLI, as you'll need a timestamp with milliseconds.

$ aws ssm get-parameter --name '/app2/sendgrid/api-key'
{
    "Parameter": {
        "Name": "/app2/sendgrid/api-key",
        "Type": "String",
        "Value": "****",
        "Version": 2,
        "LastModifiedDate": "2022-08-19T10:21:25.249000-03:00",
        "ARN": "arn:aws:ssm:us-east-1:523681489511:parameter/app2/sendgrid/api-key",
        "DataType": "text"
    }
}

The timestamp is LastModifiedDate. You'll need to convert it to a Unix timestamp with milliseconds. You can do it by pasting the date in https://time.lol/ and copying the appropriate formatted value.

3. Fix the timestamp in the template

Open the template and replace, in the affected parameter references, any outdated timestamps with the new one. Remember to also correct the version if needed.

 "Environment": {
   "Variables": {
-      "SENDGRID_API_KEY": "{{resolve:ssm:/app2/sendgrid/api-key:1:1638185826080}}"
+      "SENDGRID_API_KEY": "{{resolve:ssm:/app2/sendgrid/api-key:2:1660915285249}}"
   }
 }

4. Update the stack

Back to the CloudFormation console, close the Designer without saving any changes.

In your stack, click Update, choose "Replace current template", and "Upload a template file". Pick the new template file you've just corrected.

Finish the wizard by clicking Next until the last step, and finally click Update stack.

The stack will be updated (even though the changeset is empty).

You can check that now the processed template contains the latest version and timestamp of the parameter. The next time you deploy the application with SAM, everything should work fine.

Overriding Tailwind classes in React

Diogo Kollross — Wed, 18 May 2022 15:23:33 +0000

EDIT: A previous version of this article mentioned tailwind-override, but this package has been replaced with a more complete library that merges more Tailwind classes.

The problem

Imagine you create a simple React component that displays a pre-styled blue button using Tailwind CSS and allows adding more classes to customize it.



function Button({ label, className, ...props }) {
  const classes = `
    border
    border-black
    bg-blue-600
    p-4
    rounded-lg
    text-white
    text-xl
    ${className ?? ""}
  `;
  return <button className={classes}>{label}</button>;
}

You can use it as:



<Button label="Hello" />

Default blue button styling

And it works as advertised. Now you want to change its color to red:



<Button label="Hello" className="bg-red-600"/>

Customized red button... wait!?

What just happened? I added the new CSS class to className, so let's check if it's actually included in the rendered HTML:



<button class="
    border
    border-black
    bg-blue-600
    p-4
    rounded-lg
    text-white
    text-xl
    bg-red-600
  ">Hello</button>

It's right there at the end - bg-red-600, and it comes after bg-blue-600. A class should override anything that came before it, right?

Wrong.

The cause

It turns out that the space-separated CSS class list that the class HTML attribute accepts is not treated as a list when calculating CSS rules precedence by the browser. The class attribute actually contains the set of classes the element has, so the order doesn't matter.

This problem is not specific to Tailwind. It can happen with any two CSS classes that set the same CSS attributes. It can be as simple as:



<!DOCTYPE html>
<html>
  <head>
    <style>
      .red {
        color: red;
      }

      .blue {
        color: blue;
      }
    </style>
  </head>
  <body>
    <p class="blue red">Sample red text... not!</p>
  </body>
</html>

The .blue rule overrides the .red rule

As the order that the classes appear in the class attribute doesn't matter, the rule that comes later in the CSS stylesheets wins.

Coming back to Tailwind, this means that if, by coincidence, the Tailwind stylesheet file defines the .bg-blue-600 rule after the .bg-red-600, then bg-blue-600 will win every time.

The solution

Non-Tailwind

Sometimes it's possible to workaround this by changing your stylesheet and the specificity of the rules applied to the element. All of the following rules have higher priority than the original .red rule (and win over the original .blue rule):



p.red
.red.blue
#special
body .red

There's a neat specificity calculator that's worth checking.

Tailwind

Now the solution above won't work with Tailwind, as its very concept is to have utility classes that you can use without changing any stylesheets.

When you don't know what classes may appear after your own, you need a way to detect clashes and remove all but the last occurrence. This is exactly what the tailwind-merge npm package does.

You can use it like:



import { twMerge } from "tailwind-merge";

function Button({ label, className, ...props }) {
  const classes = twMerge(`
    border
    border-black
    bg-blue-600
    p-4
    rounded-lg
    text-white
    text-xl
    ${className ?? ""}
  `);
  return <button className={classes}>{label}</button>;
}

Button with the correct color

And we can verify that the rendered HTML does not contain bg-blue-600 anymore:



<button class=" border border-black p-4 rounded-lg text-white text-xl bg-red-600 ">Hello</button>

Conclusion

Due to the fact that the order of CSS class names in the class HTML attribute does not matter, the only way to override existing classes in an element is to remove all of the previous classes that clash with the new one.

What do you think? Did you face this issue before? Do you know a better way to override the Tailwind classes that come before the new ones?

Efficient file hashing in Elixir

Diogo Kollross — Tue, 16 Mar 2021 18:07:30 +0000

You can download the code from this article from GitHub

Elixir in itself does not have functions to calculate hashes of files or data, but as usual you can use Erlang modules to do that. The crypto module offers several cryptographic services, including many hashing algorithms.

Naive approach

The easiest option is the hash function. It takes an atom indicating one of the supported algorithms and the data to be hashed. When hashing a file, you need to call File.read! or similar to read the data before calling hash.

data = File.read!("sample.pdf")
sha256 = :crypto.hash(:sha256, data)

Streaming approach

The problem with using the hash function is that it only works if the whole file is present in the memory. When working with large files this can quickly degrade the performance of the application or even crash it.

An alternative is using the "streaming mode" of the hashing functions. Instead of feeding the data to the hashing function at once, you read the data in pieces and apply the hashing algorithm to each piece in sequence, updating its internal state until all data has been processed and the hashing algorithm has its final result. This is how these hashing algorithms actually work and this mode is available in other programming languages too.

Initialize hashing algorithm context
While there is more data:
    Feed the algorithm a piece of data
Get the final result from the hashing algorithm

In Elixir, this can be implemented using the File.stream! function and Enum.reduce.

initial_hash_state = :crypto.hash_init(:sha256)

sha256 =
  File.stream!("sample.pdf", [], 2048)
  |> Enum.reduce(initial_hash_state, &:crypto.hash_update(&2, &1))
  |> :crypto.hash_final()

The function hash_init creates a "hash state" object that is updated by the hashing algorithm as new data is processed. At this point, it's state is equivalent to hashing an empty file.

File.stream! produces an enumerable in which each item is a binary with length of up to 2048 bytes (in this example). This parameter can be tuned according to memory usage and performance requirements: larger buffers are faster but use more memory.

The enumerable returned by File.stream! is lazy and sometimes you need to explicitly execute it by calling Stream.run. Alternatively, most functions from the Enum module will trigger the execution of the file stream.

Inside Enum.reduce we call hash_update, passing the current hash state and the data to be processed. It returns the new state of the hasher, to be updated with the next item from the file stream or returned as the final result of the Enum.reduce call.

Having the hash state after processing the last data piece, we call hash_final to get the calculated digest as a binary.

Bonus: formatting the hash

The result of hashing algorithms is a sequence of bytes (16 for MD5, 20 for SHA1, 32 for SHA256, etc.), but usually we present them in hexadecimal format. To do that, use the Base.encode16 function.

formatted_sha256 = Base.encode16(sha256, case: :lower)

Random strings in Elixir

Diogo Kollross — Sat, 13 Mar 2021 23:12:01 +0000

Random integers

Elixir doesn't have a module to generate random integers, but it can call underlying Erlang modules such as rand (nowadays, preferred over random) or crypto and can select random items from enumerables. This gives us some options to generate integers inside a range.

To generate integers between 0 and 255 (inclusive):

n = :rand.uniform(256) - 1
n = :crypto.rand_uniform(0, 256)
n = Enum.random(0..255)

Note that :rand.uniform(n) returns integers so that 1 <= x <= n - that's why we decrement the result. Also, the documentation for Enum.random states that it will efficiently "pick a random value between the range limits, without traversing the whole range".

You can also use Enum.random with ranges or charlists to pick random code points from specific alphabets.

n = Enum.random(?a..?z)
n = Enum.random('0123456789abcdef')

Random strings

The next step is to use these building blocks to create a binary from a number of random code points using comprehensions:

s = for _ <- 1..10, into: "", do: <<Enum.random('0123456789abcdef')>>

Cryptographically secure strings

Sometimes there's a need for a cryptographically secure generator to create, for example, random passwords or authentication tokens.

If you simply need a sequence of random bytes, you can use strong_random_bytes from Erlang's crypto module. It's also much faster than looping in Elixir using comprehensions.

s = :crypto.strong_rand_bytes(10)

If you need to use a specific alphabet, you can combine :crypto.rand_uniform with Enum.at:

symbols = '0123456789abcdef'
symbol_count = Enum.count(symbols)
s = for _ <- 1..10, into: "", do: <<Enum.at(symbols, :crypto.rand_uniform(0, symbol_count))>>

Benchmark

I've benchmarked these options using Benchee.

random_length = 10_000
Benchee.run(%{
  "Enum.random comprehension" => fn ->
    for _ <- 1..random_length, into: "", do: <<Enum.random(0..255)>>
  end,
  ":rand.uniform comprehension" => fn ->
    for _ <- 1..random_length, into: "", do: <<:rand.uniform(256) - 1>>
  end,
  ":crypto.rand_uniform comprehension" => fn ->
    for _ <- 1..random_length, into: "", do: <<:crypto.rand_uniform(0, 256)>>
  end,
  ":crypto.strong_rand_bytes" => fn ->
    :crypto.strong_rand_bytes(random_length)
  end,
})

Which yielded these results:

Name                                         ips        average  deviation         median         99th %
:crypto.strong_rand_bytes               73695.16      0.0136 ms    ±34.33%      0.0130 ms      0.0239 ms
:rand.uniform comprehension               488.88        2.05 ms    ±10.39%        1.99 ms        2.62 ms
Enum.random comprehension                 284.56        3.51 ms     ±8.22%        3.53 ms        4.33 ms
:crypto.rand_uniform comprehension         44.04       22.71 ms     ±2.16%       22.64 ms       24.54 ms

Comparison: 
:crypto.strong_rand_bytes               73695.16
:rand.uniform comprehension               488.88 - 150.74x slower +2.03 ms
Enum.random comprehension                 284.56 - 258.98x slower +3.50 ms
:crypto.rand_uniform comprehension         44.04 - 1673.55x slower +22.70 ms

Summary

Based on the benchmarks and thinking about readability, this is what I would use depending on what I need to generate:

Binary strings: :crypto.strong_rand_bytes
Any other symbol alphabet: Enum.random
Passwords/tokens: :crypto.rand_uniform
Fast: :rand.uniform

Laravel tests naming rules

Diogo Kollross — Thu, 07 Jan 2021 02:47:39 +0000

There is one important information about Laravel testing that may not be obvious when reading the official documentation: the names of test classes and test methods must follow some simple rules stated below.

Test classes must end with the suffix Test
Test methods must start with the prefix test

This detail has bitten me more than once in the past. You copy and paste ExampleTest.php to create, say, ExampleTest2.php and the artisan command insists in ignoring your otherwise perfect test class!

The explanation is simple: under the hood, php artisan test and php artisan dusk use PHPUnit to run the tests, so default PHPUnit's rules apply. That's why you can also use test annotations if you really want to avoid prefixing your test methods with test:

/**
 * @test
 */
public function sendsConfirmationEmail()
{
    ...
}

Why we need frameworks (for now)

Diogo Kollross — Mon, 30 Mar 2020 01:47:50 +0000

Some time ago, my colleagues and I had a discussion about the usefulness of JavaScript frameworks given the current state of web browsers and their support for modern HTML5 standards.

The first article that sparkled that debate was The deepest reason why modern JavaScript frameworks exist, by Alberto Gimeno. In his article, he claims that JavaScript frameworks are needed to synchronize the user interface state and the visual components of the user interface.

I thought that this argument didn't stand anymore, because web components would meet that demand with support for bindings or something similar. Unfortunately, I was wrong: web components can do many things, but synchronizing state and UI is not one of them.

The second article was Do we still need JavaScript frameworks?, by Luke Joliat. In it, he develops a simple application using vanilla JavaScript only. He demonstrates that you actually can refrain from using frameworks up to some "tipping point". That point would be the application' size/complexity: there is a time when, no matter how much you try, the need for code reuse forces you to use a framework. Either you use an existing framework, or you end writing your own homemade framework, focused on solving your specific problem (which is not necessarily bad, as that's how many successful frameworks came to be).

It's here that both articles kinda agree (I and agree with them): whenever you go beyond trivial, you need some structure that helps to abstract the solution that you are creating for the problem you're solving. Programming languages by themselves give some structure, but that's not enough. It's been quite some years that programming languages don't come bundled with heavier frameworks that allow for more complex applications to be developed. I believe that's deliberate: even though there are patterns that can be found in many frameworks from many languages, the users of these languages like the freedom to tinker with different abstractions.

That is different from "older fashioned" technologies like Visual Basic, Delphi, JSP, and Classic ASP. All of them have in common the provision of a native framework that can be used for structuring applications. Coincidence or not, the frameworks all these technologies offer are based on two pillars: components and event-oriented programming – essentially the same features that the most famous JavaScript frameworks provide. The main difference is that in older technologies there was no separation between state and UI: the UI IS the state. It's like keeping all information about the user interface' state in the DOM, using only classes, attributes, and properties. Anyone that has already used these older technologies to build complex user interfaces knows that this way of doing things has a limit, and soon you're creating all sorts of flags and ancillary variables trying to put some order to this big mess.

The important innovation of the last years is explicitly separating these two concepts: the user interface's logic state, which is (somewhat) independent of the way it's presented and the specific components you use; and the user interface itself (eg: the components or HTML tags). When you split these two concepts you create (or expose?) the need for state-UI synchronization, because the user interface has its own internal state (controlled, for example, by the operating system or the web browser).

This separation is not new. It exists since at least the 1980s when the MVC pattern was adopted by Smalltalk. The novelty is that separation becoming mainstream (which is something good). Having the user interface logic isolated in a class without concrete UI dependencies makes testing easier (especially unit tests) and forces the developer to think about the user interface more abstractly.

For me, the definition of "framework", what differentiates it from a "library", is inversion of control (IoC). Instead of your code calling some external code, it's the external code that calls your code. The base of the application' structure is not your own code, but the code of the framework. You're given extension points and slots where you put your code, and the framework calls your classes and functions as the user interacts with your application. That allows us to "shift up a gear", to abstract more of the implementation because it hides questions that permeate the application as a whole: access control, sessions, database connections, logging, debugging, profiling, templates and user interface rendering, uploads, forms, validation, etc.

As someone that has used many frameworks, has created more than one framework and has tried to develop without frameworks, I can say that frameworks are really necessary. My experience building "small customer registries" that in time turned to be "little monsters" is exactly that: code reuse through functions and classes, then libraries with more abstract components, then finally inversion of control – in other words, a framework. Even when I tried to get develop with no framework, I ended building a micro-framework because the programming language by itself didn't provide the abstraction level I needed.

There's a saying in some not-so-mainstream programming languages circles stating that "design patterns (eg: Facade, Singleton, Observer) are only required when the language is not rich enough to describe these behaviors natively". I never found a language, be it object-oriented, functional, logic, concatenative or of any other kind, that allowed one to dismiss each and every pattern.

Maybe it's impossible to create a programming language that natively offers all features needed to discard design patterns and frameworks. Or maybe that's the next step: a language that offers, natively, inversion of control. I'm not sure how that would work (maybe something similar to AOP - aspect-oriented programming), but I think it's something to consider: the language would be indistinguishable from the framework.

What do you think?

File upload using Laravel and Vue.js (The Right Way)

Diogo Kollross — Sun, 08 Mar 2020 14:09:20 +0000

Ways to upload a file

Most articles showing how to upload a file using JavaScript actually teach how to encode the file contents in Base64 so it can be included in the JSON request. It works, but it's not as efficient as other methods. In this post I'll show how to upload a file using the multipart/FormData method using Vue.js together with axios.

Base64 inside JSON

Advantages:

No need to manually encode/decode your data in JSON (if using any frontend framework or client library)
File's content is just another field in the JSON object

Disadvantages:

Need to encode the file in Base64
Uses more CPU, more memory, and more network bandwidth (Base64 uses 33% more space than binary)
Little support from backend frameworks

Multipart

Advantages:

No need to encode the file in Base64
Uses less CPU, less memory, and less network bandwidth
Full support from backend frameworks

Disadvantages:

Need to manually encode/decode your data in JSON
File's content is separate from the JSON object

Getting the file

In one way or another, your page will have a file input element that lets the user choose a file. Vue will complain if you try to use v-model on it because file inputs are readonly, so we usually add an event handler for the change event.

<template>
    <input type="file" @change="selectFile">
</template>

<script>
    data: () => ({
        photo: null,
        description: '',
        productId: 0,
    }),

    methods: {
        selectFile(event) {
            // `files` is always an array because the file input may be in multiple mode
            this.photo = event.target.files[0];
        }
    }
</script>

Sending the file

File input elements have a files property that is an array of instances of the File class. It has some metadata about the selected file and methods to read its contents. Besides that, it can be used directly as a value in a FormData object. The FormData class allows one to use JavaScript to build the same request that a plain HTML form would create. You can use a FormData object as the request's body when using axios, jQuery or even plain XMLHttpRequest objects.

The following:

const data = new FormData();
data.append('photo', this.photo);
data.append('description', this.description);
data.append('productId', this.productId);
axios.post("/api/photo", data);

Is roughly the same as:

<form method="POST" enctype="multipart/form-data" action="/api/photo">
    <input type="file" name="photo"/>
    <input type="text" name="description"/>
    <input type="text" name="productId">
</form>

If you have complex data as arrays or nested objects, you will have to convert them to JSON manually:

const data = new FormData();
data.append('photo', this.photo);
const json = JSON.stringify({
    description: this.description,
    productId: this.productId,
});
data.append('data', json);
axios.post("/api/photo", data);

Receiving the file

At the Laravel side, there is full support to handle file uploads transparently using the Request class. Uploaded files are fields like any other, presented by the framework as instances of the Illuminate\Http\UploadedFile class. From there on you can read the file's contents or store it somewhere else.

public function savePhoto(Request $request)
{
    // Validate (size is in KB)
    $request->validate([
        'photo' => 'required|file|image|size:1024|dimensions:max_width=500,max_height=500',
    ]);

    // Read file contents...
    $contents = file_get_contents($request->photo->path());

    // ...or just move it somewhere else (eg: local `storage` directory or S3)
    $newPath = $request->photo->store('photos', 's3');
}

If you had complex data that you manually converted to JSON, you need to decode it before use:

public function savePhoto(Request $request)
{
    $request['data'] = json_decode($request['data']);

    // Validate
    $request->validate([
        'data.description' => 'required|filled|size:100',
        'data.productId' => 'required|int|exists:App\Product,id'
    ]);

    // ...the rest is the same...
}

DEV Community: Diogo Kollross

Dynamically required fields in Joi

Introduction

The Problem

The Solution

Fixing CloudFormation SSM parameter drift

Introduction

SSM Parameter drift

Introduction to SSM Parameters

How to break the stack

Solution

1. Get the processed template

2. Get the new parameter timestamp

3. Fix the timestamp in the template

4. Update the stack

Overriding Tailwind classes in React

The problem

The cause

The solution

Non-Tailwind

Tailwind

Conclusion

Efficient file hashing in Elixir

Naive approach

Streaming approach

Bonus: formatting the hash

Random strings in Elixir

Random integers

Random strings

Cryptographically secure strings

Benchmark

Summary

Laravel tests naming rules

Why we need frameworks (for now)

File upload using Laravel and Vue.js (The Right Way)

Ways to upload a file

Base64 inside JSON

Multipart

Getting the file

Sending the file

Receiving the file

References