Databases

How To Include Redis In Your Application Architecture - Episode 201

Summary

The Redis database recently celebrated its 10th birthday. In that time it has earned a well-earned reputation for speed, reliability, and ease of use. Python developers are fortunate to have a well-built client in the form of redis-py to leverage it in their projects. In this episode Andy McCurdy and Dr. Christoph Zimmerman explain the ways that Redis can be used in your application architecture, how the Python client is built and maintained, and how to use it in your projects.

Announcements

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • When you’re ready to launch your next app or want to try a project you hear about on the show, you’ll need somewhere to deploy it, so take a look at our friends over at Linode. With 200 Gbit/s private networking, scalable shared block storage, node balancers, and a 40 Gbit/s public network, all controlled by a brand new API you’ve got everything you need to scale up. Go to pythonpodcast.com/linode to get a $20 credit and launch a new server in under a minute. And don’t forget to thank them for their continued support of this show!
  • And to keep track of how your team is progressing on building new features and squashing bugs, you need a project management system designed by software engineers, for software engineers. Clubhouse lets you craft a workflow that fits your style, including per-team tasks, cross-project epics, a large suite of pre-built integrations, and a simple API for crafting your own. Podcast.__init__ listeners get 2 months free on any plan by going to pythonpodcast.com/clubhouse today and signing up for a trial.
  • Visit the site to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions I would love to hear them. You can reach me on Twitter at @Podcast__init__ or email [email protected])
  • To help other people find the show please leave a review on iTunes and tell your friends and co-workers
  • Join the community in the new Zulip chat workspace at pythonpodcast.com/chat
  • You listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis. For even more opportunities to meet, listen, and learn from your peers you don’t want to miss out on this year’s conference season. We have partnered with O’Reilly Media for the Strata conference in San Francisco on March 25th and the Artificial Intelligence conference in NYC on April 15th. Here in Boston, starting on May 17th, you still have time to grab a ticket to the Enterprise Data World, and from April 30th to May 3rd is the Open Data Science Conference. Go to pythonpodcast.com/conferences to learn more and take advantage of our partner discounts when you register.
  • Your host as usual is Tobias Macey and today I’m interviewing Andy McCurdy and Christoph Zimmerman about the Redis database, and some of the various ways that it is used by Python developers

Interview

  • Introductions
  • How did you get introduced to Python?
  • Can you start by explaining what Redis is and how you got involved in the project?
  • How does the redis-py project relate to the Redis database and what motivated you to create the Python client?
  • What are some of the main use cases that Redis enables?
  • Can you describe how Redis-py is implemented and some of the primitives that it provides for building applications on top of?
    • How do the release cycles of redis-py and the Redis database relate to each other?
    • How closely does redis-py match the features of the Redis database?
    • What are some of the convenience methods or features that you have added to make the client more Pythonic?
  • Redis is often used as a key/value cache for web applications, in some cases replacing Memcached. What are the characteristics of Redis that lend themselves well to this purpose?
    • What are some edge cases or gotchas that users should be aware of?
  • What are some of the common points of confusion or difficulties when storing and retrieving values in Redis?
  • What have been some of the most challenging aspects of building and maintaining the Redis Python client?
  • What are some of the anti-patterns that you have seen around how developers build on top of Redis?
  • What are some of the most interesting or unexpected ways that you have seen Redis used?
  • What are some of the least used or most misunderstood features of Redis that you think developers should know about?
  • What are some of the recent and near-future improvements or features in Redis that you are most excited by?

Keep In Touch

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

Event Sourcing with John Bywater - Episode 131

Summary

The way that your application handles data and the way that it is represented in your database don’t always match, leading to a lot of brittle abstractions to reconcile the two. In order to reduce that friction, instead of overwriting the state of your application on every change you can log all of the events that take place and then render the current state from that sequence of events. John Bywater joins me this week to discuss his work on the Event Sourcing library, why you might want to use it in your applications, and how it can change the way that you think about your data.

