After publishing Part 2 of a series on JSON data in MySQL last week, a few folks reached out to me with some great feedback. Not only that, but they shared some resources I thought would be beneficial to pass on.
Morgan Tocker, the Product Manager that works on JSON support in MySQL pointed me toward the MySQL Server Team’s blog, which is more approachable than the docs for topical matters and directed discussion.
In last week’s post, Part 1 of 3, we took a look at the JSON data type support added in MySQL 5.7.8. This week, I wanted to look at some of the document-oriented patterns that MongoDB uses so we can see how we might accomplish the same in MySQL.
The goal is not to 100% replicate what Mongo does, but to see which patterns will make the best use of JSON support in MySQL, allowing us to get the best of an SQL store and a document-oriented one.
This is the first in a series of posts about the MySQL JSON data type, how it compares to working with a document-oriented store like MongoDB, and how we can make use of it in the Laravel framework.
Part 1 is a quick look at the data type itself, and some of the functions available to work with that data. Specifically, we’ll focus on what kind of data to store and how to work with it, regardless of framework.
It never fails. Just a few hours after I hit publish on my last post, the great folks behind Vue.js and the boilerplate templates, cranked out a new template aimed at beginners. You just use node to install the Vue cli (think Composer) and use it to pull in the template.
The result? A single page HTML file that pulls Vue in from a CDN and you are off and running.
(Update: The folks at Vue made an even easier startup template. I wrote a quick post about it here.)
Since Polymer went 1.0, I have built a couple small, personal projects with it. Those experiences have gone great, but some of the rigidity of Polymer’s elements and API continued to bug me.
Now I’m working on shipping my first public project in a while, and I’ve bumped into some challenges with Polymer.