The Laravel News site has a new post today describing a feature of the upcoming Laravel 5.4 release: the ability to define language files with JSON formatted files.

One of the most wanted requests we receive at Laravel is introducing better support for multilingual web applications, there are already packages out there that add some nice functionality to Laravel for better handling of multilingual projects requirements, but one of the painful issues when building such applications is managing translation keys.

Previously the trans/trans_choice helper to reference the value defined in the PHP array from your language files by a key name. With this new functionality, a new __() helper method is defined that will look through the English translation file, locate the correct key and find the matching record in the requested language to return. They also show how to pass in some parameters into the translator and how to use it directly from Blade.

For the Slim framework users out there Rob Allen has a quick new post to his site showing an easy way to handle JSON data errors in a Slim 3 application (besides just a silent failure).

When you send JSON data into a Slim Framework application with a content-type of application/json, then Slim will decode it for you if you use getParsedBody(). [...] If there's an error however, you get [an empty response]. If you care about this, you can use json_last_error_msg() and return an error.

He includes a code example of using this function on an endpoint, providing more information on why the JSON parsing failed. He also includes a "bonus" that makes use of the jsonlint library to inspect the JSON message and provide back a more human-readable message letting the user know what exactly was wrong with the JSON they provided.

Johannes Schlüter has written up an article covering an interesting feature of the latest MySQL server release related to its JSON column handling: JSON Aggregation functions.

[The JSON datatype, functions and generated columns] combined allow building very powerful applications without committing to a fixed data structure on every part, but I was missing one thing a lot: Aggregation.

A topic I'm thinking a lot about is finding ways to select nested data. In MySQL we typically have two ways for this. Either one sends multiple queries to retrieve different nesting levels or one builds JOINs which tend to deliver repetitive responses.

He points out that one solution is the GROUP_CONCAT function, but the results of this can be difficult to work with and larger data may override the small memory space allowed. Instead he introduces two new functions in v8 to help with this nested data selection: JSON_ARRAYAGG and JSON_OBJECTAGG. He provides a brief example of the use of these two functions together to replace the "concat" handling from before.

My (love-)story with Docker started in December 2013, after having lost a 2 years long battle against Chef. I had been attracted to Docker for a couple of months, and I finally made the switch the day when I learned that it was built on a REST API. This meant that I could control all my infrastructure from PHP, which is the language I’m most partial to.

After some research, I found the library docker-php built by ubermuda, but, like all the things around Docker at that time, there was only a very limited support of the API. Like any decent developer (yes, it’s a troll), I started to write pull requests to fulfill my needs, and it was both the greatest and the worst thing that happened to me.

The post starts off with a brief history of PHP libraries working with HTTP requests (and the difficulties he had with Guzzle). This includes the fast pace that the library was changing at the time, making it difficult to keep the code maintained. He took a "step back" and decided to look more into HTTPlug and some changes to help bring it up to date. With that choice made, he got into the automation portion and using it work with the Docker API. He talks about some of the other technologies and tools he investigated along the way including Jane for working with JSON message schemas.

Maintaining an open source library is hard and takes time. However, these last years made me realize that we can control it, by moving features into other projects, trust people behind it, and by reducing the feature sets.

In a post to his site Alejandro Celaya shares a method he worked up for creating a content-based error handler in Zend Expressive - a method of changing the error output based on the content it was passed and the Accept header provided.

In one of my tests of the REST API I saw that when an error occurs (404, 405 or 500), I was getting an HTML response, which is not easy to handle when the client is expecting JSON.

I started to dig on how to fix this problem and thought that using ErrorMiddleware (which is invoked in case of an error) should be the solution, but after some tests I saw that it is only invoked if a regular middleware invokes the next one by passing an error as the third argument or an uncaught exception is thrown. When a route is not matched (404) or it is matched with an incorrect HTTP method (405), the error middleware is not invoked.

After confirming (on Twitter) that this was the intended result he went about looking for another option. He looked into using "Final Handlers" that are called when nothing else matches in the middleware execution chain. They didn't provide one for JSON handling, however, so he had to create his own (code is included in the post) and explains a bit of how it's handling the data and HTTP response code. Unfortunately using this handler made the error output always return JSON so another piece was needed, the content-based detection handler that switches between types based on the Accept header.

