A "Baby Tornado" to aid in Python server development

Why?


 Since my last post, I've been highly focused on Tensorflow projects at home and at work.  In the process of running Tensorflow behind an API, I've needed to make code changes to the "secret sauce" (business logic) that stands before Tensorflow and actually provides it with its data.  This could be in the pipeline of multiple Tensorflow models chained together, image manipulation, working with data that gets outputted from the model, or whatever other reasons.  Unfortunately, it is often slow and wastes a bunch of time to constantly restart the whole server (including reinitializing Tensorflow for 20 or 30 seconds), especially when you simply made a typo or used the wrong variable name or something like that.

 Besides the Tensorflow work, I've been involved in many blog-worthy pursuits since my last post but simply haven't had time to write about them.  (In fact, I meant to write this last week, but forgot.)  Anyway, at the end of June, right before my previous post, I began running biweekly meetups called "Tensorflow Tuesday Office Hours."  Here, interested people get together in various locations around town to talk about Tensorflow and get their questions addressed, whether it be about installation, scaling it up, mathematical questions, or picking a model.  In the process of helping people install, I decided it'd be worthwhile to try the mainline Tensorflow version that includes the Jupyter notebook rather than the "devel" version that has command-line access only but has more of the Tensorflow Github repo included in its image.  It had been many years since I used Jupyter, and had forgotten its benefits as, for such a long time, I fought the Python shell to enter long functions and make tweaks to specific lines in them.  Of course, with Jupyter, you just click on what you want to tweak, then rerun that code snippet.  (2013 called me and congratulated me on this rediscovery. :-P)

 It didn't take me long to realize I could utilize a Jupyter notebook to run a Python server where I could change the route functions that a Python server calls when a request is made to a particular endpoint on the server.  This would allow me to make small tweaks to the business logic for the sake of testing the accuracy, performance, or simply fixing typos, without having to wait on Tensorslow [sic] to restart.

How?


 The original application I was going to test this with was written using a Flask server.  Flask is a popular choice for quick proofs of concept written in Python, but has many downsides that make it unsuitable for production.  And, as much as I tried to change the underlying route function that Flask would call, it seems like the Flask process would simply take over the entire Jupyter notebook and no other code snippets could be run in Jupyter once you start a Flask server.  Maybe further research would uncover why or how to get around it, but since the app was being ported to Tornado anyway, I put the Flask research to bed and attempted to do this with Tornado.  To make a long story short, I got it working, and can make changes to the functions that Tornado runs whenever it runs a server route.

Where does the code live?


 Check out my Jupyter notebook on GitHub here: https://github.com/mrcity/baby-tornado

 In this notebook, simply run In [1], In [2], and In [3].  Each time you want to change what a particular API endpoint and request type does, just edit the code in In [2] and run In [2].  Call your endpoint again and observe the change!

 As far as Tensorflow is concerned, you could initialize it in the notebook in stage, load the model in stage 3, and then not have to worry about those steps ever again -- just change your business logic in stage 2. Enjoy!

Comments

Post a Comment

Popular posts from this blog

Less Coding, More Prompt Engineering!

Image
Software developers have taken note of the efficacy of large language models such as ChatGPT towards automating particular development tasks. Depending on the language in use and what is to be accomplished, LLMs can provide a concise answer that circumvents the shortcomings of documentation that is either incomplete or tries to "boil the ocean." LLMs work best at generating code when the problem is well-defined and the language is fairly static and consistent. For instance, I have had a great deal of success when asking for code to perform basic operations on Amazon DynamoDB in the Node.js SDK 3. It was a bit more difficult to have it write infrastructure as code for AWS using the CDK framework in Python 3, but it still produced decent enough code that I at least knew where to start in looking at lengthy documentation. However, writing native mobile code such as Kotlin for Android or Swift for iOS yields some rather incomprehensible and outdated results. Besides ChatGPT, ther...
Read more

Start Azure Pipeline from another pipeline with ADO CLI & PowerShell

Image
Are you looking to find the one simple command that can kick off a pipeline from another pipeline in Azure DevOps? You may have found a lot of annoying restrictions using straight YAML because so many things have to be known ahead-of-time (i.e. set using compile-time variables). This prevents you from doing such things as conditionally running pipelines, utilizing arrays defined at runtime as parameters into many ADO tasks/commands, or performing manipulations on runtime data for use in subsequent commands. You can't even kick off a pipeline without the previous one finishing (and invoking a pipeline trigger ). Follow along as I explore a scripted solution to solve my problem. My Use Case I want to provide fresh Databricks images on a private Azure Container Registry (ACR). This way, data scientists are not confounded by changes to Databricks runtimes when their clusters start and stop, since changes can prevent their package & library installation scripts from running successf...
Read more

An Augmented Reality Experience to Complement a Vintage Pinball Machine

My 1948 Gottlieb Cinderella pinball machine won 1st Place Best Antique at Texas Pinball Festival 2024! As one of the earliest games made with powered flippers, I worked tirelessly for weeks before the show to resolve any problems that would spoil the gameplay experience, such as mechanical malfunctioning and leveling inserts on the playfield so the ball doesn’t get stuck in spots. However, such an old game lacks many of the interesting aspects of modern games, so it might be overlooked by casual pinball players without some kind of augmented experience. Enter the Cinderella Augmented Experience! This augmented-reality (AR) app aims to provide its users a glimpse into what goes on inside the game as they play it. Games from the 1940s are much different inside than even other electromechanical machines from the 1960s and 1970s. For instance, before score reels were invented, there was a single score stepper that had rivets representing every possible score in the game. Aspects like this ...
Read more