5 Lessons Building a Claude Code Plugin with Python

🛠️ Building Custom Apps in Frappe Framework v16 — Here's what actually matters. (Full breakdown in the slides attached 👇) Most developers approach Frappe like it's just another Python framework. It isn't. And the ones who figure that out early move significantly faster. Here's the real picture from building production-grade custom apps on v16: ⚡ One command. Zero boilerplate. bench new-app library_management In under 60 seconds — scaffolded, pip-installed, assets compiled. That's the promise. And it delivers. 📁 The scaffold isn't a template. It's architecture. Every directory has intent: → hooks.py — The nervous system of your app. This is where you register DocType event listeners, scheduled jobs, permission overrides, and custom JS/CSS injections. If you're overriding core files instead of using hooks, you're doing it wrong. → modules.txt — Declares what your app exposes. Every DocType, Report, Page lives inside a module. Missing or malformed? Your app won't appear in Desk. → patches.txt — Your migration history. Sequential. Permanent. Treat it like a database migration log — because it is one. → public/ — Static assets, now built via esbuild in v16. Know the difference between app-level JS and DocType-specific JS. → www/ — File-based routing. Drop a .html + .py pair, get an instant portal page. Zero config. → pyproject.toml — Replaces setup.py. Your Python dependencies, auto-installed with the app. ⚠️ V16 gotchas that will catch you off guard: • esbuild replaced Rollup — older JS patterns fail silently • Cache is aggressive — always bench clear-cache after hook changes • Hook functions must be fully importable strings — one bad import = silent failure • Patches that fail mid-run leave your site in an inconsistent state → write them idempotent • ignore_permissions=True in multi-tenant benches = subtle security debt 🏗️ The principle that separates scalable Frappe apps from legacy nightmares: Your app should be a guest in the framework's house. Use override_doctype_class — not core edits. Use Custom Fields — not schema hacks. Always call super() — missing it breaks GL entries and stock ledgers silently, months later. The developers who struggle with Frappe fight the framework. The ones who thrive treat hooks as the integration surface and DocTypes as the source of truth. #FrappeFramework #ERPNext #PythonDevelopment #CustomAppDevelopment #WebDevelopment #OpenSource #SoftwareArchitecture #ERPDevelopment #BackendDevelopment #TechCommunity #Automation #Industry #Manufacturing

