[HN Gopher] Notes from building a blog in Django
       ___________________________________________________________________
        
       Notes from building a blog in Django
        
       Author : theptip
       Score  : 121 points
       Date   : 2023-09-12 14:53 UTC (8 hours ago)
        
 (HTM) web link (til.simonwillison.net)
 (TXT) w3m dump (til.simonwillison.net)
        
       | WD-42 wrote:
       | This is how simple Django is for CRUD apps. The author could go
       | even sparser. Love them or hate them, the views could have been
       | replaced with class based model views for even less lines of
       | code.
        
         | izak30 wrote:
         | Just for kicks I ran `git log | grep "Author: Simon" -C 20 |
         | tail -n 50`
         | 
         | ``` commit 53eddd4a0f8786e23f511a653d8d7ffa947ad8db Author:
         | Simon Willison <simon@simonwillison.net> Date: Mon Apr 23
         | 21:24:41 2007 +0000                   Added HTTP_HOST example
         | header              git-svn-id:
         | http://code.djangoproject.com/svn/django/trunk@5063 bcc190cf-
         | cafb-0310-a4f2-bffc1f526a37
         | 
         | ```
         | 
         | There are earlier references as well, but I think the author
         | was making pretty deliberate choices.
        
         | theptip wrote:
         | Fewer lines of code, perhaps, but in terms of explicitness,
         | clarity, and ease of maintainability I find myself strongly
         | favoring the functional approach for this case.
        
       | clivestaples wrote:
       | This is great and I love the simplicity and speed (of page load
       | and development). Curious, I ran it through Lighthouse and
       | received a performance score of 100. By way of comparison, some
       | of the more notable blogs on cloud edge were consistently between
       | 60-80. Just checking my perceptions.
        
       | Saphyel wrote:
       | For a blog I prefer static site generators to be honest. Fast,
       | cheap, secure and better for the environment.
       | 
       | Django and Wordpress are still valid use case for a blog.
        
       | turbobooster wrote:
       | [dead]
        
       | sneak wrote:
       | It's really not a good idea to use dynamically generated pages to
       | run a blog.
       | 
       | There's a reason static site generators exist. This should be
       | made clear that this is just a toy/example app to demonstrate
       | Django, not something someone should actually use.
       | 
       | Generating the pages on each request is madness, and is why
       | Wordpress in the default configuration (without WP Total Cache,
       | which allows the httpd to bypass Wordpress entirely for most
       | requests) falls over as soon as it's linked from any media site.
       | Let's stop repeating these engineering mistakes in language after
       | language.
       | 
       | Compile your blog to static pages and deploy those. Hugo, Jekyll,
       | and a million others await you, as well as CF Pages, S3, GitHub
       | Pages, Netlify, and others.
        
         | thraxil wrote:
         | Here's a post I put up just a few weeks ago showing how a
         | completely dynamically generated blog with zero caching or
         | performance tuning handles the traffic from ending up on the
         | front page of HN, being served off the free tier of Fly.io:
         | https://thraxil.org/users/anders/posts/2023/08/19/hn-traffic
         | 
         | It's Phoenix in my case, but I've had a dynamic blog with
         | Django for a long time and it's not massively different in
         | terms of performance. I also do like static site generators,
         | but more for being able to dump stuff into S3 and avoid some
         | deployment complexity (but they introduce other complexity).
         | 
         | The main point is really that Wordpress, with the default
         | configuration is just off the charts terrible. Like, it had to
         | have taken massive amounts of engineering to make something
         | that performs so poorly. If you don't pile a million features
         | into a product and overengineer the living daylights out of it,
         | it's really not very hard to handle quite a bit of web traffic.
        
         | simonw wrote:
         | If you're worried about traffic spikes, stick your site behind
         | a caching proxy like Varnish or Cloudflare.
         | 
         | My main blog https://simonwillison.net/ runs as a
         | Django+PostgreSQL app on Heroku behind Cloudflare, with a 15m
         | cache TTL for every page.
         | 
         | This works perfectly. I survived a surprise Elon Musk tweet a
         | few months ago which the server didn't even notice, because
         | Cloudflare absorbed all the traffic:
         | https://simonwillison.net/2023/Feb/17/analytics/
        
         | lyjia wrote:
         | There are other ways one can cache dynamic blog pages, like
         | with CLoudflare. Some frameworks will automatically cache
         | database calls as well, like with Rails.
        
         | AdamCraven wrote:
         | As someone who uses a mixture (django, Hugo), I say it's fine
         | use dynamic sites to run a blog - there's millions of them out
         | there.
         | 
         | They are usually easier to administer for less professional
         | users, as well as being able to quickly modify from standard
         | web interfaces.
         | 
         | If it's backed by a cache like redis it'll easily handle
         | Hackernews level traffic, even at very short cache times.
        
         | evantbyrne wrote:
         | What a strange comment. Yes, caching is intelligent and will
         | help you scale, but there's nothing inherently wrong with
         | dynamically generated pages.
         | 
         | > Generating the pages on each request is madness, and is why
         | Wordpress in the default configuration (without WP Total Cache,
         | which allows the httpd to bypass Wordpress entirely for most
         | requests) falls over as soon as it's linked from any media
         | site.
         | 
         | No, it is not. WordPress is slow because it has an
         | exceptionally poorly designed database schema, which requires
         | SELECT DISTINCT and joining on the same table multiple times
         | per query in order to do anything meaningful.
         | 
         | > Compile your blog to static pages and deploy those. Hugo,
         | Jekyll, and a million others await you, as well as CF Pages,
         | S3, GitHub Pages, Netlify, and others.
         | 
         | One downside of this is that you have wait for a compilation
         | process every time you make content changes. Another is that
         | any forms you might have still need a backend of some kind.
         | Static sites are really only appropriate for sites that rarely
         | ever change. A blog may or may not change frequently enough to
         | warrant a backend.
        
           | sneak wrote:
           | > _Static sites are really only appropriate for sites that
           | rarely ever change. A blog may or may not change frequently
           | enough to warrant a backend._
           | 
           | Any modern SSG can build and deploy in under a minute,
           | usually in single digit seconds. This isn't really an issue
           | in practice at all.
           | 
           | Static sites work fine even if you are updating many times an
           | hour. This is a far cry from "rarely ever change".
        
             | evantbyrne wrote:
             | You're conflating build times and deploy times. A low
             | friction deployment might take a couple minutes end-to-end
             | for something that "builds" in a few seconds once the CI is
             | booted up. Sure, that's fine for hobbyist stuff that is
             | always being edited by the web developer and nobody else.
             | The point is a proper backend editing experience brings so
             | much to the table. Once upon a time, my promotion was
             | delayed because the team lead I answered to decided to use
             | a SSG instead of a proper CMS, and non-technical
             | stakeholders were not happy about the limitations.
        
       | dabeeeenster wrote:
       | Be interested to know how/where it's deployed!
        
         | simonw wrote:
         | It's running here, hosted by https://fly.io -
         | https://www.datasette.cloud/blog/
        
           | 0xDEF wrote:
           | Does Datasette Cloud also run on Fly.io? How is Fly.io
           | stability nowadays?
        
             | simonw wrote:
             | Yes, it does. Each Datasette Cloud user gets their own
             | dedicated container, run using Fly Machines.
             | 
             | The core Django app manages SSO and team creation, then
             | calls Fly APIs to create volumes and machines for each
             | team. I'll be writing this up in a lot more detail soon.
             | 
             | I'm finding stability on Fly is excellent for my deployed
             | containers.
             | 
             | The problems I've seen are more around deployment -
             | occasionally there will be incidents where fresh deploys
             | can't go out for a few hours, all of which are reflected on
             | https://status.flyio.net/
        
       | colesantiago wrote:
       | Just a question, is it possible to have a website built with
       | Django and still work like the speed of a static site.
       | 
       | I've seen all these JAMStack websites marketed as 'fast' when the
       | only reason they are fast is that these web frameworks (11ty,
       | Astro, Hugo, Gatsby, etc) are essentially static generators to
       | HTML which is pretty much the same as creating a plain html file
       | if you want to.
       | 
       | I'm mainly interested in the SEO and speed side of things but
       | does using a web framework like Django or an SSG make a
       | difference?
        
         | EdwardDiego wrote:
         | Depends on how much work your Django app is doing. There's
         | built-in caching support to make it faster.
         | 
         | https://docs.djangoproject.com/en/4.2/topics/cache/
        
         | simonw wrote:
         | Computers are fast these days. If you write efficient code I
         | don't see any reason the difference between a Django site and
         | static files couldn't be imperceptible.
         | 
         | Or... run a Django app behind a caching proxy like Varnish or
         | Fastly or Cloudflare. I do that for my
         | https://simonwillison.net/ site (Cloudflare) and helped
         | implement Varnish at Eventbrite - it's a really solid pattern.
        
       | bodge5000 wrote:
       | I've been using Django for a number of years now and it's my go-
       | to for any web app that requires any kind of dynamic content
       | (especially user generated). DRF similarly for any REST related
       | work fits in perfectly, but aside from that it's really
       | refreshing to have a framework which doesn't require a tonne of
       | other dependencies to get something decent off the ground.
        
       | stuckinhell wrote:
       | I wouldn't recommend people use anything that requires a database
       | for a blog in 2023.
       | 
       | Edit: Since I got extremely downvoted for this comment. Here is
       | why:
       | 
       | You should use static site generators for new blogs in 2023.
       | 
       | Performance: Static sites typically load faster than database-
       | driven ones.
       | 
       | Security: Without a database, the risk of SQL injection attacks
       | is eliminated.
       | 
       | Scalability: Static sites can handle high traffic without complex
       | hosting solutions.
       | 
       | Maintenance: No database means fewer maintenance tasks and
       | potential failures.
       | 
       | Hosting and Costs: Static sites often have cheaper and more
       | flexible hosting options.
       | 
       | Decoupled Architecture: Modern trends prefer separating frontend
       | and backend, reducing the need for databases.
       | 
       | Development Simplicity: Static site generators offer a
       | straightforward content writing environment.
       | 
       | Backup and Portability: Static sites are easier to backup and
       | migrate.
       | 
       | Edge Hosting: Static sites benefit from faster load times with
       | distributed hosting solutions.
        
         | stuckinhell wrote:
         | Also Django and Rails are annoying as hell to deploy compared
         | to just uploading a zip of your static site to a static site
         | host.
        
         | winrid wrote:
         | Static sites are a PITA when you need to add certain
         | functionality. It's an optimization. Why start with such a
         | crazy optimization when you can just put cloudflare etc in
         | front of it?
         | 
         | Source: the fastcomments docs, blog, and several of my sites
         | are SSG. I don't like it anymore.
        
         | Mimmy wrote:
         | for people disagreeing with this comment, mind elaborating?
        
           | smarx007 wrote:
           | I think 800+ million Wordpress blogs are not planning to shut
           | down in 2023 after reading GP's comment.
        
             | Heloseaa wrote:
             | This doesn't provide a counterpoint to the original
             | comment's point.
             | 
             | IMHO, it's true that a static site generator should be the
             | way to go in 2023, instead of using a web framework with a
             | db.
             | 
             | I am personally running a hugo blog, on netlify, with
             | netlify CMS. I have 0 costs, great performances, everything
             | needed out of the box. What else to ask for ?
        
               | smarx007 wrote:
               | Does your blog support comments?
               | 
               | Also, for a company blog, an SSG likely means a
               | requirement to know Git, which could be inconvenient.
        
             | Cyphase wrote:
             | I don't think there are 800+ million WordPress blogs.
             | WordPress is used for lots and lots of websites that are
             | not blogs at all.
        
               | smarx007 wrote:
               | Thank you, I stand corrected, 800M+ WordPress
               | installations.
        
           | simonw wrote:
           | My https://simonwillison.net/ blog has been running since
           | 2002 and has 3015 long-form posts, 6718 bookmark posts and
           | 770 quotations.
           | 
           | Plus tag pages, archive-by-date-pages, series pages and more.
           | 
           | I don't particularly want to have to wait for all of that to
           | build!
           | 
           | It also offers faceted search against all of that, powered by
           | PostgreSQL: https://simonwillison.net/search/?q=static%20site
           | %20generato...
        
             | davidwparker wrote:
             | Incremental builds exist, so you'd really only have to
             | build once: https://nextjs.org/docs/pages/building-your-
             | application/data...
             | 
             | That said, personally, I love PG and enjoy using a DB. But
             | I can see pro's to both sides.
        
       | KolmogorovComp wrote:
       | Nice and simple. I feel the only lacking feature for a basic blog
       | is having unlisted blog posts, which is very handy when you want
       | to share it to proof-readers. This can be done on google
       | doc/hedgedoc [0] for sure, but then when porting there are very
       | often typos creeping in.
       | 
       | [0] https://hedgedoc.org/
        
         | wolfskaempf wrote:
         | The functionality exists in the author's implementation. If you
         | search for 'is_draft' you'll come across the places in the code
         | where this is implemented.
        
       | ajhai wrote:
       | Django has been my go to framework for any new web project I
       | start for more than a decade. Its batteries-included approach
       | meant that one could go pretty far with just Django alone.
       | Included admin interface and the views/templating setup was what
       | first drew me to the project.
       | 
       | Django project itself has kept pace with recent developments in
       | web development. I still remember migrations being an external
       | project, getting merged in and the transition that followed.
       | Ecosystem is pretty powerful too with projects like drf,
       | channels, social-auth etc., covering most things we need to run
       | in production.
       | 
       | https://github.com/trypromptly/LLMStack is a recent project I
       | built entirely with Django. It uses django channels for
       | websockets, drf for API and reactjs for the frontend.
        
       | danpalmer wrote:
       | For building CRUD web apps Django and Rails are truly in a league
       | of their own[^1].
       | 
       | Many frameworks try to be good at this but finish development at
       | a level of abstraction below these frameworks, leaving the last
       | level to a plugin ecosystem that requires so much more work to
       | wrangle into a fully working web app (see: Flask and its modern
       | successors in Python).
       | 
       | Other systems come at this from the opposite end, trying to be
       | low-code or less-code, like headless CMSs or static site
       | generators. The problem at that end always seems to be a lack of
       | flexibility and over-reliance on proprietary systems or SaaS
       | products.
       | 
       | Django is just Python. Rails is just Ruby. There's nothing
       | special to them and extending when necessary is often trivial,
       | particularly because they have such mature extension points.
       | 
       | There's a lot of criticism that can be levelled at these
       | ecosystems for not keeping up with whatever the hype of the year
       | is, or failing to "scale" in various ways, but damn do they get
       | you a very long way with very little work.
       | 
       | [^1]: Phoenix may be just about in this category, I don't have
       | personal experience with it though, just going on the fact it
       | seems to be very Rails inspired.
        
         | EdwardDiego wrote:
         | Django is Python, but very heavily leans on Python's
         | metaprogramming, which can make things complicated to
         | understand.
        
         | [deleted]
        
         | deaddodo wrote:
         | > Django is just Python. Rails is just Ruby. There's nothing
         | special to them and extending when necessary is often trivial,
         | particularly because they have such mature extension points.
         | 
         | Eh, I wouldn't agree with that. Both Django and Rails extend
         | the languages quite a bit with deep class overloading,
         | reflection and fluidic approaches.
         | 
         | Especially Rails, which pushes Ruby's DSL-like abilities to an
         | extreme. If you go from learning RoR to then having to make a
         | standard Ruby script, you quickly realize how much of what you
         | built relied on Rails-specific functionality. Django, more or
         | less, _is_ just Python with a bunch of logic built for you,
         | relative to that.
        
         | Daishiman wrote:
         | As someone who's been using Django for the past 12 years in
         | apps big and small, it blows my mind the trends towards
         | microframeworks and minimalist frameworks that are objectively
         | less productive in pretty much every metric.
         | 
         | Sometimes it feel like a minor superpower in just how much more
         | productive it is over pretty much everything, especially in the
         | early stages of development.
         | 
         | Even later on things like working auth and permission systems
         | and API frameworks are huge timesavers.
         | 
         | Proof that we are a fad-driven industry.
        
       | BiteCode_dev wrote:
       | While this is a good example of all the good stuff raw django
       | brings to the table, if you build a blog with django, you should
       | go for wagtail in 2023:
       | 
       | https://wagtail.org
       | 
       | - It's incredibly more productive.
       | 
       | - Seamlessly integrates with any django website, or hold your
       | hand to create one from scratch.
       | 
       | - Play nice with the whole django ecosystem.
       | 
       | - Is easy to pick up because under the hood "it's just django".
       | It uses django models, routing, auth, etc. It's uses standards,
       | best practices, and is a good citizen.
       | 
       | - The blog admin and the provided block editor are good out of
       | the box.
       | 
       | - It still gives you all the flexibility you want: it doesn't
       | force any template on you, any page structure, workflow, nothing.
       | You get to decide how simple or complex you blog is.
       | 
       | - The team behind it is super nice.
        
         | sgt wrote:
         | Will wagtail work in 10 years from now? Being Python and
         | Django, it just might. In the node ecosystem, things are broken
         | after 10 weeks or 10 months.
         | 
         | The benefits of static site generations...
        
           | lastofus wrote:
           | Wagtail first shipped 9 years ago in 2014. It's already
           | old/boring, and great!
        
         | game_the0ry wrote:
         | Thanks for the comments. Did not know much about wagtail until
         | now. Looks worthy of consideration for a side project I am
         | considering.
         | 
         | If you don't mind answering a couple of questions:
         | 
         | - I have a requirement for basically a CMS with the capability
         | of serious extensibility, built in either python or javascript
         | (I considered ghost but it does meet my requirments). Main job
         | is for a membership based cms but to potentially add
         | functionality outside of standard cms stuff. Would you say
         | wagtail / django combo would meet that requirement? (Sounds
         | like "yes")
         | 
         | - How does wagtail compare to django cms? (Less interested in
         | feature comparisons, more interested in your developer
         | experience with both)
         | 
         | Thx in advanced!
        
         | vasco wrote:
         | We moved away from wagtail and it was a bit of a mess to
         | maintain after using it for a couple of years for our marketing
         | website. I think I'd have stayed with native Django if I had
         | gone back in time. In the meantime the team that manages this
         | switched to next.js instead and it's been the most stable /
         | productive setup so far for our marketing website. This being
         | the 4th tool in 8 years (marketing people change their minds a
         | lot).
        
       | davepeck wrote:
       | This is great and showcases Django's talent for basic CRUD apps
       | with handy admin interfaces.
       | 
       | One catch: I like to deploy static sites to GitHub Pages. It
       | turns out the Django ecosystem has an answer for that in the form
       | of Django Distill [1]. Distill adds a new management command that
       | generates static content by repeatedly invoking your views.
       | 
       | I've used Distill to build quite a few static sites. It's great
       | to be able to deploy to Pages but use Django's admin UI locally.
       | Typically, for these sites, I check in my 'production' SQLite
       | database directly to my git repo.
       | 
       | (Combine this pattern with GitHub actions and you can do a lot
       | with a little. For instance, here's a toy I built to summarize
       | upcoming Seattle city council meetings [2].)
       | 
       | [1] https://github.com/meeb/django-distill
       | 
       | [2] https://scc.frontseat.org/ -- source at
       | https://github.com/front-seat/engage
        
         | deaddodo wrote:
         | I say this as someone that does like Django.
         | 
         | I had the opposite opinion. If you were trying to convert
         | Rails, Laravel or CakePHP users, this would just convince them
         | that Django was more manual and involved than those frameworks.
         | It would be better to utilize extensions like `scaffolding` to
         | give a more equivalent workflow. It does demonstrate general
         | MVC benefits and architecture, however.
        
         | reidjs wrote:
         | Your links may be broken
         | 
         | I was recently looking for a static site generator for a local
         | relay race I help organize and django-distill was the top of my
         | list. I ended up writing my own SSG because I had very little
         | HTML that actually had to be generated on the site. But might
         | check out django-distill in the future if you found it worth
         | learning.
        
         | sanderjd wrote:
         | This sounds like an awesome pattern, and I had no idea it
         | exists!
        
           | davepeck wrote:
           | It's a good one.
           | 
           | Simon Willison calls it the "baked data pattern" --- where a
           | read-only copy of your data is checked into your repo
           | alongside your code. [1]
           | 
           | (And, just to tie the threads together, that's the same Simon
           | who wrote the OP we're all commenting on, and who is also the
           | co-creator of Django and more recently of the very handy
           | Datasette!)
           | 
           | [1] https://simonwillison.net/2021/Jul/28/baked-data/
        
         | lylejantzi3rd wrote:
         | Can you think of a complicated app that utilizes Django to its
         | fullest extent? I'm trying to get a better view of what Django
         | is capable of and I find it's helpful to see both the simplest
         | example possible and the most complicated example possible.
         | "Design for the extremes" as Don Norman would say.
        
           | deckiedan wrote:
           | The wagtail CMS would be a good example of more complex
           | systems built on top of Django. https://wagtail.org/
           | 
           | One of the many more complex sites we've used it to build is
           | https://www.business-humanrights.org/en/ which tracks over
           | 10k companies, 100k+ articles in 15 or so languages. We've
           | also built internal dashboards, live updating forums,
           | donations platforms and so on. Another interesting one might
           | be https://www.achurchnearyou.com/ which is used by the
           | church of England to provide "mini sites" for all their
           | congregations around England, so several thousand church
           | administrators use that every week.
        
             | lylejantzi3rd wrote:
             | Thank you! I'll give that a gander.
        
           | btown wrote:
           | Instagram's backend is a Django monolith "with several
           | million lines of code and a few thousand Django endpoints" as
           | of 2019, and the same architecture was used for Threads! They
           | now run Django on a JIT-enabled fork of CPython, and leverage
           | a ton of internal tooling for static analysis and strong
           | typing.
           | 
           | https://instagram-engineering.com/types-for-python-http-
           | apis...
           | 
           | https://engineering.fb.com/2023/09/07/culture/threads-
           | inside...
           | 
           | https://engineering.fb.com/2022/05/02/open-source/cinder-
           | jit...
           | 
           | https://engineering.fb.com/?s=django
           | 
           | Django is also excellent for e-commerce with projects like
           | https://github.com/saleor/saleor - or you can roll your own
           | e-commerce system quite easily, which we've done at my travel
           | startup.
        
             | davepeck wrote:
             | Lots of interesting links; thanks!
             | 
             | Here in Seattle, Rover (a $1B+ market cap company) also
             | uses Django extensively.
             | 
             | In case it wasn't clear from my post above: yes, Django
             | _is_ great for building basic CRUD web apps. It's also --
             | like Rails and other mature frameworks -- great for a whole
             | lot more.
        
             | jenia2022 wrote:
             | Whats your travelling startup?
        
             | lylejantzi3rd wrote:
             | That is sufficiently complicated. Thank you!
        
           | ensemblehq wrote:
           | I've been involved with several enterprise applications based
           | off of Django - leveraging signals, custom models, tasks,
           | etc. to power insurtech and fintech applications.
        
       | tumidpandora wrote:
       | Nice, built bravoboard ideas blog with Django as well. Nothing
       | too fancy. Django gets the job done!
       | 
       | https://www.bravoboard.xyz/ideas/
        
       | Mimmy wrote:
       | This might be a dumb question, but would you use the deployed
       | version of the admin interface for writing your blog? And what if
       | you weren't online but wanted to work on a new essay or make
       | edits to an existing post?
        
         | simonw wrote:
         | I usually write posts in Markdown these days, directly in VS
         | Code with the preview pane open.
         | 
         | The blog described in this article renders Markdown directly.
         | My https://simonwillison.net/ blog doesn't do that yet, instead
         | I paste my Markdown into
         | https://til.simonwillison.net/tools/render-markdown and then
         | paste the HTML into the admin interface.
        
       | sc68cal wrote:
       | I have been using Django for 10 years and it still is my tool of
       | choice when I need to build something quickly that needs a full
       | HTML and form handling interface.
       | 
       | There is an excellent tool - https://djangobuilder.io/ that can
       | also really speed up the boilerplate even more.
        
       | waynesonfire wrote:
       | Do your notes include how to recover from being hacked?
        
         | simonw wrote:
         | Do you know something I don't know?
        
           | waynesonfire wrote:
           | No, just PTSD from my WordPress blog. I would use a static
           | site generator if possible.
        
             | simonw wrote:
             | Hah, yeah securing something like WordPress can be a
             | challenge, especially if you're running a bunch of plugins.
             | 
             | My blog is a pretty straight-forward Django setup without
             | many other dependencies, so it's a lot less of an attack
             | surface: https://github.com/simonw/simonwillisonblog
        
       | gv83 wrote:
       | god i love django. it could use a little bit of modernization and
       | modularization to ease the json api and deploy pain points, but
       | it's still the best python web framework by a long shot and it
       | would be deserving of way more manpower than it has.
       | 
       | but emoji laden docs and 500/month patreon pay better than
       | contributing to established things i guess
        
         | eYrKEC2 wrote:
         | With regard to JSON API aspects of Django, have you used
         | https://www.django-rest-framework.org/ on top of Django? I find
         | it to be very satisfactory.
        
           | bodge5000 wrote:
           | DRF has been fantastic in my experience, it fits in so well I
           | often forget it's a plugin and not just a default part of
           | Django
        
             | eYrKEC2 wrote:
             | It's the only way I've used Django and I love it.
        
           | tfeldmann wrote:
           | Django-Ninja is fantastic and based on pydantic.
        
             | winrid wrote:
             | This. I found DRF gets very confusing with all the
             | abstraction for complicated stuff. For simple APIs, it's
             | very nice (I used it on govscent.org). SidewaysData uses
             | Ninja and I love it so far.
        
       | D13Fd wrote:
       | If you want a more "out of the box" solution, you can run Wagtail
       | and Puput on top of Django. The Puput default template is a bit
       | dated, but it's pretty easy to update and tweak to your
       | preferences.
        
       | synergy20 wrote:
       | https://www.django-cms.org/en/ has blog with authentication etc,
       | just a wordpress in python
        
       ___________________________________________________________________
       (page generated 2023-09-12 23:01 UTC)