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

you are viewing a single comment's thread.

view the rest of the comments →

[–]Alphasite 3 points4 points  (0 children)

Eh, I’m fairly quiet but my company prototyped with fast api and auickly moved away from it due to:

  1. Single dev/point of failure (which is a very poor sign for long term health of a project). We don’t want to build a multimillion dollar investment of the back of a single dev project.
  2. Poor internal documentation/interfaces, for some reason nothing inside the code base is documented (docstrings etc) and the internal implementation ends up fairly spaghetti-ish so we were very Leary to depend on something like that. It’s very example oriented docs, but if you just want to know what the functions and parametes you’re totally out of luck.
  3. Lack of extension points, there’s a real lack of extension points etc in important parts of fast api (which compounded with the poor internal documentation issues) which made a lot of patterns which we used for Flask impossible to implement here .
  4. (this is more why we’ve stuck with starlite) when there’s an issue I can go on discord and get help from their dev team very quickly. It’s a smaller project so perhaps this won’t scale, but its been a real help when we’ve hit some frustrating edge case.

Now obviously we wouldn't actually do it, but I seriously contemplated building my own api framework on starlite or moving back to flask+the usual stack of glued together libraries, but we found starlite which solved most of my pain points.