Day-117 📘 Python Full Stack Journey – Django Models to UI Rendering Today I worked on a complete flow in Django — from creating database models to displaying dynamic data on a webpage. This felt like a true full-stack experience! 🚀 🎯 What I learned today: 🗄️ Model Creation (Database Table) Defined a model in models.py: class Course(models.Model): course_name = models.CharField() course_description = models.TextField() Learned: CharField → for small text data TextField → for larger content Understood that inheriting from models.Model creates a database table 🔄 Migrations & Admin Integration Applied database changes using: py manage.py makemigrations py manage.py migrate Registered model in admin.py: admin.site.register(Course) Managed data through Django Admin (add, edit, delete) 💡 Also learned that missing migrations can cause errors like “no such table” 🌐 Fetching & Displaying Data Retrieved data in views.py: details = { 'data': Course.objects.all() } Passed data to template and displayed using loop: {% for i in data %} <h1>{{i.course_name}}</h1> <p>{{i.course_description}}</p> {% endfor %} 🎨 Styling & Layout Used Flexbox/Grid to design responsive course cards Created a clean UI layout for displaying multiple records dynamically This session helped me understand how Django connects database → backend → frontend, making applications truly dynamic and data-driven. Excited to build more real-world features using Django! 💻✨ #Django #Python #FullStackDevelopment #WebDevelopment #Backend #Frontend #Database #CodingJourney #LearningToCode #Upskilling #ContinuousLearning

 Python Django Split Settings (Best Practice Structure) In production-ready Django projects, using a single settings.py quickly becomes messy and risky. A better approach is splitting settings by environment: settings/ base.py development.py production.py 🧱 1. BASE.PY (Shared Configuration) 👉 This is the core of the project (used everywhere) ✅ Keep here: INSTALLED_APPS MIDDLEWARE (common only) ROOT_URLCONF TEMPLATES WSGI / ASGI AUTH_USER_MODEL LANGUAGE / TIME_ZONE STATIC_URL, MEDIA_URL Third-party apps ❌ DO NOT include here: DEBUG DATABASES ALLOWED_HOSTS Security settings (SSL, HSTS) Environment-specific configs 👉 Rule: Only shared configuration 🧪 2. DEVELOPMENT.PY (Local Environment) 👉 Optimized for speed and debugging ✅ Add here: from .base import * DEBUG = True ALLOWED_HOSTS = [] Database: DATABASES = { "default": { "ENGINE": "django.db.backends.sqlite3", "NAME": BASE_DIR / "db.sqlite3", } } Dev-friendly settings: SECURE_SSL_REDIRECT = False SESSION_COOKIE_SECURE = False CSRF_COOKIE_SECURE = False EMAIL_BACKEND = "django.core.mail.backends.console.EmailBackend" ❌ Avoid: PostgreSQL config SSL/HSTS production email servers 🚀 3. PRODUCTION.PY (Live Server) 👉 Secure, optimized, real deployment settings ✅ Add here: from .base import * from decouple import config DEBUG = False Allowed hosts: ALLOWED_HOSTS = ["yourdomain.com", "www.yourdomain.com"] Database (PostgreSQL): DATABASES = { "default": { "ENGINE": "django.db.backends.postgresql", "NAME": config("DB_NAME"), "USER": config("DB_USER"), "PASSWORD": config("DB_PASSWORD"), "HOST": config("DB_HOST"), "PORT": config("DB_PORT"), } } Security (production only): SECURE_SSL_REDIRECT = True SESSION_COOKIE_SECURE = True CSRF_COOKIE_SECURE = True SECURE_HSTS_SECONDS = 31536000 SECURE_HSTS_INCLUDE_SUBDOMAINS = True SECURE_HSTS_PRELOAD = True Static files: STATIC_ROOT = BASE_DIR / "staticfiles" ❌ Avoid in production: DEBUG = True SQLite console email backend open ALLOWED_HOSTS insecure cookies 🧠 Key Idea (Simple Rule) FilePurposebase.pyShared foundationdevelopment.pyFast local developmentproduction.pySecure live system ⚡ Why this matters ✔ prevents production mistakes ✔ improves security ✔ separates environments cleanly ✔ easier scaling & deployment ✔ industry standard approach 🚀 Final insight A professional Django project is not defined by features — but by how cleanly it separates environments, security, and configuration logic.

Django ORM Internals and Query Optimization — What Every Backend Developer Should Understand What is Django ORM Really Doing? The Django ORM is an abstraction layer that converts Python code into SQL queries. When you write: books = Book.objects.all() Django does not immediately hit the database. Instead, it creates a QuerySet — a lazy object that represents the SQL query. The actual database call happens only when the data is evaluated. Examples of evaluation: Iterating over QuerySet Converting to list Accessing elements This concept is called lazy loading. How QuerySets Work Internally A QuerySet goes through multiple steps: Query construction Django builds a SQL query internally using a query compiler Optimization It decides joins, filters, and conditions Execution The query is sent to the database Result caching Results are stored to avoid repeated queries This means: Reusing the same QuerySet can save queries Creating new QuerySets repeatedly can hurt performance The Real Problem: N+1 Queries One of the biggest mistakes developers make: books = Book.objects.all() for book in books: print(book.author.name) This creates: 1 query for books N queries for authors This is inefficient and slows down applications at scale. Optimization Techniques 1.select_related() Used for ForeignKey and OneToOne relationships. books = Book.objects.select_related('author') This performs a SQL JOIN and fetches related data in a single query. 2.prefetch_related() Used for ManyToMany or reverse relationships. authors = Author.objects.prefetch_related('books') This runs separate queries but combines results efficiently in Python. 3.only() and defer() Fetch only required fields: Book.objects.only('title') Reduces data transfer and speeds up queries. 4.values() and values_list() Return dictionaries or tuples instead of full model objects: Book.objects.values('title', 'price') Useful for APIs and data-heavy operations. Why This Matters Poor ORM usage leads to: Slow APIs High database load Bad user experience Optimized queries result in: Faster response times Better scalability Efficient resource usage #Python #Django #ORM #BackendFramework #BackendDevelopment #SoftwareDevelopment #QuerySets #SQL #Optimization #Scalable #Fast_API_Response

