DEV Community: Basstardd

The Security Lindy Effect: What Smart Contracts Can Teach Us About Software Security in the Age of AI

Basstardd — Tue, 14 Apr 2026 08:14:37 +0000

There has always been something uniquely harsh about smart contracts.

The obvious reason is that mistakes are extremely costly. Once deployed, bugs are not just bugs—they are financial vulnerabilities that hurts a lot!

Smart contracts operate in one of the most hostile environments in software engineering. From the moment they go live, they are exposed to a global pool of adversaries with unlimited time and strong incentives to break them. Every line of code is continuously tested by attackers. There is no gradual feedback loop. You do not get gentle warnings. You only find out when it is too late.

This creates a form of evolutionary pressure on software. Contracts that survive in the wild, unexploited over time, gain credibility and a bit of fame (think Uniswap contracts). Those that fail disappear quickly. In that sense, they follow something close to a security Lindy effect: survival becomes a proxy for correctness.

It is a brutal way to build reliable systems, but it works.

What is changing now is that this kind of pressure is no longer limited to smart contracts or a small subset of critical open-source systems.

With the rise of AI, the attack surface of software is being fundamentally transformed. Systems are no longer probed only by human actors. Instead, they are increasingly exposed to automated, persistent, and scalable analysis. Autonomous agents can scan codebases, test APIs, explore edge cases, and search for vulnerabilities continuously. What used to require time, skill, and coordination can now be executed at scale.

This effectively turns most software into something closer to a smart contract environment. Constant exposure. Continuous probing. No safe assumptions.

This shift understandably creates concern. It increases the likelihood that weak systems will be discovered and exploited faster. It raises the cost of building and maintaining secure software. It removes the illusion that systems can remain partially broken and still function indefinitely.

However, there is another side to this transformation.

The same capabilities that enable offensive pressure can also be used defensively. AI does not only scale attacks; it also scales review, analysis, and improvement. It allows teams to continuously inspect their own systems with a level of persistence and breadth that was previously unrealistic.

In practice, this means that hardening can become an ongoing process rather than a one-time effort.

In my own workflow, I already treat AI as a defensive layer. Each night, using the remaining quota of daily tokens, I run a set of autonomous agents over our codebase. These agents scan for bugs, inconsistencies, and potential security vulnerabilities. They also compare the implementation against known best practices and architectural patterns, and generate concrete suggestions for improvement. The output is collected in a dedicated location, effectively creating a continuous stream of recommendations for hardening the system.

This is not perfect, and it does not replace human judgment. But it changes the baseline. Instead of occasional reviews, the system is subjected to constant internal pressure that mirrors, in a controlled way, the external pressure it will face in production.

Seen from this perspective, what we are entering is not only a more dangerous environment, but also a more honest one.

Weak systems will fail faster. Strong systems will emerge more clearly. Over time, this leads to a kind of large-scale hardening of software. Poor assumptions, fragile architectures, and hidden inconsistencies are less likely to survive prolonged exposure.

Smart contracts and open source are the first widely adopted systems forced to operate under continuous adversarial pressure. They showed that this pressure, while costly, leads to a different standard of thinking about correctness and security.

AI is now extending that pressure to the rest of the software world—surfacing vulnerabilities and bugs that have been hidden in plain sight, sometimes for decades.

The result will not be a collapse in security. More probable scenario, painful hardening. On the other side of it? Possibly better software.

Taming complexity: programming abstractions, epistemic boundaries, and our right to be ignorant!

Basstardd — Wed, 18 Mar 2026 08:13:34 +0000

Programming is complicated! Software stacks are deep, layered, and complex. Human cognitive abilities, time, and energy are limited. And then the central question for each programmer wrestling with this situation becomes: how can we be productive in this endlessly complex computing universe?

The answer is deceptively simple: hide complexity behind abstractions! Hide complexity behind walls of public interfaces. Layer these kinds of abstractions one onto another as a kind of stack, and you get the modern computing world. Layer upon layer. Each allows us to live in blissful ignorance and to be productive without knowing every layer that sits below or above us!

These boundaries are “epistemic,” not physical. They allow us to use the ls command without knowing anything about syscalls. They allow you to write a full-fledged Python program without ever knowing about C or CPU instruction sets—or, God forbid, assembly. They allow you to make a request and never know what is going on between the moment you send it and when you receive a nicely formatted JSON response.

And this has been the main strategy we have used to tame computing complexity all these years. A very successful recipe—just look at the world around you.

Of course, as you may guess at this point, the main enemy of this new computing order is the “leaky abstraction.” An abstraction that allows internal problems to escape into the outside world and confuse our good programmers, who stare at errors as if they were written by some alien intelligence! A sure sign that they are confronting things produced by something non-terrestrial! Strange words, never-heard-before terms—signals of new territory.

And then we are forced to acknowledge that there is a whole underworld beneath us, with its own mechanisms and complexities.

But this pattern is not unique to programming.

Scientific disciplines are exactly the same move. Physics, chemistry, biology, psychology, sociology—these aren't natural categories carved at the joints of reality. They're epistemic partitions imposed because no single human mind can reason from quarks to civilizations in one pass. A biologist studies cell signaling without solving Schrödinger's equation for every electron involved. A sociologist studies institutional behavior without modeling individual neurons. Each discipline is an abstraction layer that says, “you can reason productively at this level without understanding the level below.”

And the interfaces between disciplines work the same way as APIs. Chemistry exposes a certain contract to biology—“here’s how molecules bond, here are reaction kinetics”—and biology consumes that interface without caring about quantum mechanics. The contract is: these regularities hold at your level. Don’t look underneath unless something breaks.

The leaky abstraction problem exists in science too. That’s literally what happens at interdisciplinary boundaries. A biologist hits a problem that can't be solved with biological vocabulary alone—suddenly you need biophysics, or biochemistry. The epistemic boundary has leaked. You're forced into that same cognitive expansion across two worlds, exactly like a Python developer suddenly staring at C segfault traces.

This human way of wrestling with complexity is a hidden assumption and organizing principle of everything we build. Epistemic partitions are how complexity becomes digestible for our limited cognitive abilities. But now the big question is: what happens when those cognitive limitations are no longer the organizing principle? When they are lifted via AI?

Will we start to see entirely new type of systems and understanding emerging in a way fundamentally different from the layered abstraction model that human cognition demanded?

Ship as fast as possible! But not faster than that

Basstardd — Fri, 27 Feb 2026 10:34:23 +0000

With great love for the Anthropic team and Claude Code CLI, that I'm using on a daily level, a lot, I must say that their /worktree feature is just confusing.

Claude Code has a "worktree" feature, but it's not exactly worktree as you know it from git. They use the same name to deliver something much less useful, adding to confusion by giving it a slightly different nature. All in all — and to put it bluntly -- kind of bad design.

git worktree add is precise. You give it a path, a branch. Done. Run session in worktree. You control everything.

Claude Code's version creates a new branch you didn't ask for, hides it in .claude/worktrees/, doesn't let you pick the branch or location, and when the session ends — leaves everything behind. Orphaned branches, stale git metadata, empty directories.

The concept of worktree is used here in a strange way. The problem they're solving — isolating agent work from your current branch — is exactly what git worktree already does. One command. No magic.
If they just ran git worktree add under the hood and let you drive, it would actually be useful. Instead they built an abstraction that hides the one thing that made worktrees useful in the first place: you control it.

In my personal opinion it looks like Anthropic is starting to pay the price of shipping features at relentless speed. In the last month they've been hitting that wall often and learning the hard way. The desktop app is buggy all around the place — it literally breaks on a daily level in every imaginable way. And we're talking about one of the best product and dev teams in the world.

Maybe it's time to step back and rethink the shipping approach and quality guardrails in AI driven development. Because the current approach is giving people early draft versions full of half-baked features, which increases frustration and dissatisfaction with an otherwise loved product.

Now we can remix a bit one popular version of Einstein thought: "Everything should be made as simple as possible, but not simpler than that!" And in the context of new AI driven development we could say: "Dear Anthropic please ship as fast as possible! But not faster than that."

Practical advice skip /worktree. Use regular git worktree folder_name branch_name. Run claude code session in parallel worktree...

There is simplicity underneath complexity: detachable frames, Coroutines and Python Generators

Basstardd — Thu, 19 Feb 2026 13:27:20 +0000

Every Python developer learns early: you call a function, it runs, it returns. Simple. And for most of your career, that model holds.

Until you hit async def. Until you hit yield. Until something suspends and resumes and you're not quite sure what's keeping state alive between those moments.

There's a single mechanism underneath all of it. One trick that Python learned in 2001 and has been reusing ever since. Once you see it, generators, coroutines, and async generators all collapse into variations of the same idea.

That mechanism is the detachable frame.

What Is a Frame?

Before we can detach a frame, we need to know what one is.

Every time Python calls a function, it creates a frame object. This is a real thing — not a metaphor, not an abstraction. It's a C struct in CPython, and you can inspect it from Python:

import sys

def show_frame():
    frame = sys._getframe()
    print(f"locals:  {frame.f_locals}")
    print(f"code:    {frame.f_code.co_name}")
    print(f"line:    {frame.f_lineno}")
    print(f"caller:  {frame.f_back.f_code.co_name}")

show_frame()

A frame holds everything a function needs to execute:

f_locals — the local variables (x = 1 lives here)
f_code — pointer to the code object (the bytecode blueprint)
f_lasti — the last bytecode instruction executed (where we are)
f_back — pointer to the calling frame (the chain back up)

Frames live on the call stack. When you call a function, its frame gets pushed on top. When the function returns, its frame gets popped off. That's the fundamental rhythm of execution in Python. Quite simple: add, execute, return, pop. That's it! All superficial complexity of your programs comes down to this simple data structure, stack! Add, execute, return, pop.

But here's the question: what happens to the frame after it's popped?

The One-Shot Frame

For a normal function, the answer is simple. It dies.

def add(a, b):
    return a + b

result = add(1, 2)

The lifecycle:

add(1, 2) is called — frame created, pushed onto the call stack
f_locals gets {'a': 1, 'b': 2}
Bytecode executes: LOAD_FAST a, LOAD_FAST b, BINARY_OP +, RETURN_VALUE
Frame popped off the stack — destroyed

call add(1,2) → frame ON stack → execute → return → frame DESTROYED

One shot. The frame goes on, does its job, comes off, and it's gone forever. You can't get back to it. The locals are gone. The instruction pointer is gone. Everything that function was while it was running — gone.

This is how most people think all functions work. Create, run, destroy.

And for normal functions, they're right.

In general Python has exactly four types of functions.

def add(a, b):              # 1. Normal function
    return a + b

def counter():              # 2. Generator function
    yield 1
    yield 2

async def fetch_user(id):   # 3. Coroutine function
    return await db.query(id)

async def stream(ids):      # 4. Async generator function
    for id in ids:
        yield await db.query(id)

Two binary toggles — has async? has yield in the body? — give you a 2x2 matrix:

                No yield            Has yield
             ─────────────────   ─────────────────
No async     Normal function     Generator
Has async    Coroutine           Async generator

The compiler decides which type at compilation time. Sets a flag in co_flags. That's it.

The normal function is the one we just saw — one-shot frame, create, run, destroy. The other three? They all break that model in the same way. And that way has been available since 2001.

What If the Frame Could Survive?

Now imagine a different rule. What if, when a function gives up control, its frame doesn't die? What if it gets popped off the call stack but keeps living — in the heap (part of memory), with all its locals intact, its instruction pointer remembering exactly where it stopped?

And what if you could push it back onto the stack later and pick up right where you left off?

That's what I'm calling a detachable frame. You won't find this term in the CPython docs — but the mechanism is there. The CPython internals describe how generator and coroutine frames are embedded directly in their objects on the heap, rather than living and dying on the call stack like normal function frames. The concept is real. I'm just giving it a name.

And Python has had them since 2001.

The Detachable Frame: Generators

def counter():
    x = 1
    yield x
    x = 2
    yield x
    return "done"

When you call counter(), Python does something unexpected — it doesn't execute the body. It creates a generator object, allocates a frame, attaches the frame to the object, and hands it back to you. Not a single line of the body has run.

g = counter()           # body does NOT execute
type(g)                 # <class 'generator'>
g.gi_frame              # a live frame object — it exists!
g.gi_frame.f_locals     # {} — empty, nothing has run yet
g.gi_frame.f_lasti      # -1 — instruction pointer at the very start

The frame is sitting in the heap, attached to g, waiting. Now you drive it:

next(g)                 # → 1

What happened:

The frame gets pushed onto the call stack
Execution starts from where f_lasti points
x = 1 runs
yield x fires — the value 1 is sent out to the caller
The frame gets popped off the call stack — but NOT destroyed
It goes back to the heap, attached to g, with all its state preserved

g.gi_frame.f_locals     # {'x': 1} — state preserved!
g.gi_frame.f_lasti      # advanced past the yield

Call next(g) again:

next(g)                 # → 2

Same dance. Frame goes on the stack, resumes from exactly where it left off, x = 2 runs, hits yield, frame comes off again.

One more:

next(g)                 # StopIteration("done")
g.gi_frame              # None — NOW it's destroyed

