What is the difference between Flask-RESTful and Flask-RESTx? Is it more advantageous to use Flask-RESTx instead of Flask-RESTful?
the main difference between Flask-RESTx and Flask-RESTful is that Flask-RESTx supports auto-generated Swagger documentation. i think there are no other noticeable differences.
Related
I'm not sure what might go wrong when I have to integrate a django API (built using JsonResponse and without extra frameworks) with a frontend, in this case, Next.js.
I built a django API using JsonResponse (void of DRF). I want to build a frontend client with Next.js that would make API calls to my django API. My questions are:
Will I have to run both django and next.js servers at the same time to execute the full project?
I think I would face some challenge with csrf token, what other challenges may I face having built my API without an API framework as Django Rest Framework?
It is almost always a better approach to treat these two as separated as possible. I'd go with completely separate repos, hosting etc...
I think the biggest advantage of using DRF is the validation. DRF has nice ways to handle request data validation. Your views will look much leaner, because it will save you the trouble of writing much boilerplate code.
I'm used to test Django Rest Framework apps with the test tools available directly in Django and DRF. It's possible to setup a dummy client and expose all the REST methods.
At the same time, I see many posts talking about Postman for API testing. I fail to see where the advantage would be.
Is there any reason for me, a single developer, to use Postman? Or perhaps there is only an advantage for shared projects?
I'm currently evaluating the suitability of LoopBack for a future microservice-based project. Moreover, I'm new to LoopBack, so please correct me, if a misunderstood the concepts of Loopback.
At times, you need an aggregator microservice which calls several others. Is it possible to generate a strongly typed client library stubs (in the form of a Service) analogous to the lb4 openapi command?
And if not, what is the point of using TypeScript (as advertized), when one has to use pure JavaScript as shown in these examples (1) (2)?
Also is there an option to use an OpenAPI spec file from existing services?
It seems to me that this is a 'terra incognita' at this point for LoopBack v4 with TypeScript.
Disclaimer: I'm a maintainer of LoopBack.
There are a few things involved here:
Communication between microservices - we support REST and gRPC via connectors, such as loopback-connector-openapi and loopback-connector-grpc.
As you mentioned, it's on the roadmap to generate service stubs - see https://github.com/strongloop/loopback-next/issues/1070#issuecomment-403530459. The lb4 openapi command has implemented a lot of logic that can be applied to lb4 openapi-stub. Contributions are welcome!
You should also check out https://github.com/strongloop/loopback4-example-shopping/pull/268.
I'm considering using GraphQL with a Django backend service but I couldn't find much information regarding the API documentation. I need some solution to dynamically generate the documentation, perhaps like npm's graphql-docs with a result similar to GitHub's API docs.
Is it feasible to accomplish with graphene-django? If not, what's a good alternative for a python environment?
Yes, it's very easy to do by using GraphiQL, which is embedded in to Graphene.
The instructions on how to integrate this with Graphene are here in the graphene-python documentation. --- basically you need to add the parameter graphiql=True when setting up the API route in your urls.py file.
After it is set up, if go to your API endpoint in your browser, you'll see a nice interface for sending API calls, getting API responses, and reading documentation for both queries and mutations. The documentation is initially hidden on the right until you click on the "< Docs" link.
What are the pros and cons for using django related REST API packages such as tastypie, piston or django-rest for non-ORM calls over simply using views?
I don't think its really a question of whether the API resources directly map to models or not. Its a matter of these API packages abstracting away much of the boilerplate code that you end up doing like checking the request type, mapping to URLs, and serializing your output. Associating a resource with a model is simply one of many features, allowing you to more easily format the representation of the data.
While I can't really see this as an significant negative, I suppose using an API package does require you to conform to its specs and generally work within the realm of its features. But packages like piston or tastypie are so convenient, I can't really think of a real reason NOT to use them if your goal is to expose a RESTful api. You get so much for free. These packages also tend to include extra authentication functionality, and decorators.
Writing basic django views is just the same as rolling your own API. Either use a package for convenience, or roll your own if you really need something custom that they don't provide.
Besides REST to ORM call translations, many aspects can be handled for you by a good API package, such as being able to support multiple serialization backends, handling of authentication/authorization, caching, throttling and more.
If you don't expect your project to ever need these benefits in the future, going for hard coded views may be the quickest, however that tends not to be the case.