221–230 of 237 posts
Earlier quoted context omitted.
Thank you, mister, but I mean from a techy point of view.
I only know laravel from skimming the docs, but I got the impression that there was not enough difference between it and Django to justify switching to a language you don't know,going either way. That said... Does Laravel have something like Django's admin view?
I have experience with NextJS, Express and Flask.
In the past, Django had intimidated me due to having so many official-sounding files and folder structure and settings etc. So, I had just not given it too much brain cycles.
After having experience with the earlier listed frameworks, I can appreciate some of the things Django gives out of the box. It feels "industry-grade".
Hoping to make fond memories with Django just like the other experiences described here! Happy holidays everyone!
Earlier quoted context omitted.
An approach I've done in the past for projects that are publicly API-based: Django handles the database migrations and user accounts/models/etc - and you get the useful admin to boot, which is just incredible if you ever need to open up the data layer to someone else. Then just write the API interface in Go/Rust/your language of choice. It decouples the DB modeling from the API layer, but in practice... I've just not…
Interesting, I was thinking of the exact same thing. Glad to see it works!
Earlier quoted context omitted.
I know it's not "shiny and new" but Django is still serving us very well were I work. The only two things it lacks great support of is typing and async. However the async is actively being worked on and does work (with some quirks), and python's type support has only gotten half-mature just recently (coming from typescript at least). I would personally be hesitant to try something new just because django is so battle…
> However the async is actively being worked on and does work (with some quirks) I recently tried to implement it in a project using the new ORM a-methods (which AFAIK are not even async under the hood) and it resulted in an explosion of complexity bubbling up in many places in the codebase. I reverted everything to sync and re-implemented the hot functions with multi-threading... I think I'll keep to this approach u…
> I reverted everything to sync and re-implemented the hot functions with multi-threading...
I'm curious what your workload is? If you need the requests themselves async then you normally have gunicorn/uwsgi handle that for you. Otherwise you'd send it to a work queue. Do you have a lot of long-running queries or realtime stuff?
Hopefully django's async support improves. I love the ORM so much I use it for non-server based projects.
Earlier quoted context omitted.
That general story can happen with any tech stack. POC whipped together without good architecture. Having proven itself, usage increases until the application starts to burst at the seams. Program must be redesigned, avoiding performance gotchas. I still think Django + the ORM give you a lot of runway before performance should be a concern.
Idk. The python stack strikes as particularly troublesome if you don’t know exactly what you’re doing. There are no guardrails for less experienced devs that prevents you from making basic mistakes. I also realized mid project that the default rest framework doesn’t support good api model generation from OpenApi or vice versa. And most devs didn’t understand why using untyped dicts everywhere was bad. In all transpar…
Earlier quoted context omitted.
Still Django unless you're only building a simple API.
Why not a complex API?
If you discover a hot spot somewhere one can always spin that part off to its own service (which can very well be FastAPI to run it async) or rewrite that particular service in Go or Java. But I would not recommend premature optimization in most cases. First get your product out.
Earlier quoted context omitted.
Why do you say python holds it back?
The three big problems with Python: * It's slow. 'nuff said. No the fact that Numpy exists doesn't change that. * Lack of static types. I mean, they do exist now which is fantastic, but there are still far far far too many projects not using them. And lots of code that can't be statically typed (e.g. lxml). * The infrastructure and module systems are a total mess. Literally nobody understands Python imports. There's…
Earlier quoted context omitted.
Idk. The python stack strikes as particularly troublesome if you don’t know exactly what you’re doing. There are no guardrails for less experienced devs that prevents you from making basic mistakes. I also realized mid project that the default rest framework doesn’t support good api model generation from OpenApi or vice versa. And most devs didn’t understand why using untyped dicts everywhere was bad. In all transpar…
Have you tried django-ninja or FastAPI?
Earlier quoted context omitted.
Broadly, if you're happy with Django and haven't felt the need to transition to SPA, power to you. This is the case in some industries. It's generally not the case in b2c, though, and if you haven't felt the pain yet then you likely aren't in touch enough with your customers (or you haven't connected the dots). I don't need to sell you on the concept though I will address your comment in depth. In general, React (esp…
I’d also add that if you use Typescript with an OpenAPI client generator ( https://github.com/ferdikoomen/openapi-typescript-codegen ) it can immensely alleviate some of the biggest pain points of seperate backend and front-end. It always used to be a major pain in the ass with the amount of overhead an API change would incur - updating documentation, postman, constant communication between backend and front-end devs…
Curious, are you doing anything in your code-generation workflow to solve this specific pain point?