How to affordably release a webapp for my job company - python-3.x

First of all, I'm not really sure if this question goes here in stackoverflow or if I should ask it on another place. Please if that's the case, indicate me in the right way :)
So, for context, this is an app that I was asked to develop for my job. At first I thought in doing a webapp and host it inside the company servers and domain (intranet), but it isn't possible due to external issues that I can't control.
Is there another way to achieve this? The app must have a database and should be accessible for a bunch of users at the same time.
Of course we want to spend the least amount of money possible to make this happen. Also, using a workstation of our own to host everything is not possible either.
Edit: I didn't finish developing, but for now I'm developing it in Python Flask.
The number of users is small really, just up to five people.

OK - I guess a lot of what you'll get in response to this is your definition is too vague. Things such as scale, number of users, programming languages used to create the web app etc are important when talking about hosting.
However, for me, there are three very good options out there for free hosting, up to a certain amount of traffic.
1.) Heroku - Heroku.com
A world known web hosting platform. You can publish code through GitHub, and it has some extensive coverage for different types of web apps. Definitely worth a look.
2.) Netlify - netlify.com
Similar to Heroku, but used by some major companies. Allows you to host for free to a point, and is relatively simple to get started with.
3.) Vercel - vercel.com
A bit more technical in my opinion - but again, very similar to the above two and has a free tier.
All three are great options, and I'd recommend looking into them in more detail to see what option is best for you. Can't go wrong with any of them.

I had a similar problem: A Python-Flask-SQLite app for me and my office pals to use together.
The solution was creating one .exe file with pyinstaller, hosting this and the database files in a network drive (one that everyone that will use the app has access). As everybody (~10 people) sees the same db, things works fine!

Related

Things to consider before launching a BIG website?

I’m about to launch a classifieds website like gumtree and OLX in South Africa…., but it’s not gonna be as big as Gumtree or OLX obviously. It’s going to operate in one province…planning to expand it over time.
The site works like a charm on my local machine, but I’m concerned coz I’ve never launched a big website before. Plus, I just graduated from University this year – no work experience. But I’m positive that if Facebook and Twitter were built by students, I too can build my own thing and run it successfully.
Are there any key issues to take into consideration before launching a big website ?
There is probably more to consider but I here are a few
Hire a lawyer and get a terms and conditions for your site with proper legality. You dont want to short yourself on this.
Get a decent backup and restore solution that you test and make sure that it works. Remember if you have paying clients with your site there will be implications for down time.
Get a security certificate https://
Know what you paying with your hosting solution. If your traffic does spike you could be in for a very large bill that you cant afford. And if you dont have scaling your site might run really slow. So get to know your hosting solution really well.
Good luck

How to deploy a node.js app for testing