The frame went on and off the call stack three times before finally being destroyed on return. Between each trip, it sat in the heap, holding its locals, its instruction pointer, its entire execution state — alive but dormant.

One-shot frame:     ON → execute → OFF → destroyed
Detachable frame:   ON → OFF → ON → OFF → ON → OFF → destroyed

That's the whole trick. A frame that can leave the call stack and come back. Python learned this in 2001 with generators. And this — not async def, not await, not asyncio — is the mechanism that makes async Python possible.

The Two-Way Door

There's more. yield isn't just an exit — it's a door that swings both ways.

def ping_pong():
    received = yield "first"        # send "first" out, pause, wait for input
    print(f"got: {received}")
    received = yield "second"       # send "second" out, pause, wait for input
    print(f"got: {received}")
    return "done"

g = ping_pong()
val = next(g)               # → "first"   (value comes OUT)
val = g.send("hello")       # → "second"  (prints: got: hello — value goes IN)
g.send("world")             # → StopIteration("done")  (prints: got: world)

yield sends a value out and pops the frame off. .send() pushes the frame back on and delivers a value in. Two-way communication through a suspended frame.

             yield x                   send(y)
Generator ──────────────→ Caller    Caller ──────────────→ Generator
           "here's x,                "here's y,
            your turn"                your turn"

Read that twice. This bidirectional channel — yield out, send in, through a detachable frame — is the entire foundation of Python's async system.

The Repackaging

Now the part that should make you pause.

In 2013, Python 3.4 introduced asyncio. It used generators for async I/O. Not a new mechanism — plain generators with yield from:

# Python 3.4 — this is how async worked before async existed
@asyncio.coroutine
def fetch_data():
    data = yield from asyncio.sleep(1)
    return data

Generator suspends → event loop takes control → I/O completes → event loop calls .send() → generator resumes.

Same detachable frame. Same .send() protocol. The event loop was just a fancy caller doing next() and .send() based on I/O readiness instead of iteration needs.

It worked. But it was confusing — is this generator producing values or doing async I/O? The syntax doesn't tell you. You had to squint.

So in 2015, Python 3.5 introduced async def / await (PEP 492). And here's the thing — no new frame machinery was built. None. The detachable frame mechanism is identical. What changed:

A new type. Coroutine objects are not generator objects. Different type, different name.

Renamed attributes. Same internals, new labels:

Generator              Coroutine
─────────              ─────────
g.gi_frame      →      coro.cr_frame
g.gi_code       →      coro.cr_code
g.gi_running    →      coro.cr_running
g.gi_yieldfrom  →      coro.cr_await

Guardrails. You can't accidentally mix them up anymore:

for x in my_coroutine()     # TypeError!
await my_generator()         # TypeError!

One flag. One bit in co_flags:

Normal function:  co_flags = 0b0000_0011
Async function:   co_flags = 0b1000_0011
                               ^
                               CO_COROUTINE — this one bit

When the VM sees this flag at call time, it says: "don't execute the body, wrap it in a coroutine object." Same thing it does for generators with CO_GENERATOR. Same logic, same mechanism.

That's it. async/await is a repackaging of generator frame suspension with type safety and clearer intent. New clothes on an old engine.

The Only Difference That Matters

If the engine is the same, what's actually different?

Who calls .send() to put the frame back on the stack.

That's it. That's the whole thing.

Generator:        YOUR code calls next()/send()      — you decide when to resume
Coroutine:        EVENT LOOP calls .send()            — the orchestrator decides
Async generator:  BOTH take turns                     — two drivers, one frame

The frame doesn't know or care who wakes it up. It gets pushed on the stack, runs until it suspends, gets popped off, and waits. The driver is external to the mechanism.

A generator suspends at yield and waits for your code to ask for the next value. A coroutine suspends at await and waits for the event loop to signal that I/O is ready. Same suspension. Different reason. Different caller.

You can prove this to yourself right now. Drive a coroutine manually, without any event loop:

async def simple():
    return 42

coro = simple()
try:
    coro.send(None)          # YOU are the event loop
except StopIteration as e:
    print(e.value)           # 42

.send(None) pushes the frame on the stack, the body executes, return 42 triggers StopIteration with the value. Same protocol as generators. Because it is the same protocol.

The Async Generator: Both Reasons at Once

The fourth type in our matrix — async def with yield — creates something that suspends for two different reasons:

async def stream_data():
    data = await fetch()        # returns ["a", "b", "c"]
    for item in data:
        yield item
    data = await fetch()        # returns ["d", "e", "f"]
    for item in data:
        yield item

async for value in stream_data():
    print(value)

Trace the frame:

anext() → frame ON stack
  → hits await fetch()
  → frame OFF (reason: I/O — event loop will resume)

I/O returns → frame ON stack
  → data = ["a", "b", "c"], enters loop
  → yield "a"
  → frame OFF (reason: producing value — async for will resume)
  → consumer prints "a"

anext() → frame ON → yield "b" → frame OFF → prints "b"
anext() → frame ON → yield "c" → frame OFF → prints "c"

anext() → frame ON (loop ends, continues to next line)
  → hits await fetch()
  → frame OFF (reason: I/O — event loop resumes)

I/O returns → frame ON → yield "d" → frame OFF → prints "d"
anext() → frame ON → yield "e" → frame OFF → prints "e"
anext() → frame ON → yield "f" → frame OFF → prints "f"

anext() → frame ON → end of function → StopAsyncIteration → frame DESTROYED

Eight suspensions. Two for I/O, six for producing values. Two different drivers taking turns pushing the same frame back onto the stack. The frame doesn't care. It just does its thing.

The Full Picture

Four function types. One core mechanism. Three variations of it.

Normal function    → frame ON → execute → frame OFF → gone forever
                     one-shot, no suspension

Generator          → frame ON/OFF, driven by next()/for
                     suspends at: yield
                     purpose: produce values

Coroutine          → frame ON/OFF, driven by event loop
                     suspends at: await
                     purpose: wait for I/O

Async generator    → frame ON/OFF, driven by BOTH
                     suspends at: yield AND await
                     purpose: stream values with async I/O

The normal function is the simple case — frame created, used, destroyed. The other three all share the detachable frame: the frame leaves the call stack, survives in the heap, and comes back when someone calls .send().

They differ only in the answer to two questions:

Why did the frame suspend? To produce a value (yield), to wait for I/O (await), or both?

Who puts it back? Your code, the event loop, or both?

                    Why it suspends          Who resumes it
                    ──────────────           ──────────────
Generator           yield (value out)        your code
Coroutine           await (I/O wait)         event loop
Async generator     yield + await            both

That's the whole model. Everything else — asyncio, uvicorn, FastAPI's dependency injection, database connection pools — is built on top of this. Abstractions upon abstractions, all the way up. But at the bottom, there's a frame going on and off the call stack.

The Timeline

This didn't appear overnight. It was a twenty-year evolution:

Year What Happened	PEP
2001 Generators + `yield` — detachable frames are born	PEP 255
2005 `.send()` / `.throw()` — two-way communication	PEP 342
2012 `yield from` — delegation to sub-generators	PEP 380
2013 asyncio — generators repurposed for async I/O	PEP 3156
2015 `async def` / `await` — dedicated type and syntax	PEP 492
2016 Async generators — `yield` inside `async def`	PEP 525

Twenty years from detachable frames to the async ecosystem we use today. Not a revolution — an evolution. Each step built on the one before. The frame suspension mechanism from 2001 is still the same mechanism running your FastAPI handlers right now.

Pull back async/await and you find generators. Pull back generators and you find detachable frames. Pull back detachable frames and you find the simple insight that a function's state doesn't have to die when it gives up control.

That's the whole story.

All concepts in this post can be verified hands-on: create a coroutine, don't await it, inspect cr_frame, call .send() yourself. Drive it manually. Build a toy event loop in 20 lines. Once you see that an event loop is just "pick a frame, .send(), handle what it yields" — the magic evaporates and understanding takes its place.

UI Tectonic Plates are on the Move?

Basstardd — Mon, 29 Dec 2025 13:19:27 +0000

After 50 years, it looks like the UI tectonic plates are on the move.

Modern UI is the far cousin of ideas born in the famous Xerox PARC (Palo Alto Research Center) laboratory in the mid-70s. This was the place that invented concepts like windows, icons, menus, and pointers—the WIMP paradigm—as well as files, folders, and the trash can. And, equally famously, Xerox never succeeded in capitalizing on any of those inventions. Something that cannot be said for macOS, Windows, and every other modern OS that took "inspiration" from the Xerox lab at the time.

This UI paradigm was so successful that we haven't even been able to imagine an alternative. We took it for granted. It shaped how humans interact with machines for the last 50 years—from desktop to web to mobile apps. It just clicked with the way we do the things.

The Bottleneck We Stopped Seeing

However, this approach assumes a mouse and keyboard as the input devices. Step back and look at the keyboard: even if you're a blind typist and very fast, using a keyboard is akin to the speed of a dial-up modem. It's an obvious bottleneck in communication between our brains and machines.

We run around the screen searching for icons, clicking, and typing. And there's a feeling that this cannot be the final UI frontier. There must be a different, more natural, faster, and more intuitive way for humans to talk to machines.

And, you guessed it, there is: Voice.

The New Paradigm

If voice increasingly becomes the new brain-computer interface, what will this new UI paradigm look like?

My guess: it will look much more fluid and intuitive. You will just talk to the computer, and things will magically happen. The UI—with all its icons and windows—won't stand in the way of finishing your tasks. You ask, and it is done. This doesn't mean to say that typing will go away entirely, but it will become more on call when precision is needed.

What means something like this:

Voice: "Draft an email to Sarah about the Q4 results"
Keyboard: Fine-tuning the wording, fixing a specific sentence
Voice: "Send it"

Let's imagine a classic CRM application through this new lens.

Old way:

Go to project page → Press menu → Check table → 
Find export option → Select format → Choose destination → 
Enter file name → Confirm

New way:

"Export the Acme project data to my desktop."
"What should I call the file?"
"Q4-summary."
Done.

You don't navigate to a project page, press a menu, and scan a table. You simply ask the machine what you want—and voilà, it's there for you.

That's the shift. Things just happen. And the interface? It gets out of the way.

The Two-Field Mental Model: What Python Frameworks actually Hide From You?

Basstardd — Mon, 22 Dec 2025 13:42:35 +0000

Frameworks hide imperative complexity behind declarative simplicity. That's fine—until it isn't. And this is the price we pay for comfort and convenience. When abstractions leak, understanding the machinery underneath becomes non-optional. But in most of cases we are just staring at the wall of unintelligible framework code. And that is a kind of a problem....

You write @pytest.fixture. Pytest auto-magically handles the rest.

You write async def. FastAPI and Uvicorn's event loop figures out the rest.

You write Column(String). SQLAlchemy maps it to your database. It allows you to define class attributes but actually wait, they are class instance attributes at the end? Did we just break Python? No, just a bit of masking that allows app devs to practice declarative programming without thinking about the inner workings of the framework or library.

This is the basic deal we make with frameworks and libraries: we declare what we want, and they handle how it happens. This is mainly a good deal—until your fixture mysteriously runs twice, and you end up scratching your head without a clue what could possibly go wrong. At that point, "the framework will handles it" becomes "I have no idea what's going on?"

About Two Fields

Most Python libraries/frameworks operate on two distinct layers:

Layer	Nature	You See It?
Observable Field	Declarative	Yes—this is your code
Hidden Field	Imperative	No—this is the machinery

Declarative = expressing what you want (intent, structure, outcome)
Imperative = executing how it happens (step-by-step machinery)

The observable field is comfortable. The hidden field is where bugs live.

Seeing Through the Abstraction

Let's pull back the curtain on three common patterns.

1. Async/Await with FastAPI-Uvicorn

What you write:

@app.get()
async def fetch_data():
    return await db.query()

Clean. Declarative. "Fetch data asynchronously."

What actually happens:

coro = fetch_data()        # Creates a coroutine object (not executed yet!)
await coro                  # Event loop: schedule, suspend, resume, complete

The async def doesn't run your function—it creates a coroutine object. That object implements the coroutine protocol (__await__, send(), throw()). The event loop drives execution by repeatedly calling send() until completion.

At the level of FastAPI, you define an async router and path—and that's it. Under the hood, this coroutine obj have life on its own! Function needs to be converted into a coroutine object and managed by the event loop. All this happens somewhere deep underground where the majority of devs never dare to go.

2. Pytest Fixtures

What you write:

@pytest.fixture
def db_session():
    session = create_session()
    yield session
    session.close()

Elegant. Setup, provide value, teardown.

What actually happens:

gen = fixture_func()       # Generator object created
value = next(gen)          # __next__ called → setup runs → value yielded
# ... your test executes with 'value' ...
next(gen)                  # Resumes after yield → cleanup runs → StopIteration

That yield isn't magic—it's part of the generator function and iterator protocol. Pytest calls this generator function, gets a generator, advances it to get your fixture value, runs your test, then advances it again to trigger cleanup (which ends with StopIteration).

Here it's important to notice one "creative misuse" of generators. This is a clever use of yield—not for its intended purpose (iterating multiple values), but specifically to exploit its suspend/resume behavior for cleanup.

