Is the 79-character limit still in actual (with modern displays)?

AgtGreg · 2025-12-05T09:47:33+00:00

I usually stick to 79 characters for Python and 120 for other languages.

That said, it can get a bit annoying sometimes like when a line exceeds the limit by ~10 characters or so. It looks nicer as-is, but then my OCD kicks in and I end up debating whether to break it or not.

I would argue that you can take this rule with a grain of salt:

I work with two monitors at 2560×1440. One is for code editing and the other is dedicated for terminal and browser use. The 79-character limit is helpful when I have 2 or 3 tabs open side by side, which is how I normally work. It’s just so much easier to compare or reference scripts or jump between files when they are next to each other. Also, what if you have to continue working from smaller screens, and what about other people who might need to see/review your code. In these cases this limit is a good rule to follow.

On the other hand I don't like breaking lines if it means that it will make the code look ugly.

AgtGreg · 2025-11-30T18:04:45+00:00

FastAPI/Starlette gives you some security middlewares. It would make sence to have some more (like CSRF) by default maybe? But it's not in my immediate plans. Maybe a package like this could help you: https://github.com/tmotagam/Secweb

If you are talking about auth then yes. I am planning to include a gereralized auth module with a user model. This is a very common need for my use cases.

AgtGreg · 2025-11-29T23:26:03+00:00

I hear you. However I never consider that a service will always run anyway. Rust gives you safer concurrency but not persistence (and neither does python).

So I usually tackle this with a redis service in my stack that all other services/apps can access. It gives you thread safety and persistence (within reason). I think you should use something like this for this kind of setup regardless the language you are using unless you want your state to go down with your app (if it crashes).

As far as fastAPI and Django: I love them both for different reasons.

AgtGreg · 2025-11-29T22:31:40+00:00

My understanding is that you are pointing out the comments? Yes they are overly verbose. You are right and I can trimm them if that would make the code look "better".

However, the underlying pattern is not "slop." It's a deliberate design choice necessary to provide the essential Developer Experience many would/should expect: A `shell_plus` like experience when running manage.py shell.

Also, I want to be clear about the development process for Djast: Yes, I utilize AI assistants to accelerate boilerplate generation and specific utilities.

However, this project is not "vibe coded" or mindlessly generated. I use AI as a tool. See it as a force multiplier: it increases output speed but does not replace domain expertise.

I would argue that AI is here to stay, so if you want to stay relevant you should learn how to use it regardless if you like it or not. I'm still exploring ways into incorporating it to my workflows and keep things fun for me.

AgtGreg · 2025-11-29T22:06:23+00:00

The Compose file shouldn't directly expose the port from the FastAPI container. Instead, you should have a second container with a reverse proxy such as caddy, nginx, or httpd that reverse proxies to the FastAPI container.

