March 2022 Summaries

The Go 1.18 generics implementation uses a partial monomorphization technique called "GCShape stenciling with Dictionaries." This approach reduces the amount of unique function shapes by monomorphizing at a broader level than the type of the arguments, specifically based on the GCShape of the arguments, not their type. However, this approach does not allow for de-virtualization or inlining, as the associated method information lives in a runtime dictionary. The implementation introduces an interface call with two layers of indirection, which can lead to performance overhead, especially when dealing with interfaces. In some cases, such as parametrizing functional helpers by their callback types, the Go compiler can flatten the code using monomorphization. Nevertheless, the current implementation has limitations and imposes a performance tax in terms of compilation times. The choice of using runtime dictionaries may be re-evaluated to introduce more aggressive monomorphization in future Go releases.

When building PlanetScale's API, the team needed a unique identifier that wouldn't reveal record counts in tables, avoiding the use of integer IDs. They considered using UUIDs but found they took up too much space in URLs. To address this, they developed NanoIDs, which are shorter than UUIDs, easy to select with double-clicking, and have a low chance of collisions. The team used 12-character long IDs with a specific alphabet, resulting in a 1% probability of collision over ~35 years if generating 1000 IDs per hour. To generate NanoIDs, they added a public_id column to their database schema for public-facing models and built a concern that could be shared across all models to auto-generate IDs. The same approach was applied in their Go backend service, using a package called go-nanoid/v2 to generate unique public IDs. By solving this detail, PlanetScale aimed to create a great developer experience.

PlanetScale has introduced a new schema revert feature that allows users to revert database schema changes with zero downtime and no data loss. This feature is made possible by VReplication in Vitess, a database clustering and management system used by PlanetScale databases alongside MySQL. With this feature, users can make changes to their database schema without fear of downtime or data loss, treating their database like they treat their code. The feature enables developers to revert schema changes with the press of a button, taking just seconds to restore previous schema states.

The new feature allows for instant reverting of recently deployed schema changes without losing data written to the original schema during the deployment period. This is made possible by leveraging Vitess' VReplication internals, which tracks progress and incoming changes with exact precision using MySQL GTID (Global Transaction Identifier). The process involves creating a shadow table, applying the schema change, syncing data, and then switching back to copying from the production database. Once the data is copied over, the original table is swapped away and replaced by the shadow table, allowing for seamless revert without downtime or data loss.

SQL injection attacks occur when malicious users inject their own SQL code into database queries, potentially leading to data breaches and other security issues. To prevent these attacks, developers can use placeholders in query strings instead of variable interpolation, validate user input to ensure it conforms to expected formats, allowlisting specific valid inputs, and avoid allowing multiple statements. By taking these steps, developers can protect their applications against SQL injection attacks and maintain the integrity and security of their databases.

A relational database is designed to store structured data that models real-life entities, with relationships between tables pre-defined at the time of creation. To design an efficient database, one must first understand the business needs and identify the entities, properties, and relationships between them. The schema, which defines the structure of the data, has a significant impact on performance and should be designed carefully to avoid future headaches. Key steps include defining primary keys, foreign keys, and indexing to ensure quick look-ups, and using tools like ERDs (entity-relationship diagrams) to visualize the entities and their relationships. With proper planning and design, relational databases can provide a robust and scalable solution for storing and managing data.