🚀 Alternatives to Anvil https://lnkd.in/eZUtz9GZ 🔍 What is Anvil Anvil is a platform that allows developers to build full-stack web apps using pure Python—no JavaScript required. It combines UI design, backend logic, and database access in one environment, enabling rapid development. ⚙️ Function of Anvil • Drag-and-drop UI builder • Python-based backend + frontend • Built-in database and hosting • API integrations • One-click deployment It acts as a Python-first full-stack development platform. ✅ Pros • No need for JavaScript • Fast prototyping • Integrated hosting + database • Beginner-friendly • Strong Python ecosystem ❌ Cons • Limited flexibility vs full frameworks • Vendor lock-in risk • Scaling constraints • Less control over infrastructure • Smaller ecosystem than mainstream stacks 💰 Cost • Free tier available • Paid plans: ~$12–$99/month • Enterprise pricing for teams 🔁 Alternatives to Anvil 1️⃣ Streamlit Description: Python app builder Function: Build data apps quickly Uniqueness: Minimal code UI Pro: Fast prototyping Con: Limited frontend control Cost: Free + cloud 2️⃣ Dash Description: Python dashboard framework Function: Build analytical apps Uniqueness: Plotly integration Pro: Highly customizable Con: More code required Cost: Free 3️⃣ Retool Description: Low-code platform Function: Build internal apps Uniqueness: API-first approach Pro: Enterprise-ready Con: Not Python-native Cost: Paid 4️⃣ Bubble Description: Visual app builder Function: Full-stack apps Uniqueness: No-code ecosystem Pro: Beginner-friendly Con: Performance limits Cost: Subscription 5️⃣ FlutterFlow Description: Flutter-based builder Function: Mobile/web apps Uniqueness: Code export Pro: Cross-platform Con: Learning curve Cost: Free + paid 6️⃣ Appsmith Description: Open-source platform Function: Build internal tools Uniqueness: Self-hostable Pro: Flexible Con: Setup required Cost: Free 7️⃣ ToolJet Description: Open-source builder Function: Internal apps Uniqueness: Lightweight Pro: Easy deployment Con: Limited UI polish Cost: Free 8️⃣ Next.js Description: Full-stack JS framework Function: Build scalable apps Uniqueness: SSR + API routes Pro: High performance Con: Requires JS knowledge Cost: Free 9️⃣ Django Description: Full-stack Python framework Function: Build robust web apps Uniqueness: Batteries-included Pro: Highly scalable Con: Slower setup Cost: Free 🔟 Supabase Description: Firebase alternative Function: Backend + DB + auth Uniqueness: Open-source backend Pro: Fast backend setup Con: Needs frontend pairing Cost: Free + paid 💡 Insight Anvil simplifies development by abstracting complexity. But alternatives fall into 3 categories: • Python-first → Streamlit, Dash • Low/No-code → Bubble, Retool • Full-stack frameworks → Django, Next.js The trade-off: Speed vs Control 🔖 #Tags #Anvil #Python #LowCode #NoCode #WebDevelopment #AppBuilder #FutureOfWork #AItools

bulk_create and bulk_update don't behave like regular Django saves. Most developers find out the hard way or never realise it! The assumption - they're just faster versions of calling .save() in a loop. Same behaviour, better performance. save() on a single instance does several things - 1. runs pre_save and post_save signals 2. calls full_clean() for validation, handles auto-generated fields 3. returns the saved instance with its new primary key bulk_create and bulk_update bypass all of it. No signals. No validation. No per-instance hooks. Django hands a list of objects directly to the database and walks away. bulk_create - the PK problem ~ By default, bulk_create returns instances without primary keys populated(in Python object) - unless update_conflicts or returning_fields is explicitly set. ~ ignore_conflicts=True silently swallows insert failures - no exception, no log, no signal. A uniqueness violation disappears without a trace. bulk_update - what it can't do ~ bulk_update requires an explicit list of fields. Miss a field - it doesn't update. ~ It cannot update fields using expressions - no F(), no computed values. ~ And like bulk_create - no post_save signals fire. Anything listening for model changes never knows. The performance gain is real - 1000 inserts in one query vs 1000 round trips. But the tradeoffs are real too. Takeaway — -> bulk_create / bulk_update - no signals, no validation, no per-instance hooks -> bulk_create → PKs not populated in Python object by default on PostgreSQL, not at all on MySQL -> ignore_conflicts=True → silent failure, uniqueness violations disappear without exception -> bulk_update → explicit fields only, no F() expressions, missed fields silently skip Have you been bitten by missing signals after a bulk operation? How did you handle downstream consistency? #Python #Django #BackendDevelopment #SoftwareEngineering