If you look semantically, return would be more appropriate for "give back one value." But return can't do cleanup, so we "abuse" yield for its superpower: pausing execution and resuming later.

# What we WANT semantically:
def fixture():
    resource = setup()
    return resource      # ← more appropriate for "one value"
    cleanup(resource)    # ← but this is impossible

# What we MUST do:
def fixture():
    resource = setup()
    yield resource       # ← "creative" use, not really iterating
    cleanup(resource)    # ← now this works!

By the way, this pattern is so common it has a name: "generator-based resource management" or "generator-based context managers."

Now back to main article thread =>

In short, you can live long and happy life at the surface level of the async fixture generator function, but underneath the surface a lot is happening. Pytest manages all of these details for you, allowing your test to run successfully with the context values it needs.

3. SQLAlchemy ORM

What you write:

class User(Base):
    name = Column(String)      # Looks like a class attribute

What actually happens:

# During class creation:
Column.__set_name__(User, 'name')    # Column captures its attribute name

# During instantiation:
user = User(name="Alice")
Column.__set__(user, "Alice")        # Descriptor intercepts assignment

# During access:
user.name
Column.__get__(user, User)           # Descriptor intercepts, returns from instance.__dict__

That name = Column(String) is a descriptor. When you access user.name, Python doesn't just return a value—it calls Column.__get__(). The Column object on the class orchestrates everything; actual data lives on the instance.

When this bites you: You try to access User.name expecting a default value, but get a Column object instead. Class-level access and instance-level access behave completely differently.

The Protocols Behind the Magic

The hidden field isn't random—it's systematic. Python's protocols are the machinery:

Descriptor Protocol → __get__, __set__, __set_name__
Iterator Protocol → __iter__, __next__
Context Manager Protocol → __enter__, __exit__
Coroutine Protocol → __await__, send(), throw()
Metaclass Machinery → __new__, __init_subclass__

Every framework you use is built on these. When you understand the protocols, you understand the frameworks.

Why This Matters

For debugging: When declarative code misbehaves, the bug lives in the hidden field. You can't debug what you can't see.

For mental models: Understanding protocols makes any library transparent. New framework? Same protocols, different application.

For API design: If you build libraries, this is your job—hiding imperative complexity behind declarative interfaces.

For mastery: There's a difference between using Python and understanding Python. The gap is the hidden field.

The Practical Takeaway

You don't need to memorize every protocol. You need to know they exist and where to look.

Next time something breaks:

Identify what abstraction you're using
Ask: "What protocol enables this?"
Look at what the machinery actually does

So is the deal worth it? Absolutely. Just know that someday you'll need to read the fine print.

Solid steel programming: blockchain and hardware programming

Basstardd — Wed, 28 Feb 2024 14:19:57 +0000

There are notable similarities between programming for hardware devices and programming for blockchain. Both operate within defined constraints and exhibit a deterministic nature. In hardware programming, one must work within the limitations of available energy and memory, acknowledging and adhering to these constraints. Similarly, blockchain programming faces constraints such as the upper gas limit, which restricts the number of computational steps that can be executed, with each step incurring a cost.
Solidity, the programming language for smart contracts on Ethereum, occupies a unique position within the realm of programming languages and technology. It blends the flexibility and expressiveness typical of Turing-complete languages, enabling the implementation of complex logic, with the robustness and rigidity characteristic of hardware programming. This amalgamation of flexibility during development and resilience in production gives rise to new kind of programming. Strange and interesting beast....

Web3 backend and smart contract development for Python developers Musical NFTs part 17: Deployment time!

Basstardd — Wed, 22 Nov 2023 21:27:48 +0000

Now we want to have our Django app up and running somewhere live for other people to see and use. In this version of our app we will use Google App engine.

First go to Google cloud and open your free account. Google will allocate some free resources automatically to your account and this will be more then enough for start. But also don't forget to go to billing part and to set some alerts when certain price thresholds are hit. Just to avoid any surprise.

Ones you are there search for App engine and create and select new MusicalNFT project.

In short what is Google App Engine (GAE)? It is a fully managed, serverless platform for developing and hosting web applications at scale. It has a powerful built-in auto-scaling feature, which automatically allocates more/fewer resources based on demand. GAE natively supports applications written in Python, Node.js, Java, Ruby, C#, Go, and PHP. Alternatively, it provides support for other languages via custom runtimes or Dockerfiles. It has powerful application diagnostics, which you can combine with Cloud Monitoring and Logging to monitor the health and the performance of your app. Additionally, GAE allows your apps to scale to zero, which means that you don't pay anything if no one uses your service.

In attempt to use GAE first we need to install Google Cloud CLI.
The gcloud CLI allows you to create and manage your Google Cloud resources and services. The installation process differs depending on your operating system and processor architecture. Go ahead and follow the official installation guide for your OS and CPU. => gcloud

To verify the installation has been successful, run:

$ gcloud version

Google Cloud SDK 415.0.0
bq 2.0.84
core 2023.01.20
gcloud-crc32c 1.0.0
gsutil 5.18

Now comes very important step: configuring Django Project to work with GEA. Till this moment we were working all the time in local dev environment, running all things (Postgres, Stripe, Django server, Celery etc.) on our machine. What we need to do now if we want our app to be live on GEA? First we need to configure our Django project and to tell to GEA that he need to run all those supporting services in the background for our app to be able to run smoothly. That is why let's open our Django settings.py

First thing we need to do is to erase defualt secrete keys. Then we will generate new one and pass to our .env file. And only then import inside our settings.py again.

Let's generate new secrete Django key:

   $py manage.py shell
    >>>from django.core.management.utils import get_random_secret_key
    >>>secret_key = get_random_secret_key()
    >>>print(secret_key)
    # and you will get some gibberish like this
    >>>^&p@m*nhn#hg6ujgri2sppxr7t8o^mfp3bnj%1%2f72wcr+kkz
    # now pass value you get into `.env` file name of varibale `DJANGO_SECRET_KEY`

Why we need secret key? In Django, a secret key plays a vital role in enhancing the security of our application. It helps manage user sessions, protects against Cross-Site Request Forgery (CSRF) attacks, and safeguards your data by generating and verifying cryptographic signatures among other things.

Now our Django settings should look something like this:

 from pathlib import Path
import os
from urllib.parse import urlparse

import environ
import io
import pyrebase
import firebase_admin
from firebase_admin import credentials
from google.cloud import secretmanager
from google.oauth2 import service_account


# Build paths inside the project like this: BASE_DIR / 'subdir'.
BASE_DIR = Path(__file__).resolve().parent.parent


env = environ.Env(DEBUG=(bool, False))
env_file = os.path.join(BASE_DIR, ".env")

if os.path.isfile(env_file):
    # read a local .env file
    env.read_env(env_file)
elif os.environ.get("GOOGLE_CLOUD_PROJECT", None):
    # pull .env file from Secret Manager
    project_id = os.environ.get("GOOGLE_CLOUD_PROJECT")
    client = secretmanager.SecretManagerServiceClient()
    settings_name = os.environ.get("SETTINGS_NAME", "django_setting_two")
    name = f"projects/{project_id}/secrets/{settings_name}/versions/latest"
    payload = client.access_secret_version(name=name).payload.data.decode("UTF-8")
    env.read_env(io.StringIO(payload))
else:
    raise Exception("No local .env or GOOGLE_CLOUD_PROJECT detected. No secrets found.")

SECRET_KEY = env("SECRET_KEY")
DEBUG = env("DEBUG")

Now set ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS, we can use the following code snippet from the GAE docs:

 APPENGINE_URL = env("APPENGINE_URL", default=None)

if APPENGINE_URL:
    # ensure a scheme is present in the URL before it's processed.
    if not urlparse(APPENGINE_URL).scheme:
        APPENGINE_URL = f"https://{APPENGINE_URL}"
    ALLOWED_HOSTS = [
        urlparse(APPENGINE_URL).netloc,
        APPENGINE_URL,
        "localhost",
        "127.0.0.1",
    ]
    CSRF_TRUSTED_ORIGINS = [APPENGINE_URL]
    # SECURE_SSL_REDIRECT = True
else:
    ALLOWED_HOSTS = ["*"]

This code fetches APPENGINE_URL from the environment (later we will add to our .env) and automatically configures ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS. Additionally, it enables SECURE_SSL_REDIRECT to enforce HTTPS.

