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.
I would like to know, if it's possible to get access to the number of collaborators currently editing a google doc.
My account owns the document and editing is enabled for the public.
I'm thinking along these lines:
1) Google Docs API - I have tried to find something in it, but maybe I'm not looking at the right stuff. Does anyone have experience if something like what I need is achievable?
2) Access the Doc through a command line browser (and somehow authorizing - any idea how?) and just pulling the whole HTML tree and then parsing the HTML with regex to find the specific number I'm looking for, then make it into a cron job running every hour for example.
Any feedback much appreciated!
1) Google Docs API - I have tried to find something in it, but maybe I'm not looking at the right stuff. Does anyone have experience if something like what I need is achievable?
No clue on this yet.
2) Access the Doc through a command line browser (and somehow authorizing - any idea how?) and just pulling the whole HTML tree and then parsing the HTML with regex to find the specific number I'm looking for, then make it into a cron job running every hour for example.
GoogleCL sounds like what you want. It will allow you to edit/delete/create/download/upload Google Docs (and by the looks of it, SO much more) from the command line. From there, you can probably port this doc to your local computer and do whatever you want to it.
Some documentation/examples for GoogleCL Docs
For example,
google docs get "Super Cool Doc" superlocaldoc.txt
For authentication, it seems like GoogleCL opens a browser to authenticate each Google service (Docs, Calendar, etc.), but it claims you only have to do so once (once per session? once per full moon? who knows).
I'm in the process of porting a Java desktop application to a ColdFusion web app. This desktop app made queries with very large result sets (thousands of text records) that, while being all right on the database side, could take a lot of memory on the client side if they were buffered. For this reason, the app explicitly tells the database driver to not buffer results too much.
Now that I'm working on the ColdFusion port, I'm being hit by the buffering problem. The ColdFusion page times out during the <cfquery> call, and I'm fairly sure this is because it tries to buffer everything.
Can I make an unbuffered query in ColdFusion?
If pagination is not an option (i.e., you're writing out a report for example), then you'll have to get low level with the java, using setFetchSize(). See this answer. Note that the code in the answer uses the DataSourceService, which, with latest security patches from Adobe, is no longer available on CF8. You'll have to figure out how to get a connection via the adminapi or create a connection outside of coldfusion. Or you could transition your datasource to use JNDI, and then you can lookup the resource yourself without using CF api's.
I'm almost certain that ColdFusion does not provide such a mechanism. As a language, it was meant to abstract the developer away from things like that.
I'd suggest that you look into a few options:
Re-work your query to use pagination, and run it in a loop.
Use the timeout attribute on the <cfquery> to prevent timeouts from happening
Use the CreateObject() syntax to instantiate a JDBC database connection.
With the last option, what you'd actually do is access the underlying Java classes to do the querying and getting results. Take a look at this article for a quick look at the CreateObject() function.
You can also look at the Adobe Livedocs for the function, but they don't really seem helpful.
I haven't tried to use CreateObject() to do querying with the Java database access classes, but I imagine that you can probably get it to work.
Does the VFS work in a cluster scenario?
It does not look like it. The docs on GetVFSMetaData only list RAM and I have not seen anything that discusses calling to another server's VFS.
Before you start flaming, I'm going to tell you that I am trying to convince myself that this is a bad idea.
Basically, I'm trying to create a website with some basic accounting functions. My friend, a consultant who only knows excel, asked if this could be an excel spreadsheet instead of a web interface.
I found myself thinking, why is excel not the better tool in this case? It has all the tools a web2.0 app has (scripting, access to a db, basic formatting), and is made for accounting. You could basically use excel to write a program that fetches data from an SQL database, populates some cells, and use formulas for the rest.
Is there precedent to using excel as one would use the browser to make an ajax-y web2 app?
Why is this a bad idea?
Update: just to clarify I meant this to be more a "rhetorical" discussion. I'm not sure why the rest of the message didn't clarify that...
Well, if you made it in excel, then it wouldn't really be a web application. It would be an Excel application.
Not that that's a bad thing though. If it makes more sense to build the app in Excel, then go for it.
The problems you'll have doing it in Excel will be the same as the problems you run into with any desktop vs. web application. For example, How do you handle deploying new versions of the app? How do you handle updating the app for new (or older) versions of Excel? etc.
ETA:
If you want to avoid the bugginess of Excel VBA and the headaches of managing a desktop application, you might want to look into the Google Spreadsheets API. You can use it to create/update Google docs spreadsheets on the fly, including formulas and lots of other spreadsheet goodness. Using a hybrid of web application and Google Spreadsheets might give you the best of both worlds, depending on what exactly you need to do.
After years of programming in Excel-VBA, the best answer that I can give you for not doing this:
Excel-VBA is buggy! It is probably the most bug-filled app that Microsoft has produced. It's great for some tasks, but forcing it to do a job for which it was never intended will lead to trouble.
I have a few spreadsheets that do similar things, (things Bill never intended), and without exception, they teeter on the brink of failure, and tend to crash with only the slightest provocation.
Sure, you can do it, but the headache is not worth it.
Excel was not meant to be used that way, so it will be painful.
Two better ideas for web-spreadsheet integration:
Take a look at Resolver One, a programmable Excel-compatible spreadsheet with an integrated web server.
Use Google Docs spreadsheets. There is an API to interact programmatically with them.
It's not a bad idea, but it does come with some limitations. If deployment isn't an issue for you, and you don't need "universal" access to the application, your solution will likely save you some time. A web application would certainly be a more elegant approach, particularly if you want to make the software available publicly.
The web is inherently based on HTML and added to with Databases, CSS and server-side languages and javascript (possibly others). As with most things, you should use the right tool for the job. If you want a website then you should use the tools for creating a website.
Excel is not meant to make websites, forcing it to do so will likely lead to more frustration than happiness.
Well, you're going to run it on the server side, you'd probably run into licencing and performance issues.
If you're delivering .xls to the client, then you'd need for all your clients to have Excel or something compatible. But you also lose control over your "site" - what's the point of visiting if you have everything you need locally?
So, the SQL statements would be on the client? That's rarely a good idea.
It's a bad idea for the same reason that writing a graphics editor with MS Access is bad, or coding a MMORPG using Powerpoint is bad :)
I would also say that once you stop using a browser as the client it ceases to be a "web application" - you are really just talking about an Excel sheet which fetches its data via HTTP.
+1 to everyone who said "an excel app is not a web app."
BUT... If you want to use the spreadsheet metaphor for server-side calculations for a web app, or if you want to access the library of financial functions that come with Excel from server-side code, you can use Excel Services. It's exposed via SOAP, interoperable, callable from any SOAP-capable platform.
It's server-capable. It does not actually load Excel on the server, but a non-GUI runtime of the functions.
I think that using Excel as Browser is bad idea, however i think better idea is to use Excel Control in Desktop App.
This way you can control the sql and connections. you can save data as often as you like. you could also implement some update mechanism. App would be more secure and harder to hack.
I think Excel freezes when you try to connect to some outside resource and this way you would control everything.
Did you start by getting user requirements for this application? It doesn't sound like they wanted a website to begin with. Sounds like they wanted an excel spreadsheet with macros.