I just created a simple web app using the MEAN stack, and I want to host it online somewhere (I'm brand new to the MEAN stack). I have done this with static pages (using only HTML and CSS) using other sites such as BitBalloon, but since this is my first deploy with the MEAN stack, I really don't know how to get it online. I'd prefer using a free service for now since I just want to test my app, and share it with friends. For example, BitBalloon will give you an address like http://stoker-neutrons-12345.bitballoon.com/, which is perfect for testing your app, and sharing it with others. Is there a similar method/hosting site available for apps built on the MEAN stack?
This question will probably be closed quickly for being a "recommendation question", which doesn't fit SO's target, but still, here are two recommendations:
RedHat OpenShift provides a free tier with plenty of functionality.
Heroku's "free" package might also work if you're just testing. However, your container will go to "sleep" after 30 minutes of inactivity.
Be prepared, that both options require some effort on getting things rolling (steps are different than simply FTPing some files). But at least Heroku provides some quick start instructions (RedHat probably too, but I haven't checked)

Development Platform for Small application

I will soon be developing an application to log and priorities worker shifts. It only needs to be small, and simple, but I am wondering what framework to use. All that needs to happen is boxes with names are in 3 lists, and the user can switch these around at will. It must log the times, which I will need access to in real time.
Im new to application development of this sort, and would like any suggestions. I have time to learn new technologies / languages.
Portability / device independence would also be useful. Should I consider a Web Application in Javascript? or something more like Python.
Thanks.
Even if your application is going to be simple that does not mean that whole system will be simple too. I can imagine that your app will serve only as a front end to something much bigger. If that is a case and you really have freedom to choose what language you will develop your app with consider choosing something that you will feel comfortable to work with. But before you will make your decision I would go to whoever gave you that task and try to get as much information about it as you can because expected features can help in choosing technology.
First of all, it seems that it is up to you to decide if it should be web or desktop app. In my opinion it is completely wrong situation. You should get clear requirements on what kind of application customer expects and in what environment it should work. And I would not move a finger towards a code before somebody gave me that information. You write that portability and device independence would be useful but is it actual requirement or you just think it would be nice feature to deliver?
EDITED (to answer a question in comment)
Probably there is as much possible solutions as people that would answer you so in the end you will have to make your own choices.
One way of doing it (considering that you want to learn something new and have a challenge :) would be implement WCF service that would act as a data provider from your database (so every GetUsers(), GetVacationDays() methods would be in it) and it would take care of some business logic (for example CalculateMaxValidWorkingTime() or whatever). That service would be a real power horse of your system. Since you don't have clear requirement whether it should be desktop or web app you could satisfy both possibilities by creating thin clients that would communicate with your service and they would be just a pretty front ends. And if you keep in mind that you can consume webservices practically with everything from C++ to .NET (C#/VB) to Javascript to Python to PHP after you done with service you would not be constrained with one particular technology/language.
Regarding databases I won't advice because personally I hate dealing with them and it always was somebody else's task to provide me with pretty API :)

Sandbox solutions seem to be too severely crippled

I am learning SharePoint and the different kind of solutions you can deploy. From the training I am watching it seems like you should try your best to use a Sandbox Solution when ever possible. This is because Farm Solutions can mess things up too much.
However, two of the main things I would do with WebParts are not supported in Sandbox Solutions. Those are Visual WebParts and WebPart communication. (The first is not allowed because it needs to hit the file system and the second is disallowed because it uses reflection).
It seems to me that my WebParts will always want to do at least one of those things. (WebParts that don't communicate are not really that modular are they?)
Am I missing the point or are Sandbox Solutions a "nice idea" that are not really used in actual code?
Yes, I agree with you that Sandbox solutions are very restrictive.
But, it is that restriction that gives them their value. Due to the restrictions a Sandboxed solution cannot bring down a farm (atleast that is the theory, someone may find a way to do it).
This means that you can open up to many more users to deploy things on the farm. It is also a requirement to deploy things to SharePoint Online.
That Sandbox solutions are more restrictive, means that development is more cumbersome, you have to program your way around the restrictions. This makes solutions more expensive. Therefore, the default should be farm unless you have a good reason not to use it.
I think some of the comments here are missing the entire point of a Sandbox solution, they have been deliberately given a reduced set of privileges for many reasons:
a) A site collection administrator can add a SB solution hence they need not be farm admins therefore better security of the farm.
b) You can trust that an SB will NOT bring down the farm, they don't even run under the normal SharePoint worker process, instead they are hosted under their own process that acts as a host to check to see if the resources accessed are allowed for an SB solution.
c) The cloud is coming, there’s no getting away from that fact, when somebody else is hosting your SharePoint solution do you really think you'll get access to the farm?
I think understanding the impact of running as a Sandbox Solution from a non-developer perspective is important, after all you wouldn't create a custom solution of any kind and expect the customer to grant you domain level accounts to run it, therefore when creating SharePoint solutions, think running your solution with the minimal amount of permissions by default, if there is really no other way then explore farm solutions.
Here's a useful guide from MS:
http://msdn.microsoft.com/en-us/library/ff798382.aspx
If your environment allows you to install farm solutions, then yes, sandboxed solutions are restrictive and stop you doing what you want.
However, if your environment does not allow regular solution deployment, as is the case with shared hosting and some large corporates then they are not restrictive because without them you wouldn't be able to use custom code at all.
Sandbox is horrible, i totally disagree with the statement "it is that restriction that gives them their value". you cannot do a many thing in sandbox.
1. no session
2. no web-part communication
3. no file upload controls
4. no redirect...
and it just makes things painful as hell. we are in the midst of developing an enterprise application facing outside users, my advice, if you considering Sandbox for these purposes, i would say add 150% more time for your project just to deal with sandbox issues.
most people talk about benefits, but all the benefits are not really benefits.. for example, if even a single sandbox application code raises exception which is unhandled... good luck, it will crash the entire farm, and tracking the issue is real nightmare.
if you can stay out of sandbox

Is Azure mature enough for actual production usage yet?

I toyed around with Azure in January this year and though it looked great in theory, I wasn't even able to deploy a simple dummy application due to various bugs I encountered.
I'd like to have another look, however I don't want to spend another two days in vain. If you have recently tried Azure, I would be interested to hear about your experiences.
Thanks,
Adrian
Yes, Xbox Live, Microsoft's BPOS suite, Live Messenger, and more all run on Azure.
If it can run Xbox Live, it can run your production app.
I'm using Azure for production stuff, and I've found it reliable, but pretty hard work. Hard work because:
The reference documentation is minimalist. Many functions are covered by a one sentence explanation and no examples.
While being much better than nothing, not everything that works on the development fabric will work on production.
When things go wrong (especially when a role keeps recycling) it can be hard to work out what the problem is, although remote desktop can help a lot.
Windows Azure works for us and allows to deploy rather complex business solutions with rather impressive auto-scaling capabilities.
We have already migrated all of the major projects towards Azure so far.
If still in doubt, take a look at 50+ case studies here.
Visual Studio 2010 added a BUNCH of functionality towards Azure development. I think it is enough to move Azure up to snuff for production apps.
However, if you don't have Studio 2010, I would wait till you can get it.
Another example that I like (I was personally involved a teeny weeny bit so I'm biased :) ). All Twitter/Facebook results on Bing.com are piped through an engine that runs on Windows Azure. It consumes multiple realtime feeds and surfaces them on Bing. You can do the math on the scale since it is crunching on all of Twitter's data and has been doing so for months

Resources