Final version .env file should look something like this (we still don't have all values but just for information)

STRIPE_SECRET_KEY=sk_test_xxxxxxxxx
DENIS_PASS=xxxxxxx
ETHEREUM_NETWORK=maticmum
INFURA_PROVIDER=https://polygon-mumbai.infura.io/v3/xxxxxx
SIGNER_PRIVATE_KEY=xxxxxxx
MUSIC_NFT_ADDRESS=0x1D33a553541606E98c74a61D1B8d9fff9E0fa138
STRIPE_ENDPOINT=whsec_GExxxxxxx
OWNER=0x273f4FCa831A7e154f8f979e1B06F4491Eb508B6
DJANGO_SECRET_KEY='^&p@m*nhn#hg6ujgri2sppxr7t8o^mfp3bnj%1%2f72wcr+kkz'
DATABASE_URL=postgres://name:password!@localhost/musicalnft
# DATABASE_URL=postgres://name:password!@//cloudsql/musicnft-405811:europe-west1:musicnft-instance/musicalnft
GS_BUCKET_NAME=musicnft-bucket
APPENGINE_URL=https://musicnft-405811.ew.r.appspot.com/

later on we will populate all those values.

Don't forget to add the import at the top of the settings.py:

 from urllib.parse import urlparse

To use Postgres instead of SQLite, we first need to install the database adapter.

  $pip install psycopg2-binary==2.9.5
    $pip freeze > requirements.txt

To utilize DATABASE_URL with Django, we can use django-environ's db() method like so:

  #settings.py
    DATABASES = {'default': env.db()}

Now create DATABASE_URL in .env and pass some random value, later on we will set up this value properly. (in general format of this value will go as fallow:

postgres://USER:PASSWORD@//cloudsql/PROJECT_ID:REGION:INSTANCE_NAME/DATABASE_NAME)

What we want to do is to replace Django dev server (what is not recommended for any kind of production environment) with Gunicorn. But first what is Gunicorn and why we should want to replace Django default server? The Django development server is lightweight and easy to use, but it's not designed/reccomndent to handle production traffic. It's meant for use during development only. On the other hand, Gunicorn is a WSGI HTTP server that's designed for production use. It's robust, efficient, and can handle multiple requests simultaneously, which is crucial for a production environment.


    $pip install gunicorn==20.1.0
    $pip freeze > requirements.txt

Now very important app.yaml file. Google App Engine's app.yaml config file is used to configure your web application's runtime environment. The app.yaml file contains information such as the runtime, URL handlers, and environment variables.

Start by creating a new file called app.yaml in the project root with the following contents:

    # app.yaml

    runtime: python39
    env: standard
    entrypoint: gunicorn -b :$PORT musical_nft.wsgi:application

    handlers:
    - url: /.*
    script: auto

    runtime_config:
    python_version: 3

We defined the entrypoint command that starts the WSGI server.
There are two options for env: standard and flexible. We picked standard since it is easier to get up and running, is appropriate for smaller apps, and supports Python 3.9 out of the box.
Lastly, handlers define how different URLs are routed. We'll define handlers for static and media files later in the tutorial.

Now let's define .gcloudignore. A .gcloudignore file allows you to specify the files you don't want to upload to GAE when deploying an application. It works similarly to a .gitignore file.

Go ahead and create a .gcloudignore file in the project root with the following contents:

   # .gcloudignore

    .gcloudignore

    # Ignore local .env file
    .env

    # If you would like to upload your .git directory, .gitignore file, or files
    # from your .gitignore file, remove the corresponding line
    # below:
    .git
    .gitignore

    # Python pycache:
    __pycache__/

    # Ignore collected static and media files
    mediafiles/
    staticfiles/

    # Ignore the local DB
    db.sqlite3

    # Ignored by the build system
    /setup.cfg
    venv/

    # Ignore IDE files
    .idea/

    README_DEV.md
    celerybeat-schedule
    node_modules
    photos
    smart-contracts

Go ahead and initialize the gcloud CLI if you haven't already:

  $ gcloud init

gcloud CLI will ask you about mail and project you would like to associate with this project. It will offer to you all avaliable projects. Choose the one we created (MusciNFT) and gcloud will automatically set all the rest. What means from this point on when ever you deploy your Django app to Google App Engine it will be avalible under that project name.

To create an App Engine app go to your project root and run:

$gcloud app create

    # you will get something like this
    You are creating an app for project [musicnft-405811].
    WARNING: Creating an App Engine application for a project is irreversible and the region
    cannot be changed. More information about regions is at
    <https://cloud.google.com/appengine/docs/locations>.

    Please choose the region where you want your App Engine application located:

    [1] asia-east1    (supports standard and flexible)
    [2] asia-east2    (supports standard and flexible and search_api)
    [3] asia-northeast1 (supports standard and flexible and search_api)
    [4] asia-northeast2 (supports standard and flexible and search_api)
    [5] asia-northeast3 (supports standard and flexible and search_api)
    [6] asia-south1   (supports standard and flexible and search_api)
    [7] asia-southeast1 (supports standard and flexible)
    [8] asia-southeast2 (supports standard and flexible and search_api)
    [9] australia-southeast1 (supports standard and flexible and search_api)
    [10] europe-central2 (supports standard and flexible)
    [11] europe-west   (supports standard and flexible and search_api)
    [12] europe-west2  (supports standard and flexible and search_api)
    [13] europe-west3  (supports standard and flexible and search_api)
    [14] europe-west6  (supports standard and flexible and search_api)
    [15] northamerica-northeast1 (supports standard and flexible and search_api)
    [16] southamerica-east1 (supports standard and flexible and search_api)
    [17] us-central    (supports standard and flexible and search_api)
    [18] us-east1      (supports standard and flexible and search_api)
    [19] us-east4      (supports standard and flexible and search_api)
    [20] us-west1      (supports standard and flexible)
    [21] us-west2      (supports standard and flexible and search_api)
    [22] us-west3      (supports standard and flexible and search_api)
    [23] us-west4      (supports standard and flexible and search_api)
    [24] cancel
    Please enter your numeric choice:  11

    Creating App Engine application in project [musicnft-405811] and region [europe-west]....done.                       
    Success! The app is now created. Please use `gcloud app deploy` to deploy your first app.

Ok, now we need to set up our Postgres database inside Cloud SQL dashboard: https://console.cloud.google.com/sql/

Ones you are there create new instance and choose PostgresSQL (enable Compute Engine API if needed).

Now pass following values:

   Instance ID: musicnft-instance
    Password: Enter a custom password or generate it
    Database version: PostgreSQL 14
    Configuration: Up to you
    Region: The same region as your app
    Zonal availability: Up to you

You might also need to enable "Compute Engine API" to create a SQL instance.

Once the database has been provisioned, you should get redirected to the database details. Take note of the "Connection name".

Go ahead and enable the Cloud SQL Admin API by searching for "Cloud SQL Admin API" and clicking "Enable". We'll need this enabled to test the database connection. Here is a link (it will route you to your project): https://console.cloud.google.com/marketplace/product/google/sqladmin.googleapis.com

To test the database connection and migrate the database we'll use Cloud SQL Auth proxy. The Cloud SQL Auth proxy provides secure access to your Cloud SQL instance without the need for authorized networks or for configuring SSL.

First, authenticate and acquire credentials for the API:

$gcloud auth application-default login

Next, download Cloud SQL Auth Proxy and make it executable:

 wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 -O cloud_sql_proxy


    --2023-11-21 00:27:00--  https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64
    Resolving dl.google.com (dl.google.com)... 172.217.20.78, 2a00:1450:4017:800::200e
    Connecting to dl.google.com (dl.google.com)|172.217.20.78|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 19239740 (18M) [application/octet-stream]
    Saving to: ‘cloud_sql_proxy’

    cloud_sql_proxy               100%[===============================================>]  18.35M  1.22MB/s    in 13s     

    2023-11-21 00:27:13 (1.45 MB/s) - ‘cloud_sql_proxy’ saved [19239740/19239740]

    $chmod +x cloud_sql_proxy

After the installation is complete open a new terminal window and start the proxy with your connection details like so:

  $./cloud_sql_proxy -instances="PROJECT_ID:REGION:INSTANCE_NAME"=tcp:5432

Where basicaly PROJECT_ID:REGION:INSTANCE_NAME connection name you saved first time you created database

And you should see something like this:

 2023/11/21 00:31:03 current FDs rlimit set to 1048576, wanted limit is 8500. Nothing to do here.
    2023/11/21 00:31:04 Listening on 127.0.0.1:5432 for musicnft-405811:europe-west1:musicnft-instance
    2023/11/21 00:31:04 Ready for new connections
    2023/11/21 00:31:05 Generated RSA key in 135.901349ms

You can now connect to localhost:5432 the same way you would if you had Postgres running on your local machine.

Since GAE doesn't allow us to execute commands on the server, we'll have to migrate the database from our local machine.

Inside our .env file in the project root, with the required environment variables:

DATABASE_URL=postgres://DB_USER:DB_PASS@localhost/DB_NAME

    # Example `DATABASE_URL`:
    # DATABASE_URL=postgres://django-images:password@localhost/mydb

Now let's make migrations


    $python manage.py migrate

Create superuser

   $python manage.py createsuperuser

Ones you done with superuser you can move to secret manager. We used to have local .env file when we worked in local dev context. But because we are migrating now whole app into Google App Engine, we need to make our .env varibales present in cloud. And for this we will use Google secret manager.

Navigate to the Secret Manager dashboard (https://console.cloud.google.com/security/secret-manager?project=musicnft-405811) and enable the API if you haven't already. Next, create a secret named django_settings with the following content:


   DJANGO_SECRET_KEY='^&p@m*nhn#hg6ujgri2sppxr7t8o^mfp3bnj%1%2f72wcr+kkz'
    # local development
    # DATABASE_URL=postgres://ilija:Meripseli1986!@localhost/musicalnft
    # in cloud
    DATABASE_URL=postgres://ilija:Meripseli1986!@//cloudsql/musicnft-405811:europe-west1:musicnft-instance/musicalnft
    GS_BUCKET_NAME=django-music-nft


    # Example `DATABASE_URL`:
    DATABASE_URL=postgres://DB_USER:DB_PASS@//cloudsql/PROJECT_ID:REGION:INSTANCE_NAME/DB_NAME
    # postgres://django-images:password@//cloudsql/indigo-35:europe-west3:mydb-instance/mydb
    GS_BUCKET_NAME=django-images-bucket

Make sure to change DATABASE_URL accordingly. PROJECT_ID:REGION:INSTANCE_NAME equals your database connection details.

You don't have to worry about GS_BUCKET_NAME. This is just the name of a bucket we're going to create and use later.

Pip installl google-cloud-secret-manager==2.15.1


$pip install google-cloud-secret-manager==2.15.1
    $pip freeze > requirements.txt

To load the environment variables from Secret Manager we can use the following official code snippet:

  from pathlib import Path
    import os
    import environ
    from urllib.parse import urlparse
    import io # new
    from google.cloud import secretmanager # new



    # Build paths inside the project like this: BASE_DIR / 'subdir'.
    BASE_DIR = Path(__file__).resolve().parent.parent

    env = environ.Env(DEBUG=(bool, False))

    env_file = os.path.join(BASE_DIR, ".env")


    if os.path.isfile(env_file):
        # read a local .env file
        env.read_env(env_file)
        password = env("DENIS_PASS")
    elif os.environ.get('GOOGLE_CLOUD_PROJECT', None):
        # pull .env file from Secret Manager
        project_id = os.environ.get('GOOGLE_CLOUD_PROJECT')

        client = secretmanager.SecretManagerServiceClient()
        settings_name = os.environ.get('SETTINGS_NAME', 'django_settings')
        name = f'projects/{project_id}/secrets/{settings_name}/versions/latest'
        payload = client.access_secret_version(name=name).payload.data.decode('UTF-8')

        env.read_env(io.StringIO(payload))
    else:
        raise Exception('No local .env or GOOGLE_CLOUD_PROJECT detected. No secrets found.')

There is two new imports: io and secretmanager

Great! It's finally time to deploy our app. To do so, run:

 $ gcloud app deploy

    Services to deploy:

    descriptor:                  [C:\Users\Nik\PycharmProjects\django-images-new\app.yaml]
    source:                      [C:\Users\Nik\PycharmProjects\django-images-new]
    target project:              [indigo-griffin-376011]
    target service:              [default]
    target version:              [20230130t135926]
    target url:                  [https://indigo-griffin-376011.ey.r.appspot.com]


    Do you want to continue (Y/n)?  y

    Beginning deployment of service [default]...
    #============================================================#
    #= Uploading 21 files to Google Cloud Storage               =#
    #============================================================#
    File upload done.
    Updating service [default]...done.
    Setting traffic split for service [default]...done.
    Deployed service [default] to [https://indigo-griffin-376011.ey.r.appspot.com]

You can stream logs from the command line by running:

   $ gcloud app logs tail -s default

Open your web app in your browser and test if it works:


    $ gcloud app browse

If you get a 502 Bad Gateway error, you can navigate to Logs Explorer to see your logs.

If there's a 403 Permission 'secretmanager.versions.access' denied error, navigate to django_settings secret permissions and make sure the default App Engine service account has access to this secret. See solution on StackOverflow

And that is it! We have now our toy app fully up and running on Google app engine for world to see

Code can be found in this repo

p.s. whole this process is defined by great crew at testdrive.io High recommendation for all their writings!

Web3 backend and smart contract development for Python developers Musical NFTs part 16: Stripe integration

Basstardd — Tue, 21 Nov 2023 10:25:09 +0000

At this point we are almost done with our version of Musical NFT platform. What we still need to do is to allow credit card buyers to buy our NFTs with credit card and to deploy our app somewhere live.

Let's start with Stripe integrations fore credit card buyers. Update credit_card_user.html doc with buy button and Buy NFT name. Now creadit_card_user.html file inside root templates folder should look something like this

 <table class="table  table-hover">
        <thead class="table-dark">
        <tr>
            <th scope="col">Name</th>
            <th scope="col">Email</th>
            <th scope="col">Total no. NFTs</th>
            <th scope="col">Means of payment</th>
            <th scope="col">Buy NFT</th>
        </tr>
        </thead>
        <tbody>
        <tr>
            <td> {{ customer.first_name }} {{ customer.last_name }} </td>
            <td> {{ customer.email }} </td>
            <td> {{ customer.total_no_of_nfts }} </td>
            <td><form action="" method="post">
                {%csrf_token%}
                {{orderForm.as_p}}
                <input type="submit" value="Save" class="btn btn-secondary">
            </form>
            </td>        
            <td>
            <form action="" method="post">
                <label for="NFT">Number of NFTs</label>
                {%csrf_token%}
                <input  type="number" id="NFT" ><br>
                </form>
                <input  id="creditCard" type="submit" value="Buy" class="btn btn-secondary">
                </td>   
            </tr>
        </tbody>
        </table>        
        {% for card in metadata%}
        {% if forloop.counter0|divisibleby:3 %} <div class="row">{%  endif %}
        <div class="card m-5 p-2" style="width: 18rem;">
            {% load static %}
            <img src="{% static 'nft/'%}{{card.cover_file_name}}"  class="card-img-top" alt="..." width="50" height="200"/>
            <div class="card-body">
            <h5 class="card-title">{{card.name}}</h5>
            <br>
            <p class="card-text">{{card.description}}</p>
            </div>
        </div>
        {%  if forloop.counter|divisibleby:3 or forloop.last %}</div> {%  endif %}
        <br>
        {% endfor %}
        <p> credit card </p>

Let's pip install stripe python library.


    (env)$pip install stripe==5.5.0

Next, register for a Stripe account (if you haven't already done so) and navigate to the dashboard. Click on "Developers":

Then click on "API keys":

Each Stripe account has four API keys: two for testing and two for production. Each pair has a "secret key" and a "publishable key". Do not reveal the secret key to anyone; the publishable key will be embedded in the JavaScript on the page that anyone can see.

Currently the toggle for "Viewing test data" in the upper right indicates that we're using the test keys now. That's what we want.

Add to your .env file STRIPE_SECRET_KEY and pass there your secret keys from Stipe. Then at the end of Django settings.py add this to two new lines of code

STRIPE_SECRET_KEY = env("STRIPE_SECRET_KEY")
STRIPE_PUBLISHABLE_KEY = "pk_test_51MgCeMHGy7fyfctt4TIWxu6ev25bm5180LalTib2YAx2YmBe3IAWNxPHDMSUzn0tx7K4Mrq8aoKIQyzHc8TRWRGG00p8ePmfug" # here your publishable key

Finally, you'll need to specify an "Account name" within your "Account settings" at https://dashboard.stripe.com/settings/account:

Next, we need to create a product to sell.

Click "Products" and then "Add product":

Add a product name, enter a price, and select "One time":

Click "Save product".

Now flow should go something like this:

After the user clicks the purchase button we need to do the following:

Get Publishable Key
1) Send an XHR request from the client to the server requesting the publishable key
2) Respond with the key
3) Use the key to create a new instance of Stripe.js

Create Checkout Session
1)Send another XHR request to the server requesting a new Checkout Session ID
2)Generate a new Checkout Session and send back the ID
3)Redirect to the checkout page for the user to finish their purchase
4) Redirect the User Appropriately:
Redirect to a success page after a successful payment
Redirect to a cancellation page after a cancelled payment

Confirm Payment with Stripe Webhooks
1)Set up the webhook endpoint
2)Test the endpoint using the Stripe CLI
3)Register the endpoint with Stripe

