Laravel 9: Preparem-se!

Está em desenvolvimento há um ano e, no dia 8 de fevereiro, finalmente foi lançado: o Laravel 9 chegou! Neste artigo, vamos abordar alguns novos recursos, mas, em vez de uma “lista de itens”, vou apresentar alguns comentários e contextualizar melhor as mudanças que chamaram minha atenção.

As Coisas Importantes

Não há grandes mudanças arquitetônicas nem alterações que possam suscitar preocupações quanto à compatibilidade com versões anteriores (dito isso, esta é uma versão importante e, portanto, contém alterações que quebram a compatibilidade, de acordo com semver). Há, no entanto, algumas mudanças significativas fora do código. Vamos analisá-las:

Ciclo de lançamento

Uma das maiores mudanças recentes no Laravel foi o anúncio de Taylor Otwell de que eles estavam mudando para um ciclo de lançamento anual. Isso faz sentido, já que permite que a equipe principal tenha mais tempo para verificar as atualizações das dependências, seja no ecossistema do Symfony, seja nas dependências criadas pela comunidade. Falando em Symfony:

Symfony Mailer

O Symfony Mailer substituiu o Swift Mailer. Falando em Symfony, tive uma conversa muito interessante com o pessoal da SensioLabs durante o PHPUK sobre as interações entre o Laravel e o Symfony. Alguns desenvolvedores podem gostar de se considerar embaixadores de uma ou de outra marca e achar que “tomar partido” é a norma, mas, como fica claro ao observar o artisan cli, o Symfony Mailer e outros componentes do Laravel, fica claro que as duas estruturas trabalham juntas muito mais do que as pessoas que tentam criar divisões possam imaginar. Vale lembrar que tanto Fabien Potencier e Taylor Otwell contribuem com código para as organizações um do outro, e que o ecossistema PHP como um todo tem relevância e direção modernas justamente por causa disso.

PHP 8

Lembro-me de ter assistido Jenny Wong , da Human Made, dar uma palestra sobre segurança no WordPress e como a implementação do Jetpack foi uma ferramenta essencial para o ecossistema do WordPress, embora com taxas de adoção muito baixas. Uma das maiores vulnerabilidades do PHP é a relutância dos desenvolvedores em atualizar suas versões do PHP. Mais de 50% da comunidade do WordPress, naquela época, estava executando software em versões do PHP que nem sequer eram mais suportadas.

Portanto, é um grande incentivo ver que o Laravel está atualizando as versões obrigatórias do PHP de acordo com o ciclo de vida do PHP principal. Isso dá acesso a um conjunto totalmente novo de recursos de API, mas, mais importante ainda, a exigência de uma versão mínima do PHP 8 significa que você passa a ter o compilador de tempo de execução Just-In-Time (JIT), e, assim, o Laravel se beneficia de um aumento significativo no desempenho.

Com um novo requisito mínimo, você pode se deparar com problemas na sua pilha de servidores. Se isso for um grande incômodo por você já ter aplicações implantadas, recomendo fortemente o uso do Laravel Shift para migrar automaticamente seus projetos.

Flysystem

Uma das -melhores- funcionalidades, para um desenvolvedor que está começando a trabalhar com o Laravel, foi a forma como a Storage facade integrava o Flysystem, de Frank De Jong. A capacidade de mudar o driver do sistema de arquivos do local para um bucket do AWS S3 simplesmente trocando os drivers:

Storage::disk('local')->put('something.jpg', 'Images'); Storage::disk('s3')->put('something.jpg', 'Images');

O Flysystem 3.0.0 foi lançado no dia 14 de janeiro e inclui atualizações de versão em conformidade com os requisitos mínimos do Laravel para o PHP 8 (especificamente para o Flysystem 8.0.2), além de aprimoramentos na API relacionados à navegação em diretórios, tais como FilesystemReader::directoryExists('Storage\Images')

O Laravel 9 agora usa o Flysystem 3.

As Coisas Menores

São ajustes e acréscimos um pouco menores, mas que, mesmo assim, resultam em um excelente conjunto de novos recursos.

Agrupamento de controladores de rota

Admito que sou muito exigente quando se trata de organizar rotas em aplicativos web. Acho que isso vem da experiência de ver arquivos de rotas enormes, com mais de mil entradas e pouca estrutura na forma como estão ordenadas. A maneira como gosto de abordar o roteamento é usar estruturas de diretórios para controladores individuais, carregados pelo provedor de serviços de rotas.

Eu já defino rotas como grupos nomeados, mas a diferença aqui é que o closure permite vincular um grupo a um controlador específico. Isso não fará diferença se você adotar a abordagem de controladores invocáveis (muito mais arquivos, mas potencialmente com acoplamento mais fraco), mas se você tiver algo como uma API REST que realiza operações CRUD padrão, por exemplo — isso fica ótimo no código. Veja, por exemplo, este controlador:

Class ReportController extends Controller
{
	public function index(){}
	public function store(){}
	public function delete(){}
	public function show(){}
}

Agora, com o agrupamento de controladores, você pode incluir os métodos dos controladores no arquivo de rotas:

