Other than the ability to automatically generate an interactive documentation for our API using Swagger UI, are there any real advantages of using Flask-RESTplus over Flask-RESTful?
I've used both, and the only reason we switched to Flask-restplus was the desire to have auto generated Swagger documentation. In my experience, there are no other noticeable differences. Flask-RESTplus started as a fork of Flask-RESTful, so if you were so inclined, you could read the commit history and see if there are any other noticeable differences.
update When reading this accepted answer, consider that there is Flask-RESTX which is a fork of Flask-RESTPlus that is maintained, as an alternative option.
I am aware of the fact that this answer is probably too late, but it still might be helpful in the future.
According to https://github.com/noirbizarre/flask-restplus/issues/593, the Flask Restplus is most probably dead and abandoned. The last commit was on October 1, 2018. It looks like the project is not being actively maintained anymore.
Therefore, I advise that you use Flask Restful despite the auto generated Swagger docs in Restplus. Since Restplus is not maintained, it is most likely that the implementation will sooner or later go out of date. Rather than switching to Restful once Restplus goes out of date, I think starting off with Restful itself would be the better idea here.
Just my two cents... :)
update You should also consider using FastAPI which is a framework that is becoming popular (see google trends). And, differently from Flask: has built-in data validation, supports asynchronous tasks and you also get the Swagger UI.
You stablish the endpoints with decorators like in Flask and it is reportedly faster.
Check: https://fastapi.tiangolo.com/
Hope it helps.
Related
I think I read all the documentation and I'm still confused on wether LB4 is ready for production use?
As I understand, it still misses Many-to-Many relationship and some OpenApi specs implementation. The documentation is very scarce so it left me very confused.
We are currently searching for good node REST solution and LB4 looks very promising with things like TS and dep. injection(more modular design), but it looks like we'll have to skip this one for now. Is anyone using this at all? I would be very glad to hear some experiences.
We have used it for one of our application. I agree that there are some gaps but for most of the stuff, you can handle it pretty well in loopback 4. The most significant reason for that is the awesome extensibility of LB4. That's the reason why we could do authentication, authorization, bpm integration, etc. in our application by creating Components in LB4.
After we were done with it, we thought about sharing our experience with open source world. So, we published a loopback 4 starter application which demonstrates a multi-tenant architecture, supports authentication via passport strategies (using loopback4-authentication extension we created), supports simple permission keys based authorization (using loopback4-authorization extension we created), soft delete entity (using loopback4-soft-delete extension we created) and DB revisioning, upgrades (using db-migrate package).
Hope it helps clear your doubts about loopback 4. Trust me, its an awesome framework with lots of futuristic goals.
I like fast code execution (because of that I switched from Python to Go) and I do not like dependencies. Amazon recommends using SDK for simpler authentication (but in Lambda I can get tokens from IAM from environment variables) and because of built into SDK retry on errors (few lines of code, as I think). Yes it is faster to write my code using SDK, but what additional caveats about using pure HTTP API instead of SDK? Am I too crazy about milliseconds? Such optimizations worth it?
Anything you do with AWS is the result of an API call, whether executed by CLI, Web console, or SDK.
The SDKs make it easier to interact with those APIs. While you may be able to come up with some minor improvements for some calls, overall you will spend a lot of time doing it to very little benefit.
I think the stated focus on performance belies real trade-offs.
Consider that someone will have to maintain your code -- if you use an API, the test area is small, but AWS APIs might change or be deprecated; if you an SDK, next programmer will plug in new SDK version and hope that it works, but if it doesn't they'd be bogged down by sheer weight of the SDK.
Likewise, imagine someone needs to do a security review of this app, or to introduce something not yet covered by SDK (let's imagine propagating accounting group from caller role to underlying storage).
I don't think there is a clear answer.
Here are my suggestions:
keep it consistent -- either API or SDK (within given app)
consider the bigger picture (how many apps do you plan to write?)
don't be afraid to switch to the other approach later
I've had to decide on something similar in the past, with Docker (much nicer APIs and SDKs/libs). Here's how it played out:
For testing, we ended up using beta version of Docker Python bindings: prod version was not enough, and bindings (your SDK) were overall pretty good and clear.
For log scraping, I used HTTP calls (your API), "because performance", in reality comparative mental load using API vs SDK, and because bindings (SDK) did not support asyncio.
We have a (AJAX heavy) web application hosted in cloud across servers and we need to monitor the availability of this service. Requires logging in to the application with a username-password, perform some searches as that user etc.
Since we plan to use Nagios for some other monitoring tasks, we decided to use Nagios for web application monitoring too.
I came across three such solutions:
Webinject: I don't feel like using this. Project not under active development. It was last released in Jan 2006. I can't see any support/help available. Also I suspect how will it behave with Ajax.
Cucumber-Nagios:
I tried using this. It involves many Ruby components and found that you have to have in-depth knowledge of Ruby platform to make all these components work together. I am not a Ruby guy and having tough time making all these components work together. Also even this project is not under active development and I don't see support/help options available. I posted a bug 4 days back and don't see any response yet.
Selenium plugin for Nagios: Haven't tried it yet. Will try now.
Any more solutions available?
Also, since I don't see any good actively developed solutions for monitoring web applications using Nagios, I suspect if it's really a good approach to use Nagios for this? If not, what alternatives do I have? In short what is the best approach to monitor web applications availability?
Edit 1: We can't afford the Nagios XI paid version and will prefer open source solutions.
If not, what alternatives do I have?
Although Nagios was one of options that we've considered, we've chosen OpenNMS for monitoring purposes. Rationale for our decision is that OpenNMS is highly reliable and configurable free open-source tool and additionally, most of our applications are Java-based; OpenNMS offers integration with JMX. However, bear in mind that if you're demanding very complex tests for your Web site maybe it's better to look elsewhere. OpenNMS can be set to check for HTTP status codes etc., but if you're looking for complex scenarios take a look at:
Apache JMeter (we're using it mainly during the testing phase)
Selenium (can be well used even in production phase)
I need to create a In-App-Purchase backend for a iPhone App, and think in build it on GAE.
However, after my experience in a recent gig in one of the largest GAE customers and reading stuff like this http://www.agmweb.ca/blog/andy/2286/, I wonder if right now is good idea (ie: reliable) to host a django+gae project like this. I expect low traffic in the first months. Mainly a API-based website with some web front-end.
Or exist any kind of hints so get possible get a reliable operation using django + gae? I'm using App engine Helper, but could switch to another implementation if is more rock solid.
From my experience it seems that Django needs a bit of effort to get working correctly, and using it on AppEngine is a bit different to how you would use it otherwise. I suggest considering the possibility of using a different framework.
Personally, I suggest Tipfy as it was built specifically for App Engine, but there are quite a few frameworks I haven't even tried but have heard great things about.
IIRC the problem with Django poisoning instances due to exceeding the deadline has been solved.
I've been looking at Rietveld as a solution for the lack of code reviews at my company. Can it be set up on a server in-house without using App Engine? It seems to have a bit of App Engine specific code, and I'm not sure it could be set up on a plain old Django/Apache install. I've looked around, but haven't found any information about this.
Check out http://django-gae2django.googlecode.com/svn/trunk/examples/rietveld/README
The gae2django project lets GAE apps run against django instead of the GAE development environment.
That means you can run rietveld under django directly, using (by default) an SQLite backend. You can also use mysql or any other DB backend django supports.
That, plus a web server (e.g. Apache) with WSGI integration, makes a local rietveld install run nicely.
What about using one of these projects that provide the same backend services as GAE?
Typhoon AE
Appscale
There may be more, these are just the ones I know about off the top of my head.
A bit of App Engine specific code? It's supposed to be an example App Engine app, so yeah it's pretty well tied to it. But, you're right, it does use Django which could make it somewhat more feasible to port. I'll second #cope360 recommendation, but from the sounds of your question, it doesn't sound like you've done much with App Engine. If it's only used by a few people, try running it on the GAE SDK itself.
Beyond that, I'd think you could take most of the code in the "codereview" directory and build you're own Django/apache app from that.
Rather than fussing around with a port or other GAE emulation, I would consider using ReviewBoard.
Review Board is a powerful web-based
code review tool that offers
developers an easy way to handle code
reviews. It scales well from small
projects to large companies and offers
a variety of tools to take much of the
stress and time out of the code review
process.
For too long, code reviews have been
too much of a chore. This is largely
due to the lack of quality tools
available, leaving developers to
resort to e-mail and bug tracker-based
solutions.
We've seen a lot of time and energy
wasted doing code reviews both in open
source projects and at companies. In
both cases, code reviews were
typically done over e-mail. A
significant amount of time was spent
in forming review requests, switching
between the diff and the e-mail, and
trying to understand what parts of the
code the reviewer was referring to.
So in an effort to keep our sanity and
improve the process both in our open
source projects and at companies, we
wrote Review Board. We hope it will be
useful to your team too so you can
focus on what's important: writing
great products.