In this new tutorialZsolt Szende talks about dependency injection and how to handle objects and related needs at runtime rather than the pre-configured method that some injection containers/systems have defined.

In this short article I would like to demonstrate a way to inject dependencies that are not known until runtime. There are many use cases for this and in essence it is about choosing between concrete implementations of some common interface. In object oriented design this is known at the Strategy pattern. The choice itself can be made in various ways, for example via a configuration option or a command line parameter in case of a console command, and I think the dynamic nature of the choice is the most interesting part of the pattern.

The article provides a practical example of an XML/JSON reader pulling information from an external source. A simple interface is defined and two implementation classes put it to use. Then the "command" pattern is used to apply it to an executable script and how injecting a reader type directly overrides the one from the provided option. This is taken a step further and refactored into a "resolver" to determine the best logic to apply based on the input argument.

The Symfony Finland site has a recent post giving an overview of GraphQL and Symfony, combing the GraphQL query language (RESTish handling) from Facebook with your application.

The origins of GraphQL stem from the needs that Facebook's mobile applications had (and continue to have). They needed a data-fetching API that was flexible enough to describe all the different kinds of data that the social network had available. [...] Back in September 2015 GraphQL was already powering Billions of API calls a day at Facebook. [...] The core idea of GraphQL is to send a simple string to the server. This string is then interpreted by the server and it sends back a JSON payload that responds to follows the structure of the query itself.

The post includes an example of what the request and response from a GraphQL query might look like for a social network's data. They also link to several PHP libraries that have come up around the functionality making it easier to integrate. There's also links to some Symfony bundles that provide functionality to make your own GraphQL servers.

The Paragon Initiative site has a new tutorial posted aiming to help you more securely use the serialize and unserialize handling in PHP to prevent security issues. In this tutorial they offer some advice - mainly don't unserialize unless you're on PHP7 - and some other solutions you could use.

A frequent problem that developers encounter when building web applications in PHP is, "How should I represent this data structure as a string?" Two common examples include:

This seems like the sort of problem that you could expect would have pre-existing, straightforward solutions built into every major programming language that aren't accompanied by significant security risk. Sadly, this isn't the case.

He starts with a look at the serialization handling and how it could allow remote code execution if an attacker were to modify the serialized data. He includes an example of using the new "allowed classes" parameter in PHP 7 too, though, preventing the issue. He also walks through two other ways you could replace serialized data: JSON structure and XML handling. Each of these have their own issues too but they're very different than the code execution with serialization.

In a post to his site Ewan Valentine looks at some considerations to think about when creating a domain specific language in your applications. This kind of language helps define common terms, conventions and practices for developers to follow in their code.

When you spin up a framework such as Laravel, Symfony etc. The first thing you'll notice, is that they have their own 'feel'. I often joke that Symfony2 is like Java and Laravel is like Ruby.

But what gives an application or a framework a 'feel'? Domain specific language or 'DSL'. Domain specific language is almost like a syntax or a language specific to your application and ecosystem. DSL is what makes your applications code unique and more usable.

He gives a specific example of a Laravel application he was creating and how he wanted the interface to function, transforming the result of a find() into a JSON response. He shows how it could actually be done but that introduces more maintenance and more code to cover. Instead he worked backwards into the domain context the request was operating in and found an ideal injection point for transformation that would keep it out of the controller action itself.

So, to design usable domain specific syntax, start at the front. In other words the part you'll be writing the most, and then work backwards to abstract the logic and make it actually work.

Rob Allen has a quick post to his site talking about some of the improved error handling that's been updated in the latest version of the Slim microframework to help make reporting issues easier in multiple contexts.

From RC1 of Slim 3, we have improved our error handling. We've always had error handling for HTML so that when an exception occurs, you get a nice error page [...] However, if you're writing an API that sends and expects JSON, then it still sends back HTML. [...] At least we set the right Content-Type and status code! However, this isn't really good enough. We should send back JSON if the client has asked for JSON. Until RC1, the only way to do this was to register your own error handler.

With Slim 3 the framework handles things more correctly based on the value of the "Accept" header sent along with the request. This value is checked and, if it references JSON or XML, the error message is translated either giving the default output or reporting back for the "notFound" and "notAllowed" error types.