Ready your fork.
This idea has been marinating in my head for over a year, and I’d been stewing over how to present this topic without it being bland. (I almost wrote “breadfully bland”, but I thought batter of it.)
If you like mixed metaphors as much as mixed greens — and as little as you like mixed indentation—pull up a chair and feast your eyes on my method for preparing a gourmet pull request.
Health benefits of this preparation method include:
See Part I: Generating API Metadata to get caught up. This post uses the
User.json metadata generated using the steps described in that post.
The idea of using API metadata in the client code isn’t revolutionary. AutoRest uses OpenAPI schemas to generate code for a number of languages, and Django REST Framework’s docs suggest using metadata to jumpstart client libraries:
API schemas are a useful tool that allow for a range of use cases, including generating reference documentation, or driving dynamic client libraries that can interact with your API.
When refactoring code or doing test-driven development, a test runner that watches file changes and runs only failed tests can save a pile of time. (Like most people, I measure time in piles of hourglass sand.)
In a hurry? Skip to the Solution section to see the working command.
Say you’re working on a Python project that has 200 unit tests and uses pytest as its test runner.
I started working on Pipenv and Poetry: Benchmarks & Ergonomics at the begining of 2019, so it seemed only fitting that I provide an update before 2020-’here near the year rear’, if you will.
In that time, Python has become the 2nd most popular language on GitHub, and Blog posts about Python dependency management continue to prompt lengthy disucssions online.
Python dependency management is a hot topic even in the tiny corner of the Internet that is this blog. My first Pipenv vs Poetry comparison is my most popular post by ~27%, and two of my three top posts…
See Part II: Consuming Metadata for how to create a typed form in Vue.js using the metadata generated in this article!
When developing a web application, a common design pattern is to divide the project into two repositories: 1) the API, or “back end”, which handles database or service interaction (“back end”), and 2) the client, or “front end”, which handles user interaction.
But before we look at how to share metadata…
UpdateViewin your project.
One of the things that drew me to Django was how easy Django makes it to interact with items in a database. Once you’ve defined your models, Django’s model forms can handle the heavy lifting of allowing your users to create, update, and delete entries in your project’s database.
The purpose of this post is to show a strategy for writing form templates that can be shared among all models in your project without modification. In doing so, we’re employing at least three of Django’s design philosophies:
Let’s get our feet wet…