Last time we discussed the Fetch API in general, taking a look at how it differed from the XMLHttpRequest API, and some of its advantages. Today, we’re going to take a look at a little library that you can include in your projects today that offers you localStorage caching for the Fetch API.
Long ago, we briefly brushed upon the topic of what has made jQuery such a valuable part of the web developer’s toolset for such a long time – namely, a cleaner interface for interacting with the DOM, and the $.ajax abstraction over XMLHttpRequest.
These days, I would go a step farther and discuss how it has positively influenced browser APIs. jQuery offered a way to find elements using their css selectors, and this eventually gave us
. More recently, browser developers have taken another page from jQuery’s playbook and introduced a new, Promise-based API for making asynchronous requests, and so much more – Fetch.
Why go Fetch? Let’s take a look.
Last time, we decided to embark on a brave new adventure and give our Django framework a big upgrade with the inclusion of Django Channels. We got just far enough to get the development server running, but while this may be an adequate start, it’s better to develop against something like what we intend to deploy, right?
So, let’s go the rest of the way and get ready to develop against something that at least resembles a standard production-ready environment with Django Channels.
You stare mournfully into the mass of code you’ve inherited. At some point, it’s clear, the requirements called for the server to push information to the client, because there’s an unholy mix of Server-Side Events, long-polling, hidden iframes and even a Java applet in there, all supporting some level of long-term connectivity with the server. It’s almost fascinating in its barely functional hideousness, and you would be inclined to leave well enough alone… except for the new feature specifications you’ve been assigned, which require the client to be able to send data back to the server in response to the received events, in as close to real-time as you can get.
It’s time for a major overhaul. Only Websockets can save us now. And, as it so happens, one of your favourite frameworks just added support for real-time, bi-directional communication…
You’ve built the web application of the century, and the users have rightly flooded to it. Cat pictures for everyone!
But alas, while your users indulge in cat-induced bliss, the cold hard reality of server costs cannot help but harsh your mellow. What is to be done?
Maybe, you could get the users to… pay for access to your incredible web application in all its multivarious splendour?
Braintree is a payment processor (now a subsidiary of PayPal), which boasts of a “simple, robust way to accept payments”, and with features like a drop-in payment ui and libraries for various programming languages enabling fairly easy integration, is a solid choice for accepting payments via credit card or PayPal.
While Braintree’s developer documentation is blessedly detailed, it’s possessed of a potentially confusing bevy of options, and its various implementation examples are spread out amongst a number of pages and platforms. So today, rather than reiterate any particular section of the docs, we’re going to take a look at an end-to-end example of a specific, straightforward scenario – accepting and processing a one-time, immediately settled payment in a web application.