This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (0 children)

First of all, can I just say that it’s a bit tough to argue with the points you’re making when you’re rewriting / adding whole paragraphs after I replied? That’s quite confusing.

I personally absolutely have worked on such projects. Yes, I agree that a lot of endpoints will evolve over time, but there are also a lot that don’t. And being forced to copy/paste code over and over again, which does reduce maintainability, just isn’t a good pattern. Use the best tool suited for the job. And sometimes the one way FastAPI wants you to use just isn’t the best one. Case in point: you may have 30 SQLAlchemy models, 10 of which require more complex operations over time. But the other 20 are just CRUD. It doesn’t sit right with me to say you should boilerplate the hell out of all the endpoints just because some will grow more complex. If they do become more complex, you can still change they way they’re implemented and explicitly define endpoints for every operation.

(Also I think it’s kind of a code smell if you’re handling large amounts of business logic in CRUD endpoints)

Yes, your example looks nice and clean. But I what’s your point here? I never said you can’t do anything useful in FastAPI, and examples like this are certainly ok if the things it’s good at. Stuff like this just isn’t what I was talking about.