Let's start => Get Publishable key:
Updated version of base.html:


    {% load static %}
    <!doctype html>
    <html lang="en">
    <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <title>Muscial NFT</title>
        <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-T3c6CoIi6uLrA9TneNEoa7RxnatzjcDSCmG1MXxSR1GAsXEV/Dwwykc2MPK8M2HN" crossorigin="anonymous">
        <script src="https://js.stripe.com/v3/"></script>  <!-- new -->
        <script type="text/javascript" src="{% static 'connect_wallet.js' %}"></script>
        <link rel="shortcut icon" type="image" href="{% static 'favicon.ico' %}" >
        <!-- <script type="module" src="{% static 'call_sc.js' %}"></script> -->
    </script>

    </head>
    <body onload="checkMetaMaskState()">
    <body>
        {% include "navbar.html"%}
        <div class="container ">       
        <br/>
        <br/>
        {% if messages %}
        {% for message in messages%}
        <div class="alert alert-warning alert-dismissible fade show" role="alert">
            {{ message }}
            <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
        </div>

        {% endfor%}
        {% endif %} 

        {% block content %}
        {% endblock content %}
        </div>
        </body>
        <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/js/bootstrap.bundle.min.js" integrity="sha384-C6RzsynM9kWDrMNeT87bh95OGNyZPhcTNXj1NW7RuBCsyN/o0jlpcV8Qyq46cDfL" crossorigin="anonymous"></script>
        <script src="https://cdn.ethers.io/scripts/ethers-v4.min.js"
        charset="utf-8"
        type="text/javascript"></script>
        <script type="text/javascript" src="{% static 'call_sc.js' %}"></script>
        <script type="text/javascript" src="{% static 'stripe_integration.js' %}"></script>
        </html>

Inside our authentication app folder views.py, create new class StripeConfigView + we should add few new imports as well as one new method to handle XHR request:

 #new imports 
    from django.conf import settings # new
    from django.http.response import JsonResponse # new
    from django.views.decorators.csrf import csrf_exempt # new

    class StripeConfigView(TemplateView): # new

        @csrf_exempt
        def get(request):
            stripe_config = {'publicKey': settings.STRIPE_PUBLISHABLE_KEY}
            return JsonResponse(stripe_config, safe=False)

Now update our authentication app level urls.py:

 from django.urls import path

    from .views import HomeView, LogoutUser, RegisterUser, StripeConfigView

    urlpatterns = [
        path("", HomeView.as_view(), name="home"),
        # path("login/", LoginUser.as_view(), name="login"),
        path("logout/", LogoutUser.as_view(), name="logout"),
        path("register/", RegisterUser.as_view(), name="register"),
        path("config/", StripeConfigView.as_view(), name="stripe_config"), # new
    ]

Next, use the Fetch API to make an XHR (XMLHttpRequest) request to the new /config/ endpoint in static/stripe_integrations.js:

 // new
    // Get Stripe publishable key
    fetch("/config/")
    .then((result) => { return result.json(); })
    .then((data) => {
    // Initialize Stripe.js
    const stripe = Stripe(data.publicKey);
    });

Include stripe.js in head tag of our base.html just bellow bootstrap

 `<script src="https://js.stripe.com/v3/"></script>`

With this we close down first item from our list:
Get Publishable Key

Send an XHR request from the client to the server requesting the publishable key
Respond with the key
Use the key to create a new instance of Stripe.js

What still needs to be done =>
Create Checkout Session

Send another XHR request to the server requesting a new Checkout Session ID
Generate a new Checkout Session and send back the ID
Redirect to the checkout page for the user to finish their purchase
Redirect the User Appropriately

Redirect to a success page after a successful payment
Redirect to a cancellation page after a cancelled payment
Confirm Payment with Stripe Webhooks

Set up the webhook endpoint
Test the endpoint using the Stripe CLI
Register the endpoint with Stripe

Create Checkout Session
Moving on, we need to attach an event handler to the button's click event which will send another XHR request to the server to generate a new Checkout Session ID.

inside authentication/views.py crete new CreateCheckoutSession

 class CreateCheckoutSession(TemplateView): # new   

    @csrf_exempt
    def get(self, request):
        number_of_nfts = request.GET.get("number")
        domain_url = 'http://localhost:8000/'
        stripe.api_key = settings.STRIPE_SECRET_KEY
        try:
            # Create new Checkout Session for the order
            # Other optional params include:
            # [billing_address_collection] - to display billing address details on the page
            # [customer] - if you have an existing Stripe Customer ID
            # [payment_intent_data] - capture the payment later
            # [customer_email] - prefill the email input in the form
            # For full details see https://stripe.com/docs/api/checkout/sessions/create

            # ?session_id={CHECKOUT_SESSION_ID} means the redirect will have the session ID set as a query param
            checkout_session = stripe.checkout.Session.create(
                success_url=domain_url + 'success?session_id={CHECKOUT_SESSION_ID}',
                cancel_url=domain_url + 'cancelled/',
                payment_method_types=['card'],
                mode='payment',
                line_items=[
                    {
                        'price_data': {
                            'currency': 'usd',
                            'unit_amount': 2000,
                            'product_data': {
                                'name': 'MusicalNFT',
                            },
                            },
                            'quantity': number_of_nfts,
                    }
                ]
            )
            return JsonResponse({'sessionId': checkout_session['id']})
        except Exception as e:
            return JsonResponse({'error': str(e)})

Here we pick up fron front-end number of NFTs user wants. Then we defined a domain_url, assigned the Stripe secret key to stripe.api_key (so it will be sent automatically when we make a request to create a new Checkout Session), created the Checkout Session, and sent the ID back in the response. Take note of the success_url and cancel_url. The user will be redirected back to those URLs in the event of a successful payment or cancellation, respectively. We'll set those views up shortly.

Don't forget to import stripe into views.py

    import stripe

Add to authentication urls.py

 from django.urls import path

    from .views import HomeView, LogoutUser, RegisterUser, StripeConfigView, CreateCheckoutSession

    urlpatterns = [
        path("", HomeView.as_view(), name="home"),
        path("logout/", LogoutUser.as_view(), name="logout"),
        path("register/", RegisterUser.as_view(), name="register"),
        path("config/", StripeConfigView.as_view(), name="stripe_config"),
        path('create-checkout-session/', CreateCheckoutSession.as_view(), name = "create_checkout_session"), # new
    ]

XHR Request

Add the event handler and subsequent XHR request to static/stripe_integrations.js:

 // Get Stripe publishable key
    fetch("/config/")
    .then((result) => { return result.json(); })
    .then((data) => {
    // Initialize Stripe.js
    console.log("stripe config")
    const stripe = Stripe(data.publicKey);

    // Event handler
    document.querySelector("#creditCard").addEventListener("click", () => {
    // Get Checkout Session ID
    // pass input values to backend
    let num = Number(document.getElementById("NFT").value);

    fetch(`/create-checkout-session?` + new URLSearchParams({number: `${num}`}))
    .then((result) => { return result.json(); })
    .then((data) => {
        console.log(data);
        /// Redirect to Stripe Checkout
        return stripe.redirectToCheckout({sessionId: data.sessionId})
    })
    .then((res) => {
        console.log(res);
        });
    });
    });

Here, after resolving the result.json() promise, we called redirectToCheckout with the Checkout Session ID from the resolved promise.

Navigate to user profile page on button click you should be redirected to an instance of Stripe Checkout (a Stripe-hosted page to securely collect payment information) with the NFT product information:

We can test the form by using one of the several test card numbers that Stripe provides. Let's use 4242 4242 4242 4242. Make sure the expiration date is in the future. Add any 3 numbers for the CVC and any 5 numbers for the postal code. Enter any email address and name. If all goes well, the payment should be processed, but the redirect will fail since we have not set up the /success/ URL yet.

To confirm a charge was actually made, go back to the Stripe dashboard under "Payments":

To review, we used the secret key to create a unique Checkout Session ID on the server. This ID was then used to create a Checkout instance, which the end user gets redirected to after clicking the payment button. After the charge occurred, they are then redirected back to the success page.

Ok, at this point we resolve first two items from our list: 1) Get publishable key and 2) Create Checkout session. What still need to be doe is to 3) Redirect User based on success or failure of transaction. And after that, finaly, 4) confirm payment over Stripe webhook, 5) minti new NFT to platform to custodial wallet and 6) database bookeeping staff (to keep all things in the sync).

To redirect user after transacrtion success or failure we can make two additional templates: canceled.html and success.html in project root templates folder

success.html

 <!DOCTYPE html>
    <html>
    <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <title>Django + Stripe Checkout</title>
        <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-T3c6CoIi6uLrA9TneNEoa7RxnatzjcDSCmG1MXxSR1GAsXEV/Dwwykc2MPK8M2HN" crossorigin="anonymous">
    </head>
    <body>
        {% block content%}
        <section class="section">
        <div class="container">
            <p>Your payment succeeded!</p>
            <a href="{% url 'home' %}"> Return to user profile page </a>
        </div>
        </section>
        {% endblock content%}
    </body>
    <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/js/bootstrap.bundle.min.js" integrity="sha384-C6RzsynM9kWDrMNeT87bh95OGNyZPhcTNXj1NW7RuBCsyN/o0jlpcV8Qyq46cDfL" crossorigin="anonymous"></script>
    </html>

And then canceled.html

  <!DOCTYPE html>
    <html>
    <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">

        <title>Django + Stripe Checkout</title>
        <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-T3c6CoIi6uLrA9TneNEoa7RxnatzjcDSCmG1MXxSR1GAsXEV/Dwwykc2MPK8M2HN" crossorigin="anonymous">

    </head>
    <body>
        {% block content %}
        <section class="section">
        <div class="container">
            <p>Your payment was cancelled.</p>
            <a href="{% url 'home' %}"> Return to user page </a>
        </div>
        </section>
        {% endblock content %}
    </body>
    <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/js/bootstrap.bundle.min.js" integrity="sha384-C6RzsynM9kWDrMNeT87bh95OGNyZPhcTNXj1NW7RuBCsyN/o0jlpcV8Qyq46cDfL" crossorigin="anonymous"></script>
    </html>

Then inside authenticaiton views.py add this two new classes:

  class SuccessView(TemplateView):
        template_name = 'success.html'


    class CancelledView(TemplateView):
        template_name = 'cancelled.html'

This two templates will be used to redirect user to correct page from inside our CreateCheckoutSession class.

If tx was succesfule user should see something like this

but before that we need to update our urls.py with two additional paths

  # payments/urls.py
    from django.urls import path

    from . import views

    urlpatterns = [
        path('', views.HomePageView.as_view(), name='home'),
        path('config/', views.stripe_config),
        path('create-checkout-session/', views.create_checkout_session),
        path('success/', views.SuccessView.as_view()), # new
        path('cancelled/', views.CancelledView.as_view()), # new
    ]

Ok, refresh the web page at http://localhost:8000/. Click on the payment button and use the credit card number 4242 4242 4242 4242 again along with the rest of the dummy info. Submit the payment. You should be redirected back to http://localhost:8000/success/.

To confirm a charge was actually made, go back to the Stripe dashboard under "Payments":

At this point we have just few more things to add to finish credit card functionaliy. Precasly three more things: 1) confirm payment over Stripe webhook; 2) minti new NFT to custodial wallet ones confirmaton arrive over wevhook and 3) user database bookeeping.

Ok, webhooks! Our app works well at this point, but we still can't programmatically confirm payments and run smart contract related code if a payment was successful. One of the easiest ways to get notified when the payment goes through is to use a callback or so-called Stripe webhook. We'll need to create a simple endpoint in our application, which Stripe will call whenever an event occurs (e.g., when a user buys a NFT). By using webhooks, we can be absolutely sure the payment went through successfully (and based on that mint new NFT to custodial wallet and asisgne ownership to the user in our Postgres database). In order to use webhooks, we need to:
Create Stripe request handler inside our views.py
Test the endpoint using the Stripe CLI
Register the endpoint with Stripe