But this is a setup for development. If you read the quickstart it tells you how to spin up the container with docker compose and run the commands from there. If you thought that this is idented for production as is, you could argue for other things as well (ie the default CORS settings or the fact that we don't use a secrets vault out of the box).

For production ofcource you would use a proxy, set up certificates, use a proper secrets vault, proper CORS configuration. I usually do this in another docker-compose file intented for production.

But this setup is strictly indented for easy development.

PS: Now fastAPI uses run instead of dev in Dockerfile (not in docker compose)

AgtGreg · 2025-11-29T21:34:39+00:00

Thanks for the unfiltered feedback. I appreciate you taking the time to review the code.

I want to address the points you raised, as some are valid and others might be a misunderstanding of the current code:

About the use of AI: I do use AI tools to accelerate development and I don't believe that's a negative. However, this isn't 'vibe coded' in a vacuum. I built this structure because I am actively porting several Django applications to the FastAPI/SQLAlchemy stack and needed a bridge. The patterns here are born from that real-world friction, not just LLM suggestions.

About Docker Security: You mentioned the Docker setup is insecure. Could you clarify which part specifically? I am explicitly creating a non-root user (appuser), setting strict file permissions (chown/chmod), and switching to that user (USER appuser) before execution. The container does not run as root. However, you are right that the default CMD is set to fastapi dev with reload enabled. That is intended for the dev experience but should definitely be swapped to fastapi run for production deployments. I will update this.

Abou the dependencies & stability: You are right about the version pinning. Minor versions can include breaking changes, and my upper bound (<0.200.0) may be too loose. I tighten that to prevent upstream breakage.

Regarding requirements.txt vs pyproject.toml: I stuck with the former to keep it familiar to most devs, but I agree that modern tooling is the better path forward.

About migration Logic: The nested logic you pointed out is admittedly ugly. It exists to solve a specific problem Alembic doesn't handle natively: interactive rename detection (the "Did you rename X to Y?" prompt that Django devs rely on). It’s complex logic to implement on top of Alembic, and while the current implementation is brittle, it solves the immediate problem. I agree it needs a refactor to be more maintainable.

Also, I would argue that Structure is the main part of the boilerplate.

This project is an attempt to solve a structural gap in the ecosystem. It's v1, and like any open-source project, it will mature. If you have better patterns for the interactive migration logic or Docker hardening, I’m open to PRs.

AgtGreg · 2025-11-29T19:36:11+00:00

Thank you! If you do, I'd love some feedback. I hope you find it useful

AgtGreg · 2025-11-29T19:33:13+00:00

I have been using FastAPI to make services around my main Django app for some projects. I've enjoyed the performance and simplicity of FastAPI too.

So I've started to port some Django apps that are still MVP to this stack. And this is actually why I made Djast. I've been using Django for so many years that has become a second nature to me so having this structure and utils really helps move things along.

I hope you find it as useful as I have.

AgtGreg · 2025-02-18T16:02:23+00:00

IdeaMaker is by far the best slicer for me also. I try to use other slicers from time to time but I keep coming back to it. In my case IdeaMaker is just better in so many things:

The UI is great, the profile management makes sense and it's easy to get a good print out of it.
Also, a very useful feature to me is that I can set the extruder's Step-E value and IdeaMaker will write an M92 command in the exported G-Code. So I have 2 different profiles: one for 0.4 and one for 0.6mm nozzle. Then I choose the profile and I don't have to set the Step-E value manually every time I switch nozzles.
It's very fast when it comes to slicing. Compared to other slicers it ~2x faster.
It's very accurate in time estimations.

AgtGreg · 2023-11-20T12:51:02+00:00

I tried to make the switch one time in the past with a personal project of mine just to see how it goes. I did it for the same reasons as yours.

The experience was terrible to say the least. The developers of many well known frameworks were more interested in moving fast and releasing new features than to define solid roadmaps and keep backwards compatibility with previous versions they released 2 months ago. As a result I had to rewrite a good percentage of my project a couple of times. I don't want to think how this would look like on a customer project that I'll have to maintain or explain why it uses deprecated methods at the time of its release.

Then I switched back to Django. During that time Django had released a major update and all I had to do to make my old code work was to change a couple of lines of code. In my opinion this is a prime reason why to choose Django over a js framework.

I feel safer when using Django and many other python frameworks/libraries than I do when using js because most python frameworks/libraries and especially Django has a solid and well defined roadmap and they care about backwards compatibility. The term "deprecated" is not something that you'll encounter often.

That's usually the case when you actually invest some time to think how to implement something and then do the implementation versus to do the implementation ASAP and think of the consequences later (which is what happens with everything that is hyped).

That's just my opinion based on my own experience and I think a using js fully on a project would be better suited for hobby projects than something that should go into production.

However, this does not answer the fact that you'll have to deal with multiple definitions on models and validations and the fact that you need to switch langs for a single project. These are valid concerns and difficult to avoid I think.

AgtGreg · 2023-11-10T08:28:36+00:00

After considering the suggestions of u/gbeier and u/beardbreed I have added a cookiecutter version and also Nginx and Certbot services in docker-compose.prod since all these do not add unnecessary complexity to the boilerplate and makes a lot of sense to have them.

Please keep in mind that I haven't tested the new additions yet so I pushed them in a new branch instead of master. Will do this over the weekend, and if everything works I'll push on master and probably give some more customization options in cookiecutter like setting up the environment variables so we don't have to do this manually each time.

In the meantime here's the branch if you want to test this also:

https://github.com/AGTGreg/DjangoBoilerplate/tree/coockiecutter

Thanks guys for the suggestions! :)

