Skip to main content

3 posts tagged with "php"

View All Tags

Introducing Bytey - A Google Polyline Encoding library

· 4 min read
Connor Tumbleson
Director of Engineering

One day we saw an interesting crash that one of our applications was generating a URL so long that Google's static map generation refused to generate it. With a bit of research we discovered lodged in the official documentation that there was a known limit.

note

Maps Static API URLs are restricted to 16384 characters in size. In practice, you will probably not have need for URLs longer than this, unless you produce complicated maps with a high number of markers and paths.

This led us to discovering that Google had the Encoded Polyline Algorithm Format designed to help pack information in the URL into a dense binary format in plain ASCII text in order to reduce characters. This blog is our journey to writing a little package to accomplish this in PHP.

Enhanced Resources for Laravel

· 3 min read
Connor Tumbleson
Director of Engineering
Jason Jones
Senior Software Engineer II, Lead

Developing an API was a common task for engineers working with Laravel in the early days of the framework. Prior to version 5.5 Laravel did not offer an elegant way to format/prepare API responses. Historically, it worked by calling toArray() on your model instance.

This pattern of calling toArray() risked the possibility of exposing attributes that should not be exposed over an API. As a result, it was common to use the $hidden property to exclude the specified attributes during serialization which was helpful in building an API response as both a mechanism to avoid exposing sensitive data and more generally controlling which data would be included. The example shown below was a common pattern prior to Laravel 5.5.

<?php

class User extends Eloquent {
protected $hidden = ['password', 'remember_token'];
}

// Usage
$user = User::find(1);
$user->toArray();
// Returns: ['name' => 'John', 'email' => 'john@example.com']

This approach was flexible, but any change to your database schema resulted in those changes appearing in your API. We needed something more concrete and landed on Fractal which served us well until Laravel added official support for API Resources, and thus we worked on an enhancement for that feature.

Rule Helper for Laravel

· 2 min read
Connor Tumbleson
Director of Engineering
Erik Perri
Senior Software Engineer II

As our applications moved from Laravel 4 into the future versions we noticed an issue that occasionally came up. Laravel validation rules in the early days of Laravel were primarily leveraged using string concatenation with pipe (|) characters.

$this->validate($request, [
'title' => 'required|unique:posts|max:255',
'body' => 'required',
]);

This added a bit of a mental overhead to know all the variations these rules offered and would require a fair amount of trips to the documentation to remember all the possible validation options. Additionally, if you made a typo on some of the rule names Laravel would just silently skip that rule during validation. If you didn't have great test coverage it was pretty easy to make a mistake with this style of validation writing.

We were in search of a more fluent approach to validation rules and as the release of Laravel 8 arrived we decided to create a package to solve our issue.