Create a new view functon called stripe_webhook which prints a message every time a payment goes through successfully (more about code in comments and bellowe code):

  from django.http.response import JsonResponse, HttpResponse

    # payments/views.py
    @csrf_exempt
    def stripe_webhook(request):
        stripe.api_key = settings.STRIPE_SECRET_KEY
        endpoint_secret = settings.STRIPE_ENDPOINT_SECRET
        payload = request.body
        sig_header = request.META['HTTP_STRIPE_SIGNATURE']
        event = None

        try:
            event = stripe.Webhook.construct_event(
                payload, sig_header, endpoint_secret
            )
        except ValueError as e:
            # Invalid payload
            return HttpResponse(status=400)
        except stripe.error.SignatureVerificationError as e:
            # Invalid signature
            return HttpResponse(status=400)

        # Handle the checkout.session.completed event
        if event['type'] == 'checkout.session.completed':
            # Mint new NFT
            result = contract_interface.mint_nft("ipfs://uri.test")
            suc, result = contract_interface.event()
            if suc:
                try:
                    # if tx was sucesfule update custodial wallet related DB as well as user
                    c1 = Customer.objects.get(eth_address=result.args.owner)
                    if result.args.numberOfNFT not in c1.nft_ids:
                        # update custodial wallet information db
                        c1.nft_ids.append(result.args.numberOfNFT)
                        c1.total_no_of_nfts += 1
                        c1.save()
                        # update customer db
                        user = event["data"]["object"]["customer_details"]["name"]
                        name, last = user.split()
                        c2 = Customer.objects.get(first_name=name, last_name=last)
                        c2.nft_ids.append(result.args.numberOfNFT)
                        c2.total_no_of_nfts += 1         
                        c2.save()   
                        print("Payment success!)                                
                except Exception as e:
                    print (e)
        return HttpResponse(status=200)

And then update urls.py

  from django.urls import path

    from . import views

    urlpatterns = [
        path('', views.HomePageView.as_view(), name='home'),
        path('config/', views.stripe_config),
        path('create-checkout-session/', views.create_checkout_session),
        path('success/', views.SuccessView.as_view()),
        path('cancelled/', views.CancelledView.as_view()),
        path('webhook/', views.stripe_webhook), # new
    ]

Logic here is that over our webhook we are listen for request from Stripe. Then ones we get that request we are checking if sender is authroized, if type is completed and there is no any error alonge the way. Only if this is the case we assigne custodial wallet user and assigne id from newly minted NFT as well as increase total number of NFTs we have in custodial wallet. Then we query our database for user who acctualy pay this NFT with his card and then update his nft_ids field and total_no_of_nfts. Because he payed with credit card we minted new NFT to custodial wallet not to his one (he don't have one). But also in db we made record about the fact that he is owner of this NFT minted to custodial wallet.

Now let's test our webhook.

We'll use the Stripe CLI to test the webhook.

Once downloaded and installed, run the following command in a new terminal window to log in to your Stripe account:


    $ stripe login

This command should generate a pairing code:

    Your pairing code is: peach-loves-classy-cozy
    This pairing code verifies your authentication with Stripe.
    Press Enter to open the browser (^C to quit)

By pressing Enter, the CLI will open your default web browser and ask for permission to access your account information. Go ahead and allow access. Back in your terminal, you should see something similar to:

   > Done! The Stripe CLI is configured for Django Test with account id acct_<ACCOUNT_ID>
    Please note: this key will expire after 90 days, at which point you'll need to re-authenticate.

Next, we can start listening to Stripe events and forward them to our endpoint using the following command:


    $ stripe listen --forward-to localhost:8000/webhook/

This will also generate a webhook signing secret:

  > Ready! Your webhook signing secret is whsec_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (^C to quit)

In order to initialize the endpoint, add the secret to the settings.py file:

    STRIPE_SECRET_KEY = env("STRIPE_SECRET_KEY")
    STRIPE_PUBLISHABLE_KEY = "pk_test_51MybU0KtroSirNQXi4fuyC99SsypbcWbqLZtfYtGWTUmwTyoNkPaPvu7vy2twd5JjyzHTaL9EirWX7GsFJV3xFsj00xVvZo3C8" 
    STRIPE_ENDPOINT_SECRET=env("STRIPE_ENDPOINT")

Make sure that you have in your root .env STRIPE_ENDPOINT_SECRET variable

Stripe will now forward events to our endpoint. To test, run another test payment through with 4242 4242 4242 4242. In your terminal, you should see the Payment was successful. message.

Once done, stop the stripe listen --forward-to localhost:8000/webhook/ process.

Finally, after deploying your app, we will register the endpoint in the Stripe dashboard, under Developers > Webhooks. This will generate a webhook signing secret for use in your production app.

With this basically we have also credit card buyer covered. And what's left in this moment is deployment of our platform somewhere live. And as you can guess this will be topic of our final blog post...

Code can be found in this repo

p.s. Huge thanks to tesdrive.io for all knowledge they share!

Web3 backend & smart contract development for Python developers part 15: Listening on-chain events with Celery and web3.py

Basstardd — Fri, 17 Nov 2023 22:09:17 +0000

Now it is time to plug blockchain part into Django and database and to put all things together. General flow will go something like this: 1) cypto user order let's say 1 NFT and pay in crypto from his user profile. 2) We will listen emitted events from Polygin Mumbai on our backend and filter the one associated with our MusicNFT contract. If newNFTMinted event is there we will take out ID of newly minted NFT as well as buyer address. Then based on user address we will query our database and assign customer to variable. If NFT ID is not in his collection we will append ID to nft_ids filed and for one increase total_no_of_nft field. With this we will bring in sync database on backend and data in contract storage.

Now, during this toy project a lot of different patterns emerged that most probably you will often confront in your web3 day to day job. And listening for smart contract events on backend and updating database accordingly is definitely one of them. And this can be done on myriad of different ways. Here is one possible solution =>

We will use Celery (task/process) and RabitMQ (message/task broker).

Let's start by installing our message broker rabbitmq-server:

   #install message broker
    $sudo apt install rabbitmq-server

    # enable message broker
    $sudo systemctl enable rabbitmq-server

    # start message broker
    $ sudo systemctl start rabbitmq-server

    IMPORTANT: If you are working from `WSL2` this command will throw error:
    `System has not been booted with systemd as init system (PID 1). Can't operate.
    Failed to connect to bus: Host is down`

    That is why in case of `WSL2` we need to use another command (reasons for this are a bit deep and you can find more in this nice stack exchange "essay" explaining all technical intricacy https://askubuntu.com/questions/1379425/system-has-not-been-booted-with-systemd-as-init-system-pid-1-cant-operate):



 $sudo service rabbitmq-server start

    If everything whent well you should get seomething like this 
    $* Starting RabbitMQ Messaging Server rabbitmq-server

With this we have broker server up and running. Now we need Celery related staff. Let's go first pip install Celery (don't forget to activate virtual environment)

  $pip install celery

Inside Django project directory ./musical_nft create new file celery.py. Content of file should look something like this:

# celery.py
    from __future__ import absolute_import, unicode_literals
    import os
    from celery import Celery

    # set the default Django settings module for the 'celery' program.
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'musical_nft.settings')

    app = Celery('musical_nft', broker="pyamqp://guest@localhost//")

    # Using a string here means the worker doesn't have to serialize
    # the configuration object to child processes.
    app.config_from_object('django.conf:settings', namespace='CELERY')

    # Load task modules from all registered Django app configs.
    app.autodiscover_tasks()

Now in our authentication app folder we should create new tasks.py file

 # tasks.py
    from celery import shared_task
    from web3_interface import contract_interface
    from .models import Customer


    @shared_task
    def event_listener():
        suc, result = contract_interface.event()
        if suc:
            try:        
                c1 = Customer.objects.get(eth_address=result.args.owner)
                if result.args.numberOfNFT not in c1.nft_ids:
                    # update user db
                    c1.nft_ids.append(result.args.numberOfNFT)
                    c1.total_no_of_nfts += 1
                    c1.save()
            except Exception as e:
                print (e)

Then in our Django musical_nft/settings.py we should add Celery relevant setting:

  # Celery settings
    CELERY_BROKER_URL = 'pyamqp://guest@localhost//'
    CELERY_RESULT_BACKEND = 'rpc://'
    CELERY_TASK_SERIALIZER = 'json'
    CELERY_RESULT_SERIALIZER = 'json'
    CELERY_ACCEPT_CONTENT = ['json']
    CELERY_TIMEZONE = 'UTC'
    CELERY_ENABLE_UTC = True
    CELERY_BEAT_SCHEDULE = {
        'event_listener': {
            'task': 'authentication.tasks.event_listener',
            'schedule': 5.0,  # Run every 5 seconds
        },
    }

And then update __init__.py file from musical_nft folder with followinig code:

  from __future__ import absolute_import, unicode_literals

    # This will make sure the app is always imported when
    # Django starts so that shared_task will use this app.
    from .celery import app as celery_app

    __all__ = ('celery_app',)

What we need now is new contract_interface class where we will do all web3 related staff (listening for the newNFTMinted etc.). But first let's update our Django customer model with one additional field for user ETH address (we will use this field to pull correct user from DB based on newNFTMinted arg.owner of person who bought NFT).

Just add to models.py inside authentication app one line (now our Customer models should look something like this):

  from django.contrib.postgres.fields import ArrayField
    from django.db import models


    class Customer(models.Model):
        CRYPTO = "CRYPTO"
        CREDIT = "CREDIT"

        OPTIONS = [(CRYPTO, "cypto buyer"), (CREDIT, "credit card buyer")]

        created_at = models.DateTimeField(auto_now=True)
        first_name = models.CharField(max_length=50, blank=True)
        last_name = models.CharField(max_length=50, blank=True)
        username = models.CharField(max_length=50, blank=True)
        eth_address = models.CharField(max_length=100, blank=True)
        email = models.EmailField(max_length=250, blank=True)
        type = models.CharField(
            max_length=20,
            choices=OPTIONS,
            # default="CRYPTO"
        )
        total_no_of_nfts = models.IntegerField(default=0)
        nft_ids = ArrayField(
            models.IntegerField(null=True, blank=True), default=list
        )

        nft_metadata = models.ManyToManyField(NFTMetadata)

        def test_function():
            return list()

        def __str__(self):
            return f"{self.first_name} {self.last_name}"

Then follow standard procedure: python manage.py makemigrations & python manage.py migrate

Ones this is done we can go to Django shell and add to our user address from which we will buy first NFT (in real life user should have ability on front-end to add or change his eth address. But for test we will do by the hand):

 $py manage.py shell   
    >>>from authentication.models import Customer

    # pull user from database. put your desired pk/id 
    >>> c1 = Customer.objects.get(pk=10)

    # update newly added eth_address field with address from which you will buy NFT
    >>>c1.eth_address = "0xB4A5D329e35F83a2e6AB5a74d56f5bD67EaB8d83"
    >>>c1.save()

With this we have user in database with his eth address. Ones we pull information's from smart contract event we will query our database for user with that address and update number of NFTs he own as well as add newly minted NFT id.

What means that now we need web3 python class which will be part of celery task. Main purpose of this class is to listen for this specific smart contract event (newNFTminted emited ones buyNFT is successfully executed).

We will organize web3 part as new folder in project root directory. Name of folder will be web3_interface. We will transform this folder into Python package (to be imported in our tasks.py file) by adding __init__.py inside web3_interface folder. Inside __init__.py file add following code (explanation in comments):

  from .sc_interface import Interface
    import os
    import json

    abidir = os.path.dirname(os.path.abspath(__file__))

    # functino for smart contract ABI loading
    def load_abi(name):
        filename = os.path.join(abidir, f"{name}.json")
        return json.load(open(filename))

    # calling this function with MusicNFT.json as argument
    musicNFT = load_abi("MusicNFT")

    # instatitatin Interface class (yet to be made) with musicNFT ABI as argument
    contract_interface = Interface(musicNFT["abi"])

    # now contract interface is ready to be used imported and used in our `tasks.py`

Inside web3_interface you need to copy MusicNFT.json ABI and create sc_interface.py. Content of this file should look something like this (here we have all our web3 related staff)

import os
from web3 import Web3
from web3.middleware import geth_poa_middleware
from web3._utils.events import get_event_data
from eth_abi.codec import ABICodec
from dotenv import load_dotenv


load_dotenv()


class Contracts:
    def __init__(self, musicNFT):
        self.musicNFT = musicNFT
        self.musicNFT_address = os.environ.get("MUSIC_NFT_ADDRESS")
        self.private_key = os.environ.get("SIGNER_PRIVATE_KEY")
        self.w3Provider = Web3(Web3.HTTPProvider(os.environ.get("INFURA_PROVIDER")))
        self.codec: ABICodec = self.w3Provider.codec
        self.w3Provider.middleware_onion.inject(geth_poa_middleware, layer=0)
        self.nft_contract = self.w3Provider.eth.contract(
            address=self.musicNFT_address, abi=self.musicNFT
        )


class Interface(Contracts):
    def __init__(self, musicNFT):
        Contracts.__init__(self, musicNFT)
        self.event_template = self.nft_contract.events.newNFTMinted


    def handle_event(self, event, event_template):
        try:
            result = get_event_data(
                self.codec, event_template._get_event_abi(), event
            )
            return True, result
        except Exception as e:
            print(e)
            return False, None

    def event(self):
        block_number = self.w3Provider.eth.block_number
        events = self.w3Provider.eth.get_logs(
            {
                "fromBlock": block_number - 5,
                "toBlock": "latest",
                "address": self.musicNFT_address,
            }
        )

        try:
            for event in events:
                suc, result = self.handle_event(
                    event=event, event_template=self.event_template
                )
                if suc:
                    return (True, result)
            return False, False
        except:
            return (False, None)

Then our root .env should have following elements:

#database
DENIS_PASS=xxxxxx
ETHEREUM_NETWORK=maticmum
INFURA_PROVIDER=https://polygon-mumbai.infura.io/v3/your_keys
SIGNER_PRIVATE_KEY=private-keys
MUSIC_NFT_ADDRESS=contract_address_mumbai

With this things in place we are ready to run! Open three separate terminals:

From command line turn on our worker:

    $celery -A musical_nft worker -l info

    #And you should get something like this:

    [2023-11-15 14:23:58,390: INFO/MainProcess] mingle: searching for neighbors
    [2023-11-15 14:23:58,398: WARNING/MainProcess] No hostname was supplied. Reverting to default 'localhost'
    [2023-11-15 14:23:59,414: INFO/MainProcess] mingle: all alone
    [2023-11-15 14:23:59,443: INFO/MainProcess] celery@Ilija ready.

Then in another temrinal

 $celery -A musical_nft beat --loglevel=info

    # and you should get something like
    celery beat v5.3.4 (emerald-rush) is starting.