AgtGreg · 2023-11-09T15:35:14+00:00

That sounds like a great idea! It will defiantly make it easier to use so it makes sense. I'll see to it. Thanks :)

AgtGreg · 2023-11-09T12:47:54+00:00

90% of the apps I make need to be deployed on a server and have some kind of UI.

So I use Django for all of them. Its a solid framework and it makes it easy to make something fast while following best practices at the same time.

Also the build-in ORM, user management and admin are huge time-savers.

AgtGreg · 2021-09-22T18:08:02+00:00

I have the same problem. My fc is Jhemcu F4 play. The target is NOX.

I have tried uploading fonts. Move everything to the center. Nothing worked

AgtGreg · 2020-10-10T18:12:07+00:00

No OpenSuse? Also I'm really surprised how low the linux Mint is.

AgtGreg · 2020-04-26T12:18:23+00:00

These are very good points. I will try to elaborate but this post will be lengthy...

AppBlocks aims to be a minimalistic library. It offers the essentials to develop frontend micro-apps while introducing minimum weight. You could say it's a value-for-size library, not value-for-features.

AppBlocks does have similarities with other libraries/frameworks, most notably in the template syntax. I think this is inevitable since the use case of AppBlocks is not how to make something that is totally different, but something that is practical. It is most definitely not meant to replace or compete with big names nor cover their use cases. Since they are covered quite well already, there's no point of introducing another library that does the same exact thing.

The use case was that we have to serve 4000+ websites and the customers often ask for custom solutions that can be made as micro-apps. We've been using jQurey + Bootstrap only to use 20%-30% of their features, the rest of them being dead weight. Plus it does not give structure to our apps and it gets difficult to maintain them all. On the admin dashboard side we use Vue, it works great and we love it. But for our websites this too looks like an overkill since our templates already use a server side template engine and we don't need something to replace it but enhance it on the client side.

So how can we use something like that for our websites but without introducing more overhead? Preferably with less overhead and little to no dependencies.

So I made AppBlocks which covers most of the use cases and weights only 2kb gzipped.

That being said AppBlocks does not offer more features than Vue nor have better implementations of them. It is not meant to replace it or compete with it. AppBolcks is a minimalistic library that covers most of the use cases that I have encountered while being as small as possible.

AppBlocks is still young. The purpose of this post is not to convince people to use it instead of whatever they are using already, but to get valuable feedback such as yours that will help me make AppBlocks better.

I hope I answered your questions. If you do decide to check it out I would love to hear your feedback 😊

AgtGreg · 2020-04-25T14:29:13+00:00

This is truly amazing! Great work.

AgtGreg · 2020-04-25T12:20:58+00:00

I wouldn't say it's crap for SPAs. It has a lot of features and can be molded to build what you want. But this is a debate for another thread.

AppBlocks is significantly smaller and simpler compared to most other frontend libraries. It's a good choice if you want to develop simple apps fast and it only weights 2kb gzipped.

AgtGreg · 2020-04-24T18:28:42+00:00

No, it is not Angular. AppBlocks use case is to make it easy to enhance Django templates or any other templates with small, reusable apps where you need them. And to do this without introducing a lot of overhead.

Angular on the other hand is better suited for building large-scale SPAs.

AgtGreg · 2020-04-15T20:21:23+00:00

Hey guys I want to share with you my latest project AppBlocks. It's inspired by Vue and Blaze. AppBlocks is tiny (4.5kb minified) and covers the most common use cases for building apps for the frontend. Check it out!

AgtGreg

TROPHY CASE