Book Image

Python Web Development with Sanic

By : Adam Hopkins
Book Image

Python Web Development with Sanic

By: Adam Hopkins

Overview of this book

Today’s developers need something more powerful and customizable when it comes to web app development. They require effective tools to build something unique to meet their specific needs, and not simply glue a bunch of things together built by others. This is where Sanic comes into the picture. Built to be unopinionated and scalable, Sanic is a next-generation Python framework and server tuned for high performance. This Sanic guide starts by helping you understand Sanic’s purpose, significance, and use cases. You’ll learn how to spot different issues when building web applications, and how to choose, create, and adapt the right solution to meet your requirements. As you progress, you’ll understand how to use listeners, middleware, and background tasks to customize your application. The book will also take you through real-world examples, so you will walk away with practical knowledge and not just code snippets. By the end of this web development book, you’ll have gained the knowledge you need to design, build, and deploy high-performance, scalable, and maintainable web applications with the Sanic framework.
Table of Contents (16 chapters)
1
Part 1:Getting Started with Sanic
4
Part 2:Hands-On Sanic
11
Part 3:Putting It All together

Paths, slashes, and why they matter

Way back in the stone age when the internet was invented, if you navigated to a URL, you were literally being delivered a file that existed on a computer somewhere. If you asked for /path/to/something.html, the server would look in the /path/to directory for a file called something.html. If that file existed, it would send it to you.

While this does still exist, times have certainly changed for many applications. The internet is still largely based upon this premise, but often a generated document is sent instead of a static document. It is helpful to still keep this mental model in your head though. Thinking that a path on your API should lead to a resource of some kind will keep you away from certain API design flaws. Let's look at an example:

/path/to/create_something  << BAD
/path/to/something         << GOOD

Your URI paths should use nouns, not verbs. If we want...