18 December 2018 0 comments Python, Web development
Last week, I landed concurrent downloads in hashin. The example was that you do something like...
$ time hashin -r some/requirements.txt --update-all
...and the whole thing takes ~2 seconds even though it that some/requirements.txt file might contain 50 different packages, and thus 50 different PyPI.org lookups.
Just wanted to point out, this is not unique to use with --update-all. It's for any list of packages. And I want to put some better numbers on that so here goes...
Suppose you want to create a requirements file for every package in the current virtualenv you might do it like this:
# the -e filtering removes locally installed packages from git URLs
$ pip freeze | grep -v '-e ' | xargs hashin -r /tmp/reqs.txt
Before running that I injected a little timer on each pypi.org download. It looked like this:
def get_package_data(package, verbose=False):
url = "https://pypi.org/pypi/%s/json" % package
if verbose:
print(url)
+ t0 = time.time()
content = json.loads(_download(url))
if "releases" not in content:
raise PackageError("package JSON is not sane")
+ t1 = time.time()
+ print(t1 - t0)
I also put a print around the call to pre_download_packages(lookup_memory, specs, verbose=verbose) to see what the "total time" was.
The output looked like this:
▶ pip freeze | grep -v '-e ' | xargs python hashin.py -r /tmp/reqs.txt
0.22896194458007812
0.2900810241699219
0.2814369201660156
0.22658205032348633
0.24882292747497559
0.268247127532959
0.29332590103149414
0.23981380462646484
0.2930259704589844
0.29442572593688965
0.25312376022338867
0.34232664108276367
0.49491214752197266
0.23823285102844238
0.3221290111541748
0.28302812576293945
0.567702054977417
0.3089122772216797
0.5273139476776123
0.31477880477905273
0.6202089786529541
0.28571176528930664
0.24558186531066895
0.5810830593109131
0.5219211578369141
0.23252081871032715
0.4650228023529053
0.6127192974090576
0.6000659465789795
0.30976200103759766
0.44440698623657227
0.3135409355163574
0.638585090637207
0.297544002532959
0.6462509632110596
0.45389699935913086
0.34597206115722656
0.3462028503417969
0.6250648498535156
0.44159507751464844
0.5733060836791992
0.6739277839660645
0.6560370922088623
SUM TOTAL TOOK 0.8481268882751465
If you sum up all the individual times it would have become 17.3 seconds. It's 43 individual packages and 8 CPUs multiplied by 5 means it had to wait with some before downloading the rest.
Clearly, this works nicely.
12 December 2018 0 comments Linux, MacOSX
I needed this for a project and it has served me pretty well. Let's jump right into it:
# This is elapsed.sh
SECONDS=0
function elapsed()
{
local T=$SECONDS
local D=$((T/60/60/24))
local H=$((T/60/60%24))
local M=$((T/60%60))
local S=$((T%60))
(( $D > 0 )) && printf '%d days ' $D
(( $H > 0 )) && printf '%d hours ' $H
(( $M > 0 )) && printf '%d minutes ' $M
(( $D > 0 || $H > 0 || $M > 0 )) && printf 'and '
printf '%d seconds\n' $S
}
And here's how you use it:
# Assume elapsed.sh to be in the current working directory
source elapsed.sh
echo "Doing some stuff..."
# Imagine it does something slow that
# takes about 3 seconds to complete.
sleep 3
elapsed
echo "Some quick stuff..."
sleep 1
elapsed
echo "Doing some slow stuff..."
sleep 61
elapsed
The output of running that is:
Doing some stuff...
3 seconds
Some quick stuff...
4 seconds
Doing some slow stuff...
1 minutes and 5 seconds
Basically, if you have a bash script that does a bunch of slow things, it having a like of elapsed there after some blocks of code will print out how long the script has been running.
It's not beautiful but it works.
10 December 2018 2 comments PostgreSQL, MacOSX, Web development
It's weird to do performance analysis of a database you run on your laptop. When testing some app, your local instance probably has 1/1000 the amount of realistic data compared to a production server. Or, you're running a bunch of end-to-end integration tests whose PostgreSQL performance doesn't make sense to measure.
Anyway, if you are doing some performance testing of an app that uses PostgreSQL one great tool to use is pghero. I use it for my side-projects and it gives me such nice insights into slow queries that I'm willing to live with the cost that it is to run it on a production database.
This is more of a brain dump of how I run it locally:
First, you need to edit your postgresql.conf. Even if you used Homebrew to install it, it's not clear where the right config file is. Start psql (on any database) and type this to find out which file is the one:
$ psql kintobench
kintobench=# show config_file;
config_file
-----------------------------------------
/usr/local/var/postgres/postgresql.conf
(1 row)
Now, open /usr/local/var/postgres/postgresql.conf and add the following lines:
# Peterbe: From Pghero's configuration help.
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.track = all
Now, to restart the server use:
▶ brew services restart postgresql
Stopping `postgresql`... (might take a while)
==> Successfully stopped `postgresql` (label: homebrew.mxcl.postgresql)
==> Successfully started `postgresql` (label: homebrew.mxcl.postgresql)
The next thing you need is pghero itself and it's easy to run in docker. So to start, you need Docker for mac installed. You also need to know the database URL. Here's how I ran it:
docker run -ti -e DATABASE_URL=postgres://peterbe:@host.docker.internal:5432/kintobench -p 8080:8080 ankane/pghero
Note the trick of peterbe:@host.docker.internal because I don't use a password but inside the Docker container it doesn't know my terminal username. And the host.docker.internal is so the Docker container can reach the PostgreSQL installed on the host.
Once that starts up you can go to http://localhost:8080
in a browser and see a listing of all the cumulatively slowest queries. There are other cool features in pghero too that you can immediately benefit from such as hints about unused/redundent database indices.
Hope it helps!
13 November 2018 0 comments Linux, Python
If you don't know it is, hashin is a Python command line tool for updating your requirements file's packages and their hashes for use with pip install. It takes the pain out of figuring out what hashes each package on PyPI has. It also takes the pain out of figuring out what version you
can upgrade to.
In the 0.14.0 release (changelog) there are a bunch of new features. The most exciting one is --update-all. Let's go through some of the new features:
Update all (--update-all)
Suppose you want to bravely upgrade all the pinned packages to the latest and greatest. Before version 0.14.0 you'd have to manually open the requirements file and list every single package on the command line:
$ less requirements.txt
$ hashin Django requests Flask cryptography black nltk numpy
With --update-all it's the same thing except it does that reading and copy-n-paste for you:
Particularly nifty is to combine this with --dry-run if you get nervous about that many changes.
Interactive update all (--interactive)
This new flag only makes sense when used together with --update-all. Used together, it basically reads all packages in the requirements file, and for each one that there is a new version it asks you if you want to update it or skip it:
It looks like this:
$ hashin --update-all --interactive
PACKAGE YOUR VERSION NEW VERSION
Django 2.1.2 2.1.3 ✓
requests 2.20.0 2.20.1 ✘
numpy 1.15.2 1.15.4 ?
Update? [Y/n/a/q/?]:
You can also use the aliases hashin -u -i to do the same thing.
Support for "extras"
If you want to have requests[security] or markus[datadog] in your requirements file, hashin used to not support that. This now works:
$ hashin "requests[security]"
Before, it would look for a package called verbatim requests[security] on PyPI which obviously doesn't exist. Now, it parses that syntax, makes a lookup for requests and when it's done it puts the extra syntax back into the requirements file.
Thanks Dustin Ingram for pushing for this one!
Atomic writes
Prior to this version, if you typed hashin requests flask numpy nltkay it would go ahead and do one of those packages at a time and effectively open and edit the requirements file as many times as there are packages mentioned. The crux of that is that if you, for example, have a typo (e.g. nltkay instead of nltk) it would crash there and not roll back any of the other writes. It's not a huge harm but it certainly is counter intuitive.
Another place where this matters is with --dry-run. If you specified something like hashin --dry-run requests flask numpy
you would get one diff per package and thus repeat the diff header 3 (excessive) times.
The other reason why atomic writes is important is if you use hashin --update-all --interactive and it asks you if you want to update package1, package2, package3, and then you decide "Nah. I don't want any of this. I quit!" it would just do that without updating the requirements file.
Better not-found errors
This was never a problem if you used Python 2.7 but for Python 3.x, if you typoed a package name you'd get a Python exception about the HTTP call and it wasn't obvious that the mistake lies with your input and not the network. Basically, it traps any HTTP errors and if it's 404 it's handled gracefully.
(Internal) Black everything and pytest everything
All source code is now formatted with Black
which, albeit imperfect, kills any boring manual review of code style nits. And, it uses therapist to wrap the black checks and fixes.
And all unit tests are now written for pytest. pytest was already the tool used in TravisCI but now all of those self.assertEqual(foo, bar)s have been replaced with assert foo == bar.
04 November 2018 2 comments Python
This is perhaps insanely obvious but it was a measurement I had to do and it might help you too if you use python-jsonschema
a lot too.
I have this project which has a migration script that needs to transfer about 1M records from one PostgreSQL database, transform it a bit, validate it, and store it in another PostgreSQL database. The validation step was done like this:
from jsonschema import validate
...
with open(os.path.join(settings.BASE_DIR, "schema.yaml")) as f:
SCHEMA = yaml.load(f)["schema"]
...
class Build(models.Model):
...
@classmethod
def validate_build(cls, build):
validate(build, SCHEMA)
That works fine when you have a slow trickle of these coming in with many seconds or minutes apart. But when you have to do about 1M of them, the speed overhead starts to really matter. Granted, in this context, it's just a migration which is hopefully only done once but it helps that it doesn't take too long since it makes it easier to not have any downtime.
What about python-fastjsonschema?
The name python-fastjsonschema just sounds very appealing but I'm just not sure how mature it is or what the subtle differences are between that and the more established python-jsonschema which I was already using.
It has two ways of using it either...
fastjsonschema.validate(schema, data
)
...or...
validator = fastjsonschema.compile(schema)
validator(data)
That got me thinking, why don't I just do that with regular python-jsonschema!
All you need to do is crack open the validate function and you can now re-used one instance for multiple pieces of data:
from jsonschema.validators import validator_for
klass = validator_for(schema)
klass.check_schema(schema) # optional
instance = klass(SCHEMA)
instance.validate(data)
I rewrote my projects code to this:
from jsonschema import validate
...
with open(os.path.join(settings.BASE_DIR, "schema.yaml")) as f:
SCHEMA = yaml.load(f)["schema"]
_validator_class = validator_for(SCHEMA)
_validator_class.check_schema(SCHEMA)
validator = _validator_class(SCHEMA)
...
class Build(models.Model):
...
@classmethod
def validate_build(cls, build):
validator.validate(build)
How do they compare, performance-wise?
Let this simple benchmark code speak for itself:
from buildhub.main.models import Build, SCHEMA
import fastjsonschema
from jsonschema import validate, ValidationError
from jsonschema.validators import validator_for
def f1(qs):
for build in qs:
validate(build.build, SCHEMA)
def f2(qs):
validator = validator_for(SCHEMA)
for build in qs:
validate(build.build, SCHEMA, cls=validator)
def f3(qs):
cls = validator_for(SCHEMA)
cls.check_schema(SCHEMA)
instance = cls(SCHEMA)
for build in qs:
instance.validate(build.build)
def f4(qs):
for build in qs:
fastjsonschema.validate(SCHEMA, build.build)
def f5(qs):
validator = fastjsonschema.compile(SCHEMA)
for build in qs:
validator(build.build)
# Reporting
import time
import statistics
import random
functions = f1, f2, f3, f4, f5
times = {f.__name__: [] for f in functions}
for _ in range(3):
qs = list(Build.objects.all().order_by("?")[:1000])
for func in functions:
t0 = time.time()
func(qs)
t1 = time.time()
times[func.__name__].append((t1 - t0) * 1000)
def f(ms):
return f"{ms:.1f}ms"
for name, numbers in times.items():
print("FUNCTION:", name, "Used", len(numbers), "times")
print("\tBEST ", f(min(numbers)))
print("\tMEDIAN", f(statistics.median(numbers)))
print("\tMEAN ", f(statistics.mean(numbers)))
print("\tSTDEV ", f(statistics.stdev(numbers)))
Basically, 3 times for each of the alternative implementations, do a validation on a 1,000 JSON blobs (technically Python dicts) that is around 1KB, each, in size.
The results:
FUNCTION: f1 Used 3 times
BEST 1247.9ms
MEDIAN 1309.0ms
MEAN 1330.0ms
STDEV 94.5ms
FUNCTION: f2 Used 3 times
BEST 1266.3ms
MEDIAN 1267.5ms
MEAN 1301.1ms
STDEV 59.2ms
FUNCTION: f3 Used 3 times
BEST 125.5ms
MEDIAN 131.1ms
MEAN 133.9ms
STDEV 10.1ms
FUNCTION: f4 Used 3 times
BEST 2032.3ms
MEDIAN 2033.4ms
MEAN 2143.9ms
STDEV 192.3ms
FUNCTION: f5 Used 3 times
BEST 16.7ms
MEDIAN 17.1ms
MEAN 21.0ms
STDEV 7.1msBasically, if you use python-jsonschema and create a reusable instance it's 10 times faster than the "default way". And if you do the same but with python-fastjsonscham it's 100 times faster.
By the way, in version f5 it validated 1,000 1KB records in 16.7ms. That's insanely fast!
02 November 2018 0 comments ReactJS, Javascript
React Hooks isn't here yet but when it comes I'll be all over that, replacing many of my classes with functions.
However, as of
React 16.6 there's this awesome new React.memo() thing which is such a neat solution. Why didn't I think of that, myself, sooner?!
Anyway, one of the subtle benefits of it is that writing functions minify a lot better than classes when Babel'ifying your ES6 code.
To test that, I took one of my project's classes, which needed to be "PureComponent":
class ShowAutocompleteSuggestionSong extends React.PureComponent {
render() {
const { song } = this.props;
return (
<div className="media autocomplete-suggestion-song">
<div className="media-left">
<img
className={
song.image && song.image.preview
? 'img-rounded lazyload preview'
: 'img-rounded lazyload'
}
src={
song.image && song.image.preview
? song.image.preview
: placeholderImage
}
data-src={
song.image ? absolutifyUrl(song.image.url) : placeholderImage
}
alt={song.name}
/>
</div>
<div className="media-body">
<h5 className="artist-name">
<b>{song.name}</b>
{' by '}
<span>{song.artist.name}</span>
</h5>
{song.fragments.map((fragment, i) => {
return <p key={i} dangerouslySetInnerHTML={{ __html: fragment }} />;
})}
</div>
</div>
);
}
}
Minified it weights 1,893 bytes and looks like this:
Minified PureComponent class
When re-written with React.memo it looks like this:
const ShowAutocompleteSuggestionSong = React.memo(({ song }) => {
return (
<div className="media autocomplete-suggestion-song">
<div className="media-left">
<img
className={
song.image && song.image.preview
? 'img-rounded lazyload preview'
: 'img-rounded lazyload'
}
src={
song.image && song.image.preview
? song.image.preview
: placeholderImage
}
data-src={
song.image ? absolutifyUrl(song.image.url) : placeholderImage
}
alt={song.name}
/>
</div>
<div className="media-body">
<h5 className="artist-name">
<b>{song.name}</b>
{' by '}
<span>{song.artist.name}</span>
</h5>
{song.fragments.map((fragment, i) => {
return <p key={i} dangerouslySetInnerHTML={{ __html: fragment }} />;
})}
</div>
</div>
);
});
Minified it weights 783 bytes and looks like this:
Minified React.memo function
Highly scientific measurement. Yeah, I know. (Joking)
Perhaps it's stating the obvious but part of the ES5 code that it generates, from classes can be reused for other classes.
Anyway, it's neat and worth considering to squeeze some bytes out. And the bonus is that it gets you prepared for Hooks in React 16.7.
26 October 2018 0 comments ReactJS, Javascript, Web development
If you're reading this, you might have thought one of two thoughts about this blog post title (or both); "Cool buzzwords!" or "Yuck! So much hyped buzzwords!"
Either way, React v16.6 came out a couple of days ago and it brings with it React.lazy: Code-Splitting with Suspense.
React.lazy is React's built-in way of lazy loading components. With Suspense
you can make that lazy loading be smart and know to render a fallback component (or JSX element) whilst waiting for that slowly loading chunk for the lazy component.
The sample code in the announcement was deliciously simple but I was curious; how does that work with react-router-dom??
Without furher ado, here's a complete demo/example. The gist is an app that has two sub-components loaded with react-router-dom:
<Router>
<div className="App">
<Switch>
<Route path="/" exact component={Home} />
<Route path="/:id" component={Post} />
</Switch>
</div>
</Router>
The idea is that the Home component will list all the blog posts and the Post component will display the full details of that blog post. In my demo, the Post component never bothers to actually do the fetching of the full details to display. It just displays the passed in ID from the react-router-dom match prop. You get the idea.
That's standard React with react-router-dom stuff. Next up, lazy loading. Basically, instead of importing the Post component, you make it lazy:
-import Post from "./post";
+const Post = React.lazy(() => import("./post"));
And here comes the magic sauce. Instead of referencing component={Post} in the <Route/> you use this badboy:
function WaitingComponent(Component) {
return props => (
<Suspense fallback={<div>Loading...</div>}>
<Component {...props} />
</Suspense>
);
}
Complete prototype
The final thing looks like this:
import React, { lazy, Suspense } from "react";
import ReactDOM from "react-dom";
import { MemoryRouter as Router, Route, Switch } from "react-router-dom";
import Home from "./home";
const Post = lazy(() => import("./post"));
function App() {
return (
<Router>
<div className="App">
<Switch>
<Route path="/" exact component={Home} />
<Route path="/:id" component={WaitingComponent(Post)} />
</Switch>
</div>
</Router>
);
}
function WaitingComponent(Component) {
return props => (
<Suspense fallback={<div>Loading...</div>}>
<Component {...props} />
</Suspense>
);
}
const rootElement = document.getElementById("root");
ReactDOM.render(<App />, rootElement);
(sorry about the weird syntax highlighting with the red boxes.)
And it totally works! It's hard to show this with the demo but if you don't believe me, you can download the whole codesandbox as a .zip, run yarn && yarn run build && serve -s build and then you can see it doing its magic as if this was the complete foundation of a fully working client-side app.
1. Loading the "Home" page, then click one of the links
2. Lazy loading the Post component
3. Post component lazily loaded once and for all
Bonus
One thing that can happen is that you might load the app when the Wifi is honky dory but when you eventually make a click that causes a lazy loading to actually need to go out on the Internet and download that .js file it might fail. For example, because the file has been removed from the server or your network just fails for some reason. To deal with that, simply wrap the whole <Suspense> component in an error boundary component.
See this demo which is a fork of the main demo but with error boundaries added.
In conclusion
No surprise that it works. React is pretty awesome. I just wasn't sure how it would look like with react-router-dom.
A word of warning, from the v16.6 announcement: "This feature is not yet available for server-side rendering. Suspense support will be added in a later release."
I think lazy loading isn't actually that big of a deal. It's nice that it works but how likely is it really that you have a sub-tree of components that is so big and slow that you can't just pay for it up front as part of one big fat build. If you really care about a really great web performance for those people who reach your app rarely and sporadically, the true ticket to success is server-side rendering and shipping a gzipped HTML document with all the React client-side code non-blocking rendering
so that the user can download the HTML, start reading/consuming it immediately and then whilst the user is doing that you download the rest of the .js that is going to be needed once the user clicks around. Start there.
17 October 2018 4 comments Web Performance, Web development
Right off the bat; I don't know. All I know is that it's complicated.
I have this page
which is just a blog post page. It's entirely rendered on the server, comments and all. At the time of writing, the total size of the HTML document is 119KB (30KB gzipped). If you remove all the comments, which makes up the bulk of the HTML it reduces down to 31KB (7KB gzipped). Fair enough. That's 23KB less to download. But, does it matter (much)?
Downloading
First of all, I noticed this:
WebPagetest with iPhone 6, 4G on the same US coast as the datacenter
That's a WebPagetest using iPhone 6 on 4G and, lemme emphasize this, it took 126ms to download the HTML document
. If you subtract "DNS Lookup" (283ms), "Initial Connection" (1013ms), and "SSL Negotiation" (733ms) it took 684ms serve the file, download it, and parse it. Remember, this is all on 4G. Pretty fast. In conclusion, it's probably not too much HTML in that page to download. This downloadingness is fraction of the total "web performance cost". Let's dig deeper.
Note! With WebPagetest all those numbers like DNS Lookup, Initial Connection and SSL Negotiation are wildly unpredictable between tests. Chances are, the numbers are very different the next time you run a test using the exact same input. Who knows. Deep internet plumbings beyond the control of WebPagetest.
Note! I ran it one more time with the exact same parameters and this time it was 535ms (instead of 684ms) to serve, download, and parse.
Parsing & layout
Parsing is hard to measure but here's what I found when using the Google Chrome dev tools:
Google Chrome Performance devtools
It says it took...
- parsed HTML - 94ms
- recalculate style - 43ms
- layout - 386ms
That's half a second just loading and rendering. Definitely sucks. But note, this test uses 4x CPU slowdown and 3G simulation. So perhaps it's not so bad.
Let's try again with a smaller HTML document
So I butchered up a hybrid version that has almost the same HTML except all but 1 of those 166'ish div.comment
DOM nodes. It's now 31KB (7KB gzipped´) to download instead of 119KB (30KB gzipped).
Same WebPagetest parameters but now this this smaller HTML document:
WebPagetest with a much smaller HTML footprint
Now it says it only took 39ms to download and 232ms (it was 684ms before) to serve the file, download it, and parse it. Interesting!
Note! I ran it one more time with exact same parameters and this time it was 237ms (instead of 232ms) to serve, download, and parse.
Clearly it's working. The smaller the HTML document the faster it performs. No surprise. But stick around for the conclusion.
Parsing & layout with a smaller HTML document
Check this out:
Google Chrome Performance devtools (smaller HTML document)
It says it took...
- parsed HTML - 91ms
- recalculate style - 6ms
- layout - 29ms
Mind you, all of these numbers are at the mercy of what my laptop is up to at the moment as it can affect Chrome's rendering if it has, at that moment, less (or more) access to CPU and memory caching.
Either way, it parses + layout in 126ms instead of 523ms for the larger HTML document.
Side-by-side
The best test to see how much faster the smaller HTML document variant is, is to compare them side-by-side. It looks like this:
Visual comparison on WebPagetest (using 4G)
Two major takeaways from this:
- The smaller HTML version starts rendering half a second before the original one.
- The complete time favors the smaller HTML version by 2.5 seconds but that's possibly influenced by the ads that load more than any slow layout rendering.
- This is using 4G
which isn't unheard of but definitely much less common than better speeds.
Here they are compared on "Desktop" which appears to give the smaller HTML version a 0.2 second advantage:
Visual comparison on WebPagetest (using "Desktop")
And here are the Lighthouse reports side-by-side:
Side-by-side using Lighthouse
Discussion
The above concludes rather unsurprisingly that a smaller HTML footprint downloads, parses and lays out quicker.
The killer reason that page is so large, with all those comments rendered in the original HTML is simple: SEO. Google loves comments because comments indicate that the page is thriving and a place where people go, spend time, and stick around. I've experimented with this in the past and found that if I make the HTML document smaller (or loading the rest after document load) the SEO takes a big hit. Yes, Google's bot renders with JavaScript but not always and even if it does, I assume it's smart enough to appreciate that content that is loaded (async or post-DOMContentLoad) is less important and thus not what the page is about.
Regarding SEO, we know that Google loves fast sites. Especially for mobile. But content is still king my gut tells me. Left as an exercise to the reader to take a stand on this.
Another problem with lazy loading the comments (or whatever else might be applicable to your site) is that it might cause "flicker". I put that word in quote because sometimes flicker is literally visual flicker and sometimes it's moments of browser sluggishness. The XHR request and the subsequent post-rendering will cause a bunch of work that strains the browser and might make it unpleasant when your eyes and brain is in the midst of committing to consuming it.
Basically, there are significant real benefits of not
trying to squeeze every little millisecond out by making the HTML smaller upfront. Remember the fact that the "smaller HTML" version in this test is drastic. I butchered it from 119KB to 31KB which might be so drastic that it's not necessarily applicable at all. In other words, had I reduced the HTML size by just 20% it might not even register on the performance graph but could be significant in terms SEO keywords.
Conclusion
The majority of the time spend making a web page useful to a user is a sum of all sorts of metrics. The size of the HTML document does matter but remember that it's just one of multiple aspects to watch out for.
In conclusion, it's complicated and depends on your needs and context. I hope you can benefit a little bit from the metrics above.
12 October 2018 0 comments Python
I'm in the midst of rewriting a big app that currently uses AWS S3 and will soon be switched over to Google Cloud Storage. This blog post is a rough attempt to log various activities in both Python libraries:
Disclaimer: I'm manually copying these snippets from a real project and I have to manually scrub the code clean of unimportant quirks, hacks, and other unrelated things that would just add noise.
Install
boto3
$ pip install boto3
$ emacs ~/.aws/credentials
google-cloud-storage
$ pip install google-cloud-storage
$ cat ./google_service_account.json
Note: You need to create a service account and then that gives you a .json file which you download and make sure you pass its path when you create a client.
I suspect there are more/other ways to do this with environment variables alone but I haven't got there yet.
Making a "client"
boto3
Note, there are easier shortcuts for this but with this pattern you can have full control over things like like read_timeout, connect_timeout, etc. with that confi_params keyword.
import boto3
from botocore.config import Config
def get_s3_client(region_name=None, **config_params):
options = {"config": Config(**config_params)}
if region_name:
options["region_name"] = region_name
session = boto3.session.Session()
return session.client("s3", **options)
google-cloud-storage
from google.cloud import storage
def get_gcs_client():
return storage.Client.from_service_account_json(
settings.GOOGLE_APPLICATION_CREDENTIALS_PATH
)
Checking if a bucket exists and if you have access to it
boto3 (for s3_client here, see above)
from botocore.exceptions import ClientError, EndpointConnectionError
try:
s3_client.head_bucket(Bucket=bucket_name)
except ClientError as exception:
if exception.response["Error"]["Code"] in ("403", "404"):
raise BucketHardError(
f"Unable to connect to bucket={bucket_name!r} "
f"ClientError ({exception.response!r})"
)
else:
raise
except EndpointConnectionError:
raise BucketSoftError(
f"Unable to connect to bucket={bucket.name!r} "
f"EndpointConnectionError"
)
else:
print("It exists and we have access to it.")
google-cloud-storage
from google.api_core.exceptions import BadRequest
try:
gcs_client.get_bucket(bucket_name)
except BadRequest as exception:
raise BucketHardError(
f"Unable to connect to bucket={bucket_name!r}, "
f"because bucket not found due to {exception}"
)
else:
print("It exists and we have access to it.")
Checking if an object exists
boto3
from botocore.exceptions import ClientError
def key_existing(client, bucket_name, key):
"""return a tuple of (
key's size if it exists or 0,
S3 key metadata
)
If the object doesn't exist, return None for the metadata.
"""
try:
response = client.head_object(Bucket=bucket_name, Key=key)
return response["ContentLength"], response.get("Metadata")
except ClientError as exception:
if exception.response["Error"]["Code"] == "404":
return 0, None
raise
Note, if you do this a lot and often find that the object doesn't exist the using list_objects_v2 is probably faster.
google-cloud-storage
def key_existing(client, bucket_name, key):
"""return a tuple of (
key's size if it exists or 0,
S3 key metadata
)
If the object doesn't exist, return None for the metadata.
"""
bucket = client.get_bucket(bucket_name)
blob = bucket.get_blob(key)
if blob:
return blob.size, blob.metadata
return 0, None
Uploading a file with a special Content-Encoding
Note: You have to use your imagination with regards to the source. In this example, I'm assuming that the source is a file on disk and that it might have already been compressed with gzip.
boto3
def upload(file_path, bucket_name, key_name, metadata=None, compressed=False):
content_type = get_key_content_type(key_name)
metadata = metadata or {}
# boto3 will raise a botocore.exceptions.ParamValidationError
# error if you try to do something like:
#
# s3.put_object(Bucket=..., Key=..., Body=..., ContentEncoding=None)
#
# ...because apparently 'NoneType' is not a valid type.
# We /could/ set it to something like '' but that feels like an
# actual value/opinion. Better just avoid if it's not something
# really real.
extras = {}
if content_type:
extras["ContentType"] = content_type
if compressed:
extras["ContentEncoding"] = "gzip"
if metadata:
extras["Metadata"] = metadata
with open(file_path, "rb") as f:
s3_client.put_object(Bucket=bucket_name, Key=key_name, Body=f, **extras)
google-cloud-storage
def upload(file_path, bucket_name, key_name, metadata=None, compressed=False):
content_type = get_key_content_type(key_name)
metadata = metadata or {}
bucket = gcs_client.get_bucket(bucket_name)
blob = bucket.blob(key_name)
if content_type:
blob.content_type = content_type
if compressed:
blob.content_encoding = "gzip"
blob.metadata = metadata
blob.upload_from_file(f)
Downloading and uncompressing a gzipped object
boto3
from io import BytesIO
from gzip import GzipFile
from botocore.exceptions import ClientError
from .utils import iter_lines
def get_stream(bucket_name, key_name):
try:
response = source.s3_client.get_object(
Bucket=bucket_name, Key=key
)
except ClientError as exception:
if exception.response["Error"]["Code"] == "NoSuchKey":
raise KeyHardError("key not in bucket")
raise
stream = response["Body"]
# But if the content encoding is gzip we have re-wrap the stream.
if response.get("ContentEncoding") == "gzip":
body = response["Body"].read()
bytestream = BytesIO(body)
stream = GzipFile(None, "rb", fileobj=bytestream)
for line in iter_lines(stream):
yield line.decode("utf-8")
google-cloud-storage
from io import BytesIO
from gzip import GzipFile
from botocore.exceptions import ClientError
from .utils import iter_lines
def get_stream(bucket_name, key_name):
bucket = gcs_client.get_bucket(bucket_name)
blob = bucket.get_blob(key)
if blob is None:
raise KeyHardError("key not in bucket")
bytestream = BytesIO()
blob.download_to_file(bytestream)
bytestream.seek(0)
for line in iter_lines(bytestream):
yield line.decode("utf-8")
Note That here blob.download_to_file works a bit like requests.get() in that it automatically notices the Content-Encoding metadata and does the gunzip on the fly.
Conclusion
It's not fair to compare them on style because I think boto3 came out of boto which probably started back in the day when Google was just web search and web emails.
I wanted to include a section about how to unit test against these. Especially how to mock them. But what I had for a draft was getting ugly. Yes, it works for the testing needs I have in my app but it's very personal taste (aka. appropriate for the context) and admittedly quite messy.
10 October 2018 2 comments Web development, Python
Bleach is awesome. Thank you for it @willkg! It's a Python library for sanitizing text as well as "linkifying" text for HTML use. For example, consider this:
>>> import bleach
>>> bleach.linkify("Here is some text with a url.com.")
'Here is some text with a <a href="http://url.com" rel="nofollow">url.com</a>.'Note that sanitizing is separate thing, but if you're curious, consider this example:
>>> bleach.linkify(bleach.clean("Here is <script> some text with a url.com."))
'Here is <script> some text with a <a href="http://url.com" rel="nofollow">url.com</a>.'With that output you can confidently template interpolate that string straight into your HTML.
Getting fancy
That's a great start but I wanted a more. For one, I don't always want the rel="nofollow" attribute on all links. In particular for links that are within the site. Secondly, a lot of things look like a domain but isn't. For example This is a text.at the start which would naively become...:
>>> bleach.linkify("This is a text.at the start")
'This is a <a href="http://text.at" rel="nofollow">text.at</a> the start'...because text.at looks like a domain.
So here is how I use it here on www.peterbe.com to linkify blog comments:
def custom_nofollow_maker(attrs, new=False):
href_key = (None, u"href")
if href_key not in attrs:
return attrs
if attrs[href_key].startswith(u"mailto:"):
return attrs
p = urlparse(attrs[href_key])
if p.netloc not in settings.NOFOLLOW_EXCEPTIONS:
# Before we add the `rel="nofollow"` let's first check that this is a
# valid domain at all.
root_url = p.scheme + "://" + p.netloc
try:
response = requests.head(root_url)
if response.status_code == 301:
redirect_p = urlparse(response.headers["location"])
# If the only difference is that it redirects to https instead
# of http, then amend the href.
if (
redirect_p.scheme == "https"
and p.scheme == "http"
and p.netloc == redirect_p.netloc
):
attrs[href_key] = attrs[href_key].replace("http://", "https://")
except ConnectionError:
return None
rel_key = (None, u"rel")
rel_values = [val for val in attrs.get(rel_key, "").split(" ") if val]
if "nofollow" not in [rel_val.lower() for rel_val in rel_values]:
rel_values.append("nofollow")
attrs[rel_key] = " ".join(rel_values)
return attrs
html = bleach.linkify(text, callbacks=[custom_nofollow_maker])
This basically taking the default nofollow callback and extending it a bit.
By the way, here is the complete code I use for sanitizing and linkifying blog comments here on this site: render_comment_text.
Caveats
This is slow because it requires network IO every time a piece of text needs to be linkified (if it has domain looking things in it) but that's best alleviated by only doing it once and either caching it or persistently storing the cleaned and rendered output.
Also, the check uses try: requests.head() except requests.exceptions.ConnectionError: as the method to see if the domain works. I considered doing a
whois lookup or something but that felt a little wrong because just because a domain exists doesn't mean there's a website there. Either way, it could be that the domain/URL is perfectly fine but in that very unlucky instant you checked your own server's internet or some other DNS lookup thing is busted. Perhaps wrapping it in a retry and doing try: requests.head() except requests.exceptions.RetryError: instead.
Lastly, the business logic I chose was to rewrite all http:// to https:// only if the URL http://domain does a 301 redirect to https://domain. So if the original link was http://bit.ly/redirect-slug it leaves it as is. Perhaps a fancier version would be to look at the domain name ending. For example HEAD http://google.com 301 redirects to https://www.google.com so you could use the fact that "www.google.com".endswith("google.com").
UPDATE Oct 10 2018
Moments after publishing this, I discovered a bug where it would fail badly if the text contained a URL with an ampersand in it. Turns out, it was a known bug in Bleach. It only happens when you try to pass a filter to the bleach.Cleaner() class.
So I simplified my code and now things work. Apparently, using bleach.Cleaner(filters=[...]) is faster so I'm losing that. But, for now, that's OK in my context.
Also, in another later fix, I improved the function some more by avoiding non-HTTP links (with the exception of mailto: and tel:). Otherwise it would attempt to run requests.head('ssh://server.example.com') which doesn't make sense.