Latest Update to the PyRepl.dev Web App — Version 2.3.0! Hey all — we just bumped up a new Update to the Python REPL IDE Web App — we're now up to version 2.3.0! To remind you, this is a full-stack web-based IDE for executing Python code with an integrated REPL (Read-Eval-Print Loop). Built on Astro 6 with server-side rendering, React 19 interactive islands, Clerk authentication, and a Turso (libSQL) cloud database. The app provides a modern development environment with a file explorer, Monaco code editor, console panel, live web preview, project management, and package installation. For this version, and perhaps for the next couple of Updates, there are not many new User & UI Features added, more like a lot of internal updates and fixes to make the App far more robust & bullet-proof. Such as — • IDE.tsx (the main Astro App file) broken-out into modules • Big test-coverage push, using both Vitest for Unit Testrs and Playwright for Integration end-to-end Test Suite • A much faster, more reliable CI / CD pipeline, mirroring the local test suits, in GitHub Actions for every push. • The user-facing app behaves the same as 2.2.1 in most places, but the internals are dramatically more modular, the test suite is substantially larger, and the GitHub Actions pipeline now runs the full tes suites • Better loading experience — added a dedicated <LoadingScreen> component that shows a "Taking too long? Reload" button after a timeout. • "Complete Your Profile" modal now properly closes when you click Cancel or finish the form, instead of stubbornly re-appearing. Accessibility fix in the Command palette for screen readers announce the palette correctly • Better mobile layout — Explorer header is now hidden on small (mobile-sized) viewports • Long filenames are truncated cleanly in the Explorer — they no longer break the sidebar layout • Dependency updates — Astro v6.1.7 (was v6.1.5), @astrojs/node v10.0.5, @clerk/astro v3.0.15, @clerk/react v6.4.1, @clerk/testing v2.0.15, @tanstack/react-query v5.99.0, react-resizable-panels v4.10.0, React + react-dom v19.2.5, lucide-react v1.8.0, aws-cdk v2.1118.0, Vitest + @vitest/coverage-v8 v4.1.4, jsdom v29.0.2, TypeScript v6.0.2, @playwright/test v1.59.1, react-hook-form v7.72.1, eslint v10.2.0 autoprefixer v10.5.0 • Added: concurrently v9.2.1 (devDep), cross-fetch v4.1.0 • Removed: local-ssl-proxy (replaced by e2e/https-proxy.mjs) For the Next versions, there probably won't be much in New User Features — it'll mostly be stuff like adding Aria for Accessibility and putting all the UI components into Storybook.js. After that, back on track for new features! Enjoy a far more Robust, Quickly Loading Python REPL IDE Web App v2.3.0! https://pyrepl.dev GitHub Repository — https://lnkd.in/gXdMe2qu Changelog — https://lnkd.in/gpZjmwsc

