I have a Sproutcore application which uses CouchDB hosted by Cloudant. In devenv I'm using Sproutcore proxy to forward requests to Cloudant (due to single origin policy I obviously can't call a arbitrary hosts from my JavaScript).
What would be your suggestion on hosting the app. CouchApps loading script is failing with obscure error (please note Sproutcore app is around 40 MB of JavaScript and resources).
The thing about hosting an app that talks directly to couchdb is that you are restricted by the same origin policy, so the server that serves up your SproutCore app, has to be on the same domain as you access your couchDB database. If your host provides a static file server, you could use that, but your best bet is probably just to save it as a couch app.
The Key with deploying SC as a couch app, is that you have to set up the URL's that sc-build generates to point to the correct location. This can be done with the buildfile setting something like this:
:url_prefix => '<database>/_design/<designDocument>/'
This way the links point to the right location.
You can also setup CouchDB url rewrites to get simpler urls if you wish. Have a look here for more discussion on this:
https://groups.google.com/d/topic/sproutcore/-D-5T5yPg3A/discussion
PS: 40mb seems overly large! do you have many images? I'd be concerned if you had that much JS/CSS.
Cloudant hosts its clusters (mainly) on EC2 in the us-east-1b or us-west-1b availability zones. If you cannot deploy as a CouchApp you should try to colocate your application layer next to your DB cluster. That will minimize the latency between the web server and the databases.
You can do this yourself by getting an EC2 instance and running a web server on it, or you can use a third party host that hosts on AWS (e.g. Heroku).
In both cases, you will need to run a small proxy from your web server to the database. That's why simply hosting on S3 is not an option at the moment.
Once you deploy your app to a web server, don't forget to check that your web server and your database are in the same AWS availability zone. If they're not, just ask Cloudant to move your account.
Related
The Problem
I am student assigned to a project to create a rudimentary social media app. We are planning to use Flutter to build the app and we are going to use MongoDB and Express for the database and API respectively. The goal is to be able to use continuous integration for our project through Fastlane and GitLab.
Initially, I thought to put the API and Flutter in separate Docker containers and to host the database on my desktop, but I realize that might not be the best solution.
The Question(s)
How should we setup the database and the server that we all have access to the same data in a database? Basically, how should we best set up our project environment to work as team, in terms of:
hosting the database?
setting up Express and Flutter for continuous integration?
If you are using MongoDB just set up a cluster on Atlas it's free as long as it's a relatively small application (up to 500MB). After you sign up, you will create a cluster, and then Atlas will give you instructions on how to connect to that cluster using node.js.
Basically all you do is throw in the link to your cluster with your configured password in your database connection link. This is all in the cloud so you can access it from anywhere after you whitelist the IP's that will be accessing it remotely. (alternatively you can whitelist all IP's which is the easier way of doing things it's just A LOT less secure.) but it's an okay option for a school project.
You can then use Heroku to host your app which allows for a custom server setup like you will have with Express.
You will need to use dotenv for heroku as well as securing your database link and password, so read up on that as well.
I recently developed a web app locally, with a React frontend that interacts via proxy with a Node.js backend that interacts with MongoDB Atlas. Everything works locally, and I am ready to actually deploy the web app for public use.
How does hosting work with a full stack web application? Do I host the entire web app in the same place (e.g. S3 bucket), or should the backend and frontend be deployed separately? I have never done this before, so I appreciate any help I can get.
Yes, you can have two different servers for frontend and backend.
You can use theHeroku platform to deploy your backend app, and Mlab to provision a Mongo database. These platforms has free tiers where you can experiment and learn about deployments and clouds.
Once you are comfortable with these then you can move to Elastic Bean Stalk on AWS to provision servers and also database.
Now mlab is not available as it is already been acquired by mongoDB only, so I would recommend you to create the database on Atlas cluster which also offers a free tier.
Rather than using the Heroku, I would suggest you to use MongoDB stitch which is also the backend as a service. If you will use stitch then you can also seek for support from mongoDB people but in case you will use heroku then you will not receive any support from them.
You can refer to the documentation of stitch for more information https://docs.mongodb.com/stitch/. This has complete guidance how you can deploy your app using stich and can use mongodb database.
However if you need more help, please ping me anytime.
Is it secure to have data be sent to free database at mongolab from heroku app.
Data could be like emails, and preferences.
Or do you need ssl, i've read about mongodb ssl.
I've asked around but couldn't find anything specific to mongolab.
From MongoLab's documentation:
Securing communications to your database
You should always try to place your application infrastructure and
your database in the same local network (i.e., datacenter / cloud
region), as it will be the most secure method of deployment and will
minimize latency between your application and database.
When you connect to your MongoLab database from within the same
datacenter/region, you communicate over your cloud hosting provider’s
internal network. All of our cloud hosting providers provide a good
deal of network security infrastructure to isolate tenants. The
hypervisors used do not allow VMs to read network traffic addressed to
other VMs and so no other tenant can “sniff” your traffic.
However, when you connect to your MongoLab database from a different
datacenter/region, your communications are less secure. While your
database does require username / password authentication (with
credentials that are always encrypted on the network), the rest of
your data is transmitted unencrypted over the open internet. As such
you are potentially vulnerable to others “sniffing” your traffic.
Using MongoDB with SSL connections
Available for Dedicated plans running MongoDB 2.6+ only
To further secure communications to your database, MongoLab offers
SSL-encrypted MongoDB connections on Dedicated plans running MongoDB
2.6 or later. Even when using SSL, we still recommend placing your application infrastructure and your database in the same
datacenter/region to minimize latency and add another layer of
security.
I did the same thing as you and sent email to ask mongolab for detail. I got the answer, sharing it with you and hope it can help you.
The below is the reply.
As long as your Heroku app and MongoLab database are in the same cloud
region, we consider it safe to communicate between Heroku and
MongoLab, as AWS' infrastructure prevents packet-sniffing within
regions. If you use the MongoLab addon on Heroku this is automatic,
but if you use a deployment provisioned directly at mongolab.com
you'll need to manually select the matching region.
It looks like the connection between heroku and mongolab is in the same region. Both are secured by AWS so I guesss you don't need SSL. If you need it to be very safe, you still need SSL for extra security.
Hope it can help
Scenario: The login page for a host of web applications lives on an internally hosted server. When this server gets rebooted we need this login page to remain accessible, even if it just displays a friendly message.
The thought I am having is rendering this login page on a different app hosted in the cloud. When our server then gets rebooted the cloud hosted app will instead render a different message.
Is this even a viable option?
What are the pitfalls of this approach?
Are there any cleaner and better alternatives? (And "host the login page in the cloud" has already been considered but I'm looking for alternatives to that as well)
this is totally possible, what your describing is a reverse proxy or load balancer have a look at configuring apache as a reverse proxy server
I've recently migrated an application from heroku to amazon-ec2 because of recomendations from a security consultant. Yet, he didn't know deeply heroku and the doubt remained.
Can access to a Heroku PostgreSQL DB be restricted for it to be accessed only by the application?
Would you recommend Heroku for security critical applications?
This is a deceptively complex question because the idea of "restricted so that it can be accessed only by the application" is ill-defined. If your ultimate goal is simply to keep your data as secure as possible, then Heroku vs. AWS vs. physical servers under lock and key involves some cost-benefit analysis that goes beyond just how your database can be accessed.
Heroku limits database access via authentication. You share a secret (username/password) between the database and the application. Anyone who has that secret can access the database. To facilitate keeping the secret secret, all database access is or should be over SSL.
There are other ways to restrict access in addition to authentication, but many of them are incompatible with a cloud-based approach. Also, many of them require you to take much more control over the environment of your servers, and the more responsibility you have on that front, the bigger the chance that issues totally separate from who can hit the postgres port on your database will sink you.
The advantage in using AWS directly instead of through a paas provider like Heroku is that you can configure everything yourself. The disadvantage is that you have to configure everything yourself. I would recommend you use AWS over a managed service only if you have a team of qualified and attentive sysadmins to configure, monitor and update your environment. Read Heroku's security policy page. Are you doing at least that much to protect your servers in your own configuration on AWS? If not, then you might have bigger problems than how many layers of redundancy are in place around your database.