__    -    ... __   -        _
    LocalTime -> 2023-11-15 19:19:32
    Configuration ->
        . broker -> amqp://guest:**@localhost:5672//
        . loader -> celery.loaders.app.AppLoader
        . scheduler -> celery.beat.PersistentScheduler
        . db -> celerybeat-schedule
        . logfile -> [stderr]@%INFO
        . maxinterval -> 5.00 minutes (300s)
    [2023-11-15 19:19:32,379: INFO/MainProcess] beat: Starting...
    [2023-11-15 19:19:32,400: INFO/MainProcess] Scheduler: Sending due task my_scheduled_task (authentication.tasks.my_scheduled_task)

And lastly, third terminal window for Django server:

  $py manager.py runserver
    System check identified no issues (0 silenced).
    November 15, 2023 - 19:35:53
    Django version 4.2.7, using settings 'musical_nft.settings'
    Starting development server at http://127.0.0.1:8000/
    Quit the server with CONTROL-C.

In background we should have our Postgres server up and runnig. In any case, a lot of things currently going on in background to make all this happen.

Now let's test this thing:

1) go to front-end and log as denis user (the one to whom you assign eth address)

2) input number 1 and press buy button. MetaMask should pop-up two times: ones to approve MockTokens to MucisNFT contract and second to buyNFT (inside this function we have transferFrom and _mint to caller/user address).

Ones this is done contract will emit newNFTMinted event. Then our event_listener class will pick up this event and read two main piece of information's: buyers address and ID of newly minted MusicNFT. Then we will use user address to query our backend for that user and check if this NFT id is already in his collection. If no, we will append this new ID as well as increment for one total number of NFTs user have. This information will latter be used to update user profile on front-end.

And with this we have crypto buyer finished. Before we make deployment of this app somewhere in cloud, we have final step to do: add Stripe integrations for credit card buyers! This will be topic of next blog....

Code can be found in this repo

Web3 backend and smart contract development for Python developers Musical NFTs part 14: Buy NFT crypto buyer

Basstardd — Thu, 09 Nov 2023 11:17:00 +0000

Now we want to allow crypto user to buy our musical NFTs with MockTokens. For this to happen we will need to do few steps: 1) re-deploy our MusicNFT contract with updated max number of NFTs; 2) set-up desired price per MusicNFT; 3) send tokens from newly deployed MockUSDC to user address; 4) create buyNFT JavaScript function; 5) update our base.html and lastly 6) update our crypt_user.html.

1) Currently we have max NFT variable inside nft_package.sol set to 5. What you need to do is to re-deploy both contracts by running deploy.py script in our smart-contract/brownie_music_nfts/scripts folder (or add setter function for this var inside smart contract and then re-deploy). You should pass let's say 1000 NFTs as second argument to MusciNFT.deploy() function inside Brownie ./scripts/deploy.py (and now this call need to look something like this musciNFTdeployed = MusicNFT.deploy(mockDeployed,1000,{'from':accountOne})). And then from command line

brownie run deploy.py --network polygon-test.

Ones we re-deploy our contracts with new argument we need to pass new contract addresses to all JavaScript files where we use them (in our case call_js.js and node_interaction.js) as well as to import new MockTokens and MusciaNFTs in MetaMask. Then we need to transfer new MockTokens to buyer address before he perform new test NFT purches (all code for this we have in node_interaction_sc.js. Or simply you can make transfers directly in MetaMask from deployer to NFT buyers address ones you import our contracts there).

Reason why we do all this is fact that if we keep max NFTs on 5 (what is current situation defined during our fist deploy), very soon we will hit max limit during testing phase and our calls to smart contract buyNFT function will start to be reverted. To avoide this situation we need to re-deploy contracts and to assigne this new address to all relevenat places as we said earlier (for how to do all this you can go and check part no. 6 in this blog seria, smart contract deployment).

Now, step two: setup desired MusicNFT price

1) CDN Ethers at the end (just bellow ending body tag) of base.html template.

<script src="https://cdn.ethers.io/scripts/ethers-v4.min.js"

Then install with npm inside our root directory because we want to use it with Node (we will call some smart contract functions also from Node)

$npm install ethers@5.7.2

Here is important to install this specific version of Ethers because newer versions, after 6, tend to have problems with setting up InfuraProvider

Now is time to set new price of MusicalNFT and to transfer some MockUSDC to the user
Add to existing .env 1) infura API key; 2) signer privat keys and 3) network on which we would like to connect.

Also add .env to .gitignore (if you didn't already)

To get Infura API key you need to open profile on https://www.infura.io/. Ones you are in just create new project and copy API keys. They should look something like this https://polygon-mumbai.infura.io/v3/52153a550fd8498c9041752356789010. Be cerfule to pick up Mumbai testnet from Polygon, becuse we deploy our contracts there. Pass API key to INFURA_API_KEY inside newly created .env file.

Then for wallet private key go to MetaMask and select account from where you made contracts deployment. Then go to more => account details => show private keys. Copy private key to your local enviroment varibale under SIGNER_PRIVATE_KEY

Last thing we need here is ETHEREUM_NETWORK=maticmum (mainnet Polygon is matic and testnet Mumabi is maticmum)

Now let's load .env file. For this we need to install packege dotenv with command npm install dotenv inside our project root directory. Ones we start to work with contracts we will require this package inside Node to load .env varibales.

Now open Node

     $node
        Welcome to Node.js v19.1.0.
        Type ".help" for more information.
        > require("dotenv").config()  
        > const network = process.env.ETHEREUM_NETWORK
        > const infura = process.env.INFURA_API_KEY
        > const private_key = process.env.SIGNER_PRIVATE_KEY

At this point we should have all varibales from our .env loaded into Node and assigned to network, infura and private_key. What we need in this moment is to defin provider, signer (the one who will pay for transaction) and instancies of our contracts.

To make instance of provider, signer and contracts we always need to have follwoing ingredients: 1) ethereum network we intend to use; 2) in our case Infura API keys; 3) private keys of the signer account; 4) contract ABI and 5) address of deployed contract. With this elements you can first instatite: provider (gateway to Ethereum network); then signer (creator and signer of tx) and finally contract itself. And with ethers.js this can be done very easly

Open separate terminal from the one where your Node is running. From project root directory copy:

    $cp smart-contracts/brownie_musical_nfts/build/contracts/MockUSDC.json ./static