🚀 Django Optimization Tip: Fixing the N+1 Query Problem with select_related() As a backend developer, one of the most common performance issues I encountered while working on Django projects is the N+1 Query Problem. 💡 What is N+1 Problem? When fetching related data (like Employee → Manager), Django may execute: 1 query for employees N additional queries for each related manager 👉 This leads to slow performance and unnecessary database load. 🔍 Example (Problem Code): emps = Emp.objects.all() for emp in emps: print(emp.ename, emp.mgr.ename) ⚠️ This triggers multiple database hits (N+1 queries) ✅ Solution: Use select_related() emps = Emp.objects.select_related('mgr').all() for emp in emps: print(emp.ename, emp.mgr.ename) ✔️ Django performs a single SQL JOIN query ✔️ Reduces database hits ✔️ Improves performance significantly 🔥 Real Use Case (My Project) While building a Library Management System, I used select_related() to: Fetch user + borrowed book details Display related data efficiently in templates Avoid unnecessary queries 🎯 Key Takeaways: Use select_related() for ForeignKey / OneToOne Use prefetch_related() for ManyToMany / reverse relations Always optimize queries in production apps 💬 Have you faced N+1 issues in your projects? Let’s discuss in comments 👇 #Django #Python #WebDevelopment #Backend #FullStackDeveloper #PerformanceOptimization #100DaysOfCode

**No template boilerplate. No context switching. Just Python UI.** Introducing **Probo UI 1.4**, built with a 1200+ test suite for deterministic rendering. Probo UI (Python Rendered Objects for Backend Oriented User Interface) is a minimalist Python-first template framework that allows developers to construct and manipulate HTML component trees directly in Python. ➡️ **Build web applications that are almost 100% Python-driven.** The goal is simple. Instead of fragmenting your logic between Python, JavaScript, and complex template files, Probo UI enables backend engineers to build full, reactive interfaces using Python as the primary language. ⚡ **Why Probo UI?** • **Almost 100% Python web apps** – UI structures are built directly in Python. • **Framework agnostic** – works with **Django**, **FastAPI**, and **Flask**. • **Native HTMX support** – build dynamic interfaces without heavy frontend frameworks. • **Server-driven UI architecture** – great for dashboards, internal tools, and admin systems. • **Structured component tree** – query, traverse, and modify UI elements programmatically. • **Efficient styling system & Bootstrap integration** – inline styles, head styles, animations, and media queries. Bootstrap integration for rapid responsive layout building. • **Minimal JavaScript overhead** – focus on backend logic rather than frontend complexity. • **Real SSDOM Architecture** – Query, traverse, and modify UI elements as live Python objects. • **Enhanced CLI scaffolding** – All new projects or Django apps created with the Probo CLI now come with a stock SSDOM index document and a sample greeting component out of the box. 🌐 **Live Demo & Ecosystem** Key highlights: * Dynamic UI rendering via **HTMX-powered interactions** * **Component-driven architecture** using reusable domain-level UI modules * **Context-aware rendering**, where UI fragments are injected and updated based on backend state * Clean separation of concerns while maintaining a **Python-first development model** 🔗 **Live Demo** https://lnkd.in/e5UafrFt 🧱 **Tech Stack** * Django * Probo UI * HTMX 📂 Source Code & Docs: * Demo Application: https://lnkd.in/dGNgB9Fp * 📂 Docs: https://lnkd.in/d3sjzXMG This demo reflects how Probo UI can be used to build production-style backend-driven interfaces, reducing frontend complexity while maintaining interactivity and scalability. 📦 What’s Next? I’m currently building a `probo-components` package for community-driven extensions and innovations plus SSDOM events and a series of tutorials for production-style Python web applications integrated with: • **Django** • **FastAPI** • **Flask** Each demo will be published on GitHub. 💬 I’d love to connect with anyone interested in: • Server-driven UI architectures • Python-based frontend systems • The future of HTMX in the Python ecosystem • or having a chat #python #webdevelopment #django #htmx #opensource

I just published my first article on "The Django Habits That Hurt You in Go". Coming from Python/Django, a lot of patterns feel natural, with Celery, background jobs, fire and forget tasks, safe retries and queues still feels like "Django". Then you switch to Go after hearing so much about how awesome goroutines are, and naturally, you try to use them like Celery :) Goroutines feel lightweight and easy, so it is tempting to treat them like background workers. But they lack persistence, retry mechanism, fault isolation, and guarantees. This article breaks down: - why goroutines are not a replacement for Celery - the common mistake Django engineers make in Go - what the correct pattern looks like - and what to use instead when you actually need a task queue If you are a Django developer who is giving Go a shot, this will save you from a few painful lessons. https://lnkd.in/ef5BPMYC