Preface

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • I would like to thank everyone who supports the show on Patreon. Your contributions help to make the show sustainable.
  • When you’re ready to launch your next project you’ll need somewhere to deploy it. Check out Linode at podastinit.com/linode and get a $20 credit to try out their fast and reliable Linux virtual servers for running your awesome app. And now you can deliver your work to your users even faster with the newly upgraded 200 GBit network in all of their datacenters.
  • If you’re tired of cobbling together your deployment pipeline then it’s time to try out GoCD, the open source continuous delivery platform built by the people at ThoughtWorks who wrote the book about it. With GoCD you get complete visibility into the life-cycle of your software from one location. To download it now go to podcatinit.com/gocd. Professional support and enterprise plugins are available for added piece of mind.
  • Visit the site to subscribe to the show, sign up for the newsletter, and read the show notes. And if you have any questions, comments, or suggestions I would love to hear them. You can reach me on Twitter at @Podcast__init__ or email [email protected]
  • To help other people find the show please leave a review on iTunes, or Google Play Music, tell your friends and co-workers, and share it on social media.
  • Your host as usual is Tobias Macey and today I’m interviewing John Bywater about event sourcing, an architectural approach to make your data layer easier to scale and maintain.

Interview

  • Introductions
  • How did you get introduced to Python?
  • Can you start by describing the concept of event sourcing and the benefits that it provides?
  • What is the event sourcing library and what was your reason for starting it?
  • What are some of the reasons that someone might not want to implement an event sourcing approach in their persistence layer?
  • Given that you are storing a record for each event that occurs on a domain object, how does that affect the amount of storage necessary to support an event sourced application?
  • What is the impact on performance and latency from an end user perspective when the application is using event sourcing to render the current state of the system?
  • What does the internal architecture and design of your library look like and how has that evolved over time?
  • In the case where events are delivered out of order, how can you ensure that the present view of an object is reflected accurately?
  • For someone who wants to incorporate an event sourcing design into an existing application, how would they do that?
  • How do you manage schema changes in your domain model when you need to reconstruct present state from the beginning of an objects event sequence?
  • What are some of the most interesting uses of event sourcing that you have seen?
  • What are some of the features or improvements that you have planned for the future of you event sourcing library?

Keep In Touch

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA

Moving to MongoDB with Michael Kennedy - Episode 119

Summary

There are dozens of decisions that need to be made when building an application. Sometimes this can lead to analysis paralysis and prevent you from making progress, so don’t let the perfect be the enemy of the good. This week Michael Kennedy shares his experience with evolving his application architecture when his business needs outgrew his initial designs.

Preface

  • Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
  • I would like to thank everyone who supports us on Patreon. Your contributions help to make the show sustainable.
  • When you’re ready to launch your next project you’ll need somewhere to deploy it. Check out Linode at www.podastinit.com/linode and get a $20 credit to try out their fast and reliable Linux virtual servers for running your awesome app.
  • Visit the site to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch.
  • To help other people find the show please leave a review on iTunes, or Google Play Music, tell your friends and co-workers, and share it on social media.
  • Your host as usual is Tobias Macey and today I’m interviewing Mike Kennedy about his work scaling his apps and his business

Interview

  • Introductions
  • How did you get introduced to Python?
  • In some of your recent episodes you have mentioned the work that you did to migrate your applications to run on MongoDB. Can you start by describing the business case for these applications and how you arrived at the initial design?
  • What was the limiting factor that led you to consider such a drastic shift in how you store and manage your data and what benefits did you gain when the work was complete?
    • If the issue was with scaling, how did you identify the choke points?
    • Why go from relational (SQLite) to document (Mongo) instead of what would seem a more obvious choice of a production grade relational engine such as PostGreSQL or MySQL?
  • Are there any particular synergies that arise from using a document as opposed to a relational store when working with Python and what are some of the main considerations when deciding between them?
  • What was happening in your business that precipitated the need for this work?
  • How are you talking to MongoDB from Python? Directly (via pymongo) or ORM-style?
    • Why did you make that choice?
    • How well is that working out? Advantages / drawbacks?
  • In addition to podcasting you have also been working to create a number of successful courses to teach people how to use Python. Is there anything specific to the language that translates into how you design the material?
  • For anyone who wants to learn more about the benefits and tradeoffs of using a document store with their Python applications, what are some resources that you recommend?

Keep In Touch

Picks

Links

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA