Using CQRS in a simple Phoenix API with Commanded
Despite being a fan of event sourcing and seeing the clear benefits of the approach, I never built anything from scratch. This weekend, I finally decided to break this study cycle and do something practical.
Follow along with what I learned while implementing a project named todo_backend_commanded
.
Its git history reflects the process of migrating from a vanilla Phoenix API to an event sourced solution.
Firestore Backup and Restore
TL;DR
Check out FirestoreRestore. It uses a brand new API to backup and restore your Firestore database!
Background
There have been many requests for Google to add backup and restore functionality to their Cloud Firestore offering. Until this week, the only method for backing up a Firestore database has been to run utilities that traverse the tree as an admin client, saving each document’s JSON representation on disk.
Discovery
This morning, I opened the Google APIs Explorer and found two new methods listed under Firestore v1beta1
: exportDocuments
and importDocuments
.
Trying out ASP.NET Core 2.0
Why Bother with C#?
In my day job, I work with many APIs written in C#. Deployments involve running scripts that move DLLs to Windows servers running IIS. These servers have a large footprint and take a long time to initially provision. I think that the agility provided by being able to dockerize ASP.NET APIs could improve resource utilization, deployment times, and the ability to rapidly scale horizontally.
Since .NET Standard 2.0 and ASP.NET Core 2.0 were recently released, I decided to write a simple API using ASP.NET Core 2.0 and see if the dream of developing and deploying C# outside of Windows is finally a reality.
Example Project: Todo-Backend
Try it live here! Code available here.
The TodoMVC project exists to showcase front end technologies. It is a simple todo list application, typically using storage within the browser.
Kubernetes Autoscaling with Custom Metrics
Background
One of the most amazing things about Kubernetes is its ability to automatically scale up and down.
In current (autoscaling/v1
) releases, the only metric which could be used as a scaling target is CPU usage, as measured by heapster.
With the introduction of the custom metrics api, deployments will be able to scale using one or more application-specific metrics, as well as CPU.