Then MusicNFT.json (if you already didn't)


    $cp smart-contracts/brownie_musical_nfts/build/contracts/MusicNFT.json ./static

Let's go back to Node and import contracts ABIs (we will need them in last step when we instatie contracts) from our Node:

    // Assigning ABI path to const
    >const mockJsonFile = "./static/MockUSDC.json";
    >const nftJsonFile = "./static/MusicNFT.json";

    // Loading contract ABIs
    >const mockAbi=JSON.parse(fs.readFileSync(mockJsonFile));
    >const nftAbi=JSON.parse(fs.readFileSync(nftJsonFile));

At this point we have our ABI and .env varibles loaded in node and we can move to define provider, signer and contracts instancie (ones we come to the last point we will be able to work with our deplyed contracts from within Node).

step 1: Lets define provider and contract.

Node:

     > const { ethers } = require("ethers");
        > const provider = new ethers.providers.InfuraProvider(
        network,
        infura);

step 2: define signer

>const signer = new ethers.Wallet(private_key, provider);

step 3: define MusicNFT contract as well as MockToken


    // contract address from Mumbai Polygon testnet (last deployment)
    const nft_contract_address = "0x1D33a553541606E98c74a61D1B8d9fff9E0fa138"
    const mock_usdc_address = "0xCeD9Fe6C4851acea6833DB0B7A0d2b892E4BBD5f"

    // Let's instatiate both contracts
    const contract_usdc = new ethers.Contract(mock_usdc_address, mockAbi.abi, signer);
    const contract_nft = new ethers.Contract(nft_contract_address, nftAbi.abi, signer);

At this point we have our contract in Node ready to be used. We can test that. Let's define one async function to check for name of our NFT.


    // This function will return name of our NFT contract
    getNftName = async () {
        let result = await contract_nft.name();
        console.log(result);
    }



    >getNftName()
    Promise {
    <pending>,
    [Symbol(async_id_symbol)]: 1779,
    [Symbol(trigger_async_id_symbol)]: 5
    }
    > MuscialNFT

Now we have fully functional contract in our node and we can update NFT price and send to potential user some MockTokens. Here we should notice that we are sending MockTokens to user because only deployer of contract have all issued tokens. In real life situation user should have his own USDC or some other stabilcoins to pay for his NFTs. Last two steps: update NFT price, send MockTokens tokens to the buyer.


    setNftPrice = async (price) => {
        let result = await contract_nft.setNFTPrice(price);

    }

    // check for new price
    var assert = require('assert');
    // When you call this function please pass as argument price you set previously
    checkNFTPrice = async (price) => {
      let nft_price = await contract_nft.NFTPriceInUSDC();
      console.log(Number(nft_price));
      assert(Number(nft_price) == price, "Price was not upddted!");
    }

    // sending MockTokens to the customer 
    // const buyer = here you should add address of acocunt from which you will purches NFTs
    const buyer = "0xB4A5D329e35F83a2e6AB5a74d56f5bD67EaB8d83"
    const amount = BigInt(10e18)

    sendTokenToBuyer = async (buyer, amount) => {
        await mock_usdc_contract.transfer(buyer, amount)
    }

*this JS code you can find in static/node_interaction_sc.js

Now when our customer have MockTokens to buy NFT, we will move to front-end and add functinoality to allow user to make this NFT purches.

For this to work we will have few step process. In first step user approve NFT contract to spend his MockTokens in amount calulcated by simple multiplication of number of NFTs he wants to buy time current price of MusicNFT. But because we are calling MockUSDC transfeFrom from within MusicNFT, MockUSDC contract will se MusicNFT as caller and it will expect MusicNFT to have allowance on buyer USDC mock tokens. That is why first step is to call approve function of our MockToken and then in second step to call buyNFT function from MusicNFT contract. If first step was ok, then MockUSDC will se that caller (MusicNFT contract) have rights to use buyer MockTokens and he will then transfer in last step from buyer to MusicNFT precise amount of tokens. Only then MusicNFT contract will mint new NFTs to buyer addrees and emit event of confirmation. And with this we have all steps done!

And this function can look something like this (inside static/call_sc.js file):

 const nft_contract_address = "0x1D33a553541606E98c74a61D1B8d9fff9E0fa138"
    const mock_usdc_address = "0xCeD9Fe6C4851acea6833DB0B7A0d2b892E4BBD5f"
    const main_account = "0x273f4FCa831A7e154f8f979e1B06F4491Eb508B6"
    const test_account = "0xB4A5D329e35F83a2e6AB5a74d56f5bD67EaB8d83"

    // set provider
    const provider = new ethers.providers.Web3Provider(window.ethereum);

    // get signer this need to be test_account
    const signer = provider.getSigner(0);

    // see for original ABI file in github repo. you can copy from there
    const ABI_NFT = [...]

    // see for original ABI file in github repo. you can copy from there
    const ABI_USDC = [..]

    buyNFT = async () => {
        // 1. get value user pass to use from front-end about number of NFTs he would like to buy
        const numberOfNFTS = document.getElementById('NFT').value;

        // 2. get current price of NFT from our smart contract and caluclate total price to be payed
        const price = await nft_contract.NFTPriceInUSDC();
        console.log(Number(price)*numberOfNFTS);
        const total_price = Number(price)*numberOfNFTS

        // 3. approve MusicNFT to transfer user MockTokens in total amount on contract 
        await usdc_contract.approve(nft_contract_address, total_price)


        // 4. finally call buyNFT function from MusicNFT contract to buy and mint new NFTs to user account
        await nft_contract.buyNFT("uri://music_nft_token", numberOfNFTS)
    }

This newly created call_js.js script should be added to our base.html

 {% load static %}
    <!doctype html>
    <html lang="en">
    <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <title>Muscial NFT</title>
        <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-T3c6CoIi6uLrA9TneNEoa7RxnatzjcDSCmG1MXxSR1GAsXEV/Dwwykc2MPK8M2HN" crossorigin="anonymous">
        <script type="text/javascript" src="{% static 'connect_wallet.js' %}"></script>
        <link rel="shortcut icon" type="image" href="{% static 'favicon.ico' %}" >
        <!-- <script type="module" src="{% static 'call_sc.js' %}"></script> -->
    </script>

    </head>
    <body onload="checkMetaMaskState()">
    <body>
        {% include "navbar.html"%}
        <div class="container ">       
            <br/>
            <br/>
            {% if messages %}
            {% for message in messages%}
            <div class="alert alert-warning alert-dismissible fade show" role="alert">
            {{ message }}
            <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
            </div>

            {% endfor%}
            {% endif %} 

            {% block content %}
            {% endblock content %}
        </div>
        </body>
        <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/js/bootstrap.bundle.min.js" integrity="sha384-C6RzsynM9kWDrMNeT87bh95OGNyZPhcTNXj1NW7RuBCsyN/o0jlpcV8Qyq46cDfL" crossorigin="anonymous"></script>
        <script src="https://cdn.ethers.io/scripts/ethers-v4.min.js"
        charset="utf-8"
        type="text/javascript"></script>
        <script type="text/javascript" src="{% static 'call_sc.js' %}"></script>
    </html>

And then last step is to connect onclick inside our crypto_user.html to newly created JS funciton buyNFT(). This will allow user to pass number of NFTs he would like to buy, then in backgorund we will calculate total price, approve tokens to MusicNFT contract, transfer MockTokens to MusciNFT contract and in last step mint new NFT (or NFTs, depends from number user give as input to front-end) and assigne to buyer address. With this we have buy NFT with crypto fully in place.

<table class="table  table-hover">
        <thead class="table-dark">
        <tr>
            <th scope="col">Name</th>
            <th scope="col">Email</th>
            <th scope="col">Total no. NFTs</th>
            <th scope="col">Means of payment</th>
            <th scope="col">Buy NFT</th>
        </tr>
        </thead>
        <tbody>
        <tr>
            <td> {{ customer.first_name }} {{ customer.last_name }} </td>
            <td> {{ customer.email }} </td>
            <td> {{ customer.total_no_of_nfts }} </td>
            <td>
                <form action="" method="post">
                {%csrf_token%}
                {{orderForm.as_p}}
                <input type="submit" value="Save" class="btn btn-secondary">
            </form>
            </td>
            <td>
            <form action="" method="post">
                {%csrf_token%}
                <label for="NFT">Number of NFTs</label>
                <input  type="text" id="NFT" ><br>
            </form>
            <input  onclick="buyNFT()" type="submit" value="Buy" class="btn btn-secondary">
            </td>             

            </tr>
        </tbody>
        </table>      
        {% for card in metadata%}
        {% if forloop.counter0|divisibleby:3 %} <div class="row">{%  endif %}
        <div class="card m-5 p-2" style="width: 18rem;">
            {% load static %}
            <img src="{% static 'nft/'%}{{card.cover_file_name}}"  class="card-img-top" alt="..." width="50" height="200"/>
            <div class="card-body">
            <h5 class="card-title">{{card.name}}</h5>
            <br>
            <p class="card-text">{{card.description}}</p>
            </div>
        </div>
        {%  if forloop.counter|divisibleby:3 or forloop.last %}</div> {%  endif %}
        <br>
        {% endfor %}

If everything went well, ones user login into our platform he will be able to give number of NFTs he wants to buy and then press buy button. MetaMask will pop-up aksking him first for approval for MockTokens to MusicNFT contract, and then in second step ask to confirm start of buyNFT transaction. Something like this:

In next blog, we will listen for emited minting event on our backend and updated our database and front-end accordingly.

In this repo you can find latest code

Web3 backend and smart contract development for Python developers Musical NFTs part 13: Connecting MetaMask

Basstardd — Sun, 29 Oct 2023 22:20:28 +0000

In this part we will add ability for crypto users to connect his/her MetaMask and to purches new NFT with our MockUSDC tokens. But before that let's clean a bit our home.html because it started to look a bit messy. What we can do is to create two new templates for crypto buyers and credit card buyer and to loaded them into home.html when we check user payment method status. For this to happen we just need to repackage our home.html and to move code related to crypto buyer to newly created templates/cypto_user.html and then all HTML code related to credit card buyer to templates/credit_card_buyer.html. Then in second step we will use Django tag include to include this two newly created HTML files into our home.html. With this we will clean up cluttery and make our main home.html template a bit more readable.

Create cypto_user.html and credit_card_user.html files inside root templates folder.

cypto_user.html

<table class="table  table-hover">
    <thead class="table-dark">
      <tr>
        <th scope="col">Name</th>
        <th scope="col">Email</th>
        <th scope="col">Total no. NFTs</th>
        <th scope="col">Means of payment</th>
        <th scope="col">Buy NFT</th>
      </tr>
    </thead>
    <tbody>
      <tr>
          <td> {{ customer.first_name }} {{ customer.last_name }} </td>
          <td> {{ customer.email }} </td>
          <td> {{ customer.total_no_of_nfts }} </td>
          <td>
            <form action="" method="post">
            {%csrf_token%}
            {{orderForm.as_p}}
            <input type="submit" value="Save" class="btn btn-secondary">
        </form>
          </td>       
          <td>
            <form action="" method="post">
            {%csrf_token%}
            {{form.as_p}}
            <input type="submit" value="Save" class="btn btn-secondary">
            </form>
          </td>             

        </tr>
      </tbody>
    </table>      
    {% for card in metadata%}
    {% if forloop.counter0|divisibleby:3 %} <div class="row">{%  endif %}
      <div class="card m-5 p-2" style="width: 18rem;">
        {% load static %}
        <img src="{% static 'nft/'%}{{card.cover_file_name}}"  class="card-img-top" alt="..." width="50" height="200"/>
        <div class="card-body">
          <h5 class="card-title">{{card.name}}</h5>
          <br>
          <p class="card-text">{{card.description}}</p>
        </div>
      </div>
    {%  if forloop.counter|divisibleby:3 or forloop.last %}</div> {%  endif %}
    <br>
    {% endfor %}

And then in credit_card_user.html

<table class="table  table-hover">
    <thead class="table-dark">
      <tr>
        <th scope="col">Name</th>
        <th scope="col">Email</th>
        <th scope="col">Total no. NFTs</th>
        <th scope="col">Means of payment</th>
      </tr>
    </thead>
    <tbody>
      <tr>
          <td> {{ customer.first_name }} {{ customer.last_name }} </td>
          <td> {{ customer.email }} </td>
          <td> {{ customer.total_no_of_nfts }} </td>
          <td><form action="" method="post">
            {%csrf_token%}
            {{orderForm.as_p}}
            <input type="submit" value="Save" class="btn btn-secondary">
        </form>
          </td>         
        </tr>
      </tbody>
    </table>        
    {% for card in metadata%}
    {% if forloop.counter0|divisibleby:3 %} <div class="row">{%  endif %}
      <div class="card m-5 p-2" style="width: 18rem;">
        {% load static %}
        <img src="{% static 'nft/'%}{{card.cover_file_name}}"  class="card-img-top" alt="..." width="50" height="200"/>
        <div class="card-body">
          <h5 class="card-title">{{card.name}}</h5>
          <br>
          <p class="card-text">{{card.description}}</p>
        </div>
      </div>
    {%  if forloop.counter|divisibleby:3 or forloop.last %}</div> {%  endif %}
    <br>
    {% endfor %}
    <p> credit card </p>

Now what we need to do is to include back into our home.html this two new files via Django template language tag include. Syntax should go something like this
{% include "crypto_user.html" %}

And now our home.html should look a bit shorter and cleaner

{% extends "base.html" %}
    {% block content%}

    {% if user.is_authenticated %}
        {% if customer.type == "CRYPTO"%}
        {% include "crypto_user.html" %}    

        {% else %}
        {% include "credit_card_user.html" %}    

        {% endif %}
        {% else %}
        <div class="col-md-6 offset-md-3"> 
        <h1> Login </h1>
        <br/>
        <form method="POST" action="{% url 'home' %}"> 
            {% csrf_token %}        
                <div class="mb-3">
                <input type="text" class="form-control" aria-describedby="emailHelp" placeholder="Username" name="username" required>
                </div>
                <div class="mb-3">
                <input type="password" class="form-control" placeholder="Password" name="password" required>
                </div>
                <button type="submit" class="btn btn-secondary">Login</button>
            </form> 
        </div>
    {% endif %}
    {% endblock content%}

Now all things should work exactly the same only thing is that we have more readeble main html document.

Let's move to web3 part. For now our aim is to integrate MetaMask (you can easlly experiment with WalletConnect if you want alternative version of this code). This will allow crypto user to purches new NFT by using MetaMask. For this to happen we will need to use some JavaScript (in next iteration of this app, when we start to use React for our frontend we will integrate WalletConnect instead of MetaMask).

Ones crypto user login into his profile he will see two new buttons: connect and buy NFT. He first need to press connect and MetaMask will pop-up asking him to provide his credentials. Ones he finish login into MetaMask he will be able to use buy NFT button and to pass number of NFTs he would like to buy.

Step 1: In your static folder create new connect_wallet.js file. And inside that file pass following code (Please check if static parameters are set correctly inside your settings.py It should look something like this =>

  STATIC_URL = "/static/"
    STATICFILES_DIRS = (
        os.path.join(BASE_DIR, 'static'),
    )
    STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')

JavaScript file need to handle connection to MetaMask as well as to update list items to connected or connect to metamask status how they change. For this achive we will need few more functions.

 //function used to connect to MetaMask wallet
    connect = async () => {
        const address = await ethereum
        .request({
            method: 'eth_requestAccounts',
            params: [],
        })
        .then((res) => console.log('request accounts', res))
        .catch((e) => console.log('request accounts ERR', e));
        document_test = document.getElementById("connect");
        document_test.innerHTML = "Connected"  
    }   

    // Simple function used to manipulate HTML elements according to connected or user disconnencted status
    checkMetaMaskState = async () => {
        const account = await window.ethereum.request({method: 'eth_accounts'})
        const liElement = document.createElement("li");
        liElement.setAttribute("class", "nav-item")
        const aElement = document.createElement("a");
        aElement.setAttribute("class", "nav-link p-3")
        if (typeof account[0] == "undefined") {
            aElement.setAttribute("href", "javascript:connect()")
            aElement.setAttribute("id", "link")
            liElement.setAttribute("id", "connect")
            liElement.innerHTML = "Connect to MetaMask"
            aElement.appendChild(liElement);
        document.getElementById("logout").appendChild(aElement);
    } else if (account[0].includes("0x")) {
        aElement.setAttribute("id", "link")
        liElement.setAttribute("id", "connect")
        liElement.innerHTML = "Connected"
        aElement.appendChild(liElement);
        document.getElementById("logout").appendChild(aElement);
    } else {
        console.log("There is some problem with MetaMask")        
    }
    }

    // Detect change in connect or dissconcet wallet status and updated front-end accordingly
    window.ethereum.on('accountsChanged', async () => {
    let ilElement = document.getElementById("connect")
    const account = await window.ethereum.request({method: 'eth_accounts'})
    if (typeof account[0] == "undefined") {
        ilElement.innerHTML = "Connect to MetaMask"
    } else if (account[0].includes("0x")) {
        ilElement.innerHTML = "Connected"
    }
    });

Then we need to add onload in body element of our base.html. And then to give checkMetaMaskState JS funciton as value. This function is used to generate new HTML document according to MetaMask connect/disconnect status.

Now base.html should look something like this (bascially the same as beafore just with <body onload="checkMetaMaskState()"> added)

{% load static %}
    <!doctype html>
    <html lang="en">
    <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <title>Muscial NFT</title>
        <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-T3c6CoIi6uLrA9TneNEoa7RxnatzjcDSCmG1MXxSR1GAsXEV/Dwwykc2MPK8M2HN" crossorigin="anonymous">
        <script type="text/javascript" src="{% static 'connect_wallet.js' %}"></script>

    </head>
    <body onload="checkMetaMaskState()">
        {% include "navbar.html"%}
        <div class="container ">       
            <br/>
            <br/>
            {% if messages %}
            {% for message in messages%}
            <div class="alert alert-warning alert-dismissible fade show" role="alert">
            {{ message }}
            <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
            </div>

            {% endfor%}
            {% endif %}

            {% block content %}
            {% endblock content %}
        </div>
        <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/js/bootstrap.bundle.min.js" integrity="sha384-C6RzsynM9kWDrMNeT87bh95OGNyZPhcTNXj1NW7RuBCsyN/o0jlpcV8Qyq46cDfL" crossorigin="anonymous"></script>
    </body>
    </html>

Then in second step we will erase one list item element from our navbar.html template (this place will be populated directly from javascript level according to MetaMask wallet status).

<nav class="navbar navbar-expand-lg navbar-dark bg-dark">
      <div class="container-fluid">
        <a class="navbar-brand" href="{% url 'home' %}">Musical NFT </a>
        <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbarSupportedContent" aria-controls="navbarSupportedContent" aria-expanded="false" aria-label="Toggle navigation">
          <span class="navbar-toggler-icon"></span>
        </button>
        <div class="collapse navbar-collapse" id="navbarSupportedContent">
          <ul class="navbar-nav me-auto mb-2 mb-lg-0" id="logout">
            {% if user.is_authenticated%}
              {% if customer.type == "CRYPTO"%}
              {% load static %}
              <script type="text/javascript" src="{% static 'connect_wallet.js' %}"></script>
                <li class="nav-item"  >
                  <a class="nav-link p-3" href="{% url 'logout'%}"  >Logout</a>
                </li>
                {% else %}
                <li class="nav-item">
                  <a class="nav-link" href="{% url 'logout'%}">Logout</a>
                </li>

                {% endif %}

          {% else %}
          <li class="nav-item">
            <a class="nav-link" href="{% url 'register'%}">Register</a>
          </li>
          <li class="nav-item">
            <a class="nav-link" href="{% url 'home'%}">Login</a>
          </li>
          {% endif%}
              </ul>
            </li>
          </ul>
        </div>
      </div>
    </nav>

If everything went well ones you login Denis user into his account you should be able to see something like this.

Code can be found in this github repo