Route::controller(ReportController::class)->group(function () {
	Route::get('/reports', 'index');
	Route::post('/reports', 'store');
	Route::delete('/reports/{id}', 'delete');
	Route::get('/reports/{id}', 'show')
}

Saída da CLI da Lista de Rotas

Por falar em rotas, a saída de routes:list foi alterada, passando a apresentar uma visualização muito mais amigável para desenvolvedores:

Restrições de escopo forçadas

Essa é uma pequena mudança interessante que organiza as relações entre modelos na vinculação de rotas de forma muito mais clara. Anteriormente, era possível realizar uma vinculação de escopo forçada adicionando uma chave personalizada dentro de um registro filho:

Route::get('/users/{user}/reports/{report:id}', function (User $user, Report $report) {
	return $report;
})

Sem usar essa chave personalizada, nenhuma relação entre modelos seria aplicada, o que significava que, desde que o usuário e o relatório fossem chaves válidas, ela retornaria essa $report entidade de exemplo, mesmo que ela não tivesse uma relação (por exemplo, Model::hasOne(User::class))

Agora temos um método que permite implementar essa lógica de maneira muito mais explícita:

Route::get('/users/{user}/reports/{report}', function (User $user, Report $report) {
	return $report;
})->scopeBindings();

Enums

O PHP 8.1 foi lançado com a nova enums classe, que pode ser tratada como um objeto com valores de retorno chamados estaticamente ou pode ser uma “enumeração com suporte” que contém um valor. Vi Derek Rethans apresentar esse recurso no palco do PHPUK 2022, e devo dizer que, da nossa perspectiva na Vonage, ela pode se mostrar extremamente útil. Como lidamos com chamadas de Voice e mensagens, muitos desses recursos implementados no SDK do PHP possuem propriedades estáticas para definir e recuperar o estado (por exemplo, o status deste SMS é “0”). As enumerações têm o potencial de ter um tipo associado, em vez de uma extensa lista de propriedades estáticas.

Com a introdução das Enums, alguns recursos do Laravel 9 foram desenvolvidos para aproveitar essa novidade.

Conversão de atributos em enums

Já trabalhei em um projeto em que isso teria realmente, realmente poupado muitas dores de cabeça. Tudo em um banco de dados MySQL bastante grande derivava de uma classe base/tabela de banco de dados chamada “Event”, com as entidades derivadas restritas por enums do MySQL. Parece bom, né? Quando expandimos a plataforma, era preciso adicionar uma nova enumeração, o que acionava uma reindexação em uma tabela com várias centenas de milhões de registros. O sistema travava, todas as vezes.

Pense em como você escreveria uma migração para uma coluna de tabela do tipo enum:

$table->enum('eventType', ['SpotifyEvent', 'VideoEvent', 'AppleEvent'])

OK, então, toda vez que você adicionar uma nova enumeração, será necessário fazer uma nova migração, além de ter que atualizar o modelo.

No Laravel 9, você pode especificar uma classe enum em vez disso, mantendo a lógica no código do backend, em vez de no banco de dados. Embora isso seja uma desvantagem do ponto de vista do banco de dados, devido ao armazenamento ineficiente, torna o código, sem dúvida, mais legível. Assim, sua migração seria, em vez disso, uma coluna varchar:

$table->string('eventType')->default('SpotifyEvent');

E sua lógica ficaria dentro de uma classe de enumeração com suporte que é referenciada dentro da matriz Model $casts :

enum EventType: string {
	case SpotifyEvent = 'spotify';
	case VideoEvent = 'video';
	case AppleEvent = 'apple';
}

class EventEntry extends Model
{
	protected $casts = [
		'eventType' => EventType::class
	];
}

Isso vincula nossa conversão de tipos de e para o banco de dados: você pode testar isso com o tinker:

php artisan tinker

\App\Model\EventEntry::first()->eventType->value;

E o valor da sua string será retornado. eventType Na verdade, ele retornará um objeto enum, e é por isso que precisamos adicionar o value atributo para acessar a propriedade subjacente.

Ligação de rotas com enums

Você também pode usar classes de enumeração na vinculação de rotas. Digamos que você queira restringir a seguinte rota:

Route::get('events/eventType');

Agora você pode vincular a classe de enumeração, desta forma:

Route::get('/events/{eventType}', function (EventType $eventType) {
	return $eventType->value;
});

Cobertura de testes

Voltar a usar o Xdebug no meu conjunto de ferramentas de desenvolvimento do dia a dia foi uma espécie de revelação depois de anos usando die() e dd() depurar. Quando comecei a trabalhar no nosso SDK de PHP, percebi que nossa CI usa o CodeCov para garantir que os Pull Requests não possam ser mesclados sem cobertura suficiente no conjunto de testes. A cobertura é fornecida pelo Xdebug, então você precisa habilitar a cobertura no seu arquivo .ini primeiro:

xdebug.mode=develop,debug,coverage

Agora, se você executar artisan test --coverage, ele exibirá um relatório incluindo a cobertura do seu aplicativo:

Muito legal, né?

E o que vem a seguir?

Esta versão marca mais um marco na trajetória do Laravel, mas o que é realmente impressionante é o extenso ecossistema construído em torno dele — Vapor, Breeze, Octane, Sail, Horizon... e a lista continua. O que acho empolgante nessa lista cada vez maior de projetos do Laravel é sua inclusão na Fundação PHP, criada na sequência da a aposentadoria de Nikita Popov do desenvolvimento do núcleo do PHP. Ao lado do Symfony, fica bem claro que a frase imortal “PHP está morto” não poderia estar mais longe da verdade.