The admin is a vital part of Django, it makes dealing with your models much, much easier than having to wrangle with the database, so it was important to me to get working. The one problem I had was that the usual TestCase class didn’t work (it gave me “table is locked” errors), but TransactionTestCase works splendidly and is probably quite a bit faster, too. To clarify, we’ll be testing the FastAPI views using Django’s test runner and. If you want to use another runner like pytest, that should also work properly, though I haven’t tested it. Tests are working great as well, using Django’s. Migrations work fine, and any app that interfaces with or enhances the ORM should also work properly. The ORM works quite well, basically exactly as if you were using Django. If you do get it working, or try to, please leave a comment here or contact me. I suspect I’d have issues, as Django doesn’t support it very well yet, and the ORM would probably block all view threads. I also didn’t try to get asynchronicity working, which might be a dealbreaker for many people. This means that some things like middleware will obviously not work, since Django is not handling views at all. The way this profane joining works is by using FastAPI as the view layer, and importing and using parts of Django separately. I will go into details on each part here, and post code in the next section. Verily, I say unto thee, it would be rad.Įach part of this unholy union needed a different integration. Still, there’s no reason for DRF not to have an API as nice as FastAPI’s, but there’s no helping that.Ī fantastical notion caught hold of me: What if I could combine FastAPI’s view serving with Django’s ORM and apps? It would have been great if FastAPI was a Django library, but I guess the asynchronicity wouldn’t have been possible. I would also miss Django’s admin interface a lot. It lacked Django’s ecosystem, and it didn’t have an ORM as good and well-integrated as Django’s. It looked very simple, well-architected and with sane defaults, and I seriously considered developing the API for my company’s next product on it, but was apprehensive about two things: It’s no surprise, then, that when I found FastAPI I was really excited, I really liked its autogenerated docs, dependency injection system, and lack of magical “request” objects or big JSON blobs. I generally prefer writing a simple class-based view for my APIs, but then I don’t get automatic docs and other niceties. I hate DRF with somewhat of a passion, I always found its API way too complicated and verbose, and never managed to grok it.Įven the simplest things felt cumbersome, and the moment your API objects deviated from looking exactly like your DB models, you were in a world of hurt. My only issue with Django was that it never really had a good way of making APIs. This is going to be emphasized rather spectacularly in this article, as I’m going to do things nobody should ever have to do. I love how modular it is, and how it lets you use any of the parts you like and forget about the ones you don’t want. It’s my preferred way of developing web apps, mainly because of the absolutely vast ecosystem of apps and libraries it has, and the fact that it is really well-designed. FastAPI actually plays very well with Django
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |