I am making a android app which will have around 1-2k users per day, all I need is a json file which is hosted on https://name.github.io/repo/filename.json.
Is their any limitations on doing so?
Is their any better way to host this json file to fetch the data?
I will be also updating this json from time to time.
GitHub doesn't consider using using GitHub Pages as a CDN for hosting static assets to be within its guidelines for GitHub Pages. The intended purpose is to host a personal blog or website or a website for your open source project.
The documentation linked above outlines acceptable uses and limits.
Instead, you could end up storing this JSON file in some sort of cloud bucket (e.g., S3), possibly with a CDN (e.g., Cloudflare) in front of it. That would probably keep costs minimal for your app.
Related
I am starting a new career as a developer and I am trying to offer my services to shops in my area for free to use as my portfolio. My question is, is it okay to deploy/hand off a website to my client using google domains and GitHub pages? Since it is the cheapest way to deploy a website?
What is the downside of doing so, or should I just suggest using a hosting site such as Hostgator?
I have created a website that is ready to be handed off.
Here are my thoughts:
For a simple static website that doesn't have server-side scripting (such as PHP, etc.) GitHub pages are a fine route for deploying your website.
Another factor to take into account would be the GitHub pages limits.
No larger than 1 GB
Bandwith limit of 100 GB per month
Limit of 10 builds per hour (excluding custom actions workflows)
Other options
AWS
Google Cloud
Heroku
"I am trying to offer my services to shops in my area for free to use as my portfolio."
Based on this alone, I will tell you that GitHub pages are probably the most ideal way to go for a portfolio. If your website is more complex, however, I would go for one of the options I listed above. Since GitHub pages is free and very easy to use, though, I do recommend it. Say your website grows in complexity and you begin to feel you need more wiggle room/flexibility to control how it's hosted, you can always start using something else.
I would personally, at the very least, use GitHub pages as a starting point for a static site.
I want to host some html files on Google Cloud and wondered, if this is possible to do, without adding a custom domain...
With for example Cloudflare or AWS, that's possible...
GCS objects can be loaded just fine from a web browser, with or without a domain. They follow either of these naming schemes:
https://storage.googleapis.com/YOUR_BUCKET_NAME/YOUR_OBJECT_NAME
https://YOUR_BUCKET_NAME.storage.googleapis.com/YOUR_OBJECT_NAME
If you simply need to serve resources via a web browser, this is quite sufficient.
If you need a bucket to represent an entire website, it'd be a good idea to use a custom domain. This enables a handful of nice, website-like features, such as defining default pages when none is specified as well as providing a customization 404 page.
You have three options (well, only two of them are really viable, but the last one can be useful in certain situations).
In order of ease to use and viability:
1) Google App Engine:
The default Google App Engine app is served out of *.appspot.com site, so if you create a project call "cutekittens", your site address will be cutekittens.appspot.com.
Furthermore, you can choose to do something simple like a static webpage, or you can host an entire webapp on Google App Engine. It's easy to use and very powerful. Google App Engine supports its own storage (Datastore), bigdata (Big Query), and MySQL (Cloud SQL) solutions and all of that can be served out of the default appspot.com site which acts the the front end.
2) Static Website on Google Cloud Storage. Google Cloud Storage is less powerful but should suffice if you just need a static website served. It uses "storage.googleapis.com/[BUCKET_NAME]/[OBJECT_NAME]", in which your object is probably an index.html.
3) Use a Google Compute Engine VM on static IP. This option is probably the MOST powerful, as you can do anything you want on your own VM. However this is also the less friendly usage since you will need the actual IP address to access the site and its resources.
We are currently using an LMS system for an online course. Almost all of our material is online. We are starting to SCORM format our online material. Instead of attempting to physically merge all of our HTML pages within a SCORM file, isn't there a way to simply have the SCROM file launch a given URL automatically? All of our material needs to be in SCORM format in order for our LMS system to track the time spent in our LMS course which is why we are making the switch.
Is there a way to instantiate this in the manifest.xml or launchpage.html?
Some companies including mine, use a local file which launches a frameset to our websites. The SCORM runtime communication between the two sites can happen using a HTML5 postmessage. For example, if a learner gets a score on your website, you can send the information to the code that sits in that small local file on the LMS. In turn, you call SCORM runtime from the that file. This can also happen in reverse. Here's an example by Claude Ostyn:
http://www.ostyn.com/standardswork/xdomain/remotecontentdemo.htm
At minimum if you can run the base index.html file and point your CSS and JavaScript to your content server or CDN that would solve the double IFRAME or trying to get around browser security due to X-domain issues with your domain trying to access the LMS's runtim API on their domain.
This does cause a obvious authoring challenge or at minimum a massive search and replace in files on your project.
Only other way still requires the IFRAME workaround to get around it.
I am building a Spring Web Application hosted on Elastic Beanstalk. I use S3 to store user uploaded images which works great. What I don't understand is how fetching images from S3 to the client work. I found three alternatives.
1.Get the image in a controller and send it to the client. Like this:
S3Object object = amazonS3Client.getObject("bucketname", "path/to/image");
2.Open up all images and reach it directly by an URL in the client. Something like this:
<img src="http://aws.amazon.com/bucket/path/to/image.jpg">
3.Use signed download URLs that only working for a certain time. Like this:
GeneratePresignedUrlRequest request = new GeneratePresignedUrlRequest("bucketname", "path/to/image");
String url = conn.generatePresignedUrl(request)
Im not sure which approach to go for. Routing it through the web server seems unnecessary, since it loads the server. Open the URLs to anyone might higher requests and costs since anyone can use the images. And the third way is new to me, haven't really seen anyone practising this which makes me insecure if this is really the way to go.
So, how is this usually done?
And how is this used in the development environment versus production environment. I guess its not changing? Or is it common to use spring profiles to change the location of static content while developing and only use S3 for production?
If your hosting Javascript, CSS on S3, is it then most common to go for approach 2 and open them up for everyone?
For me it depends upon the requirements you have for access control for images uploaded by a user.
If the images are non-sensitive i.e. it wouldn't really matter if someone else got hold of another user's images, then I would go for approach 2.
If on the other hand it would be a disaster if someone managed to get hold of another user's images, then I would go for approach 3 (or some other form of expiring token access to the images).
The last time I did this I went for approach 2 because the images were non-sensitive. To try and prevent people from discovering images, we did apply a hashing function to the name of the image, but again I wasn't massively concerned about this. In either case, a well defined bucket structure that can be easily worked out by the application when constructing the URL for an image is useful. So for you, perhaps consider something like:
s3:bucket_name/images/users/<hashed_and_salted_user_name>/<user_images>
As for you request regarding dev vs prod environments, then matching a bucket name to the Spring profile is the approach we used. So for example:
s3:bucket_name/prod/images/users/user/foo.jpg
s3:bucket_name/dev/images/users/user/foo.jpg
As you can probably guess we had Spring profiles named "prod" and "dev". The code for building image URLs took into account the name of the current Spring profile when creating the URL. Gives a nice separation between environments.
In terms of CSS and Javascript, then I tend to host obfuscated/minified versions in the production S3 buckets, and full versions in the dev/test buckets (mainly for performance rather that trying to hide code). In addition I'd use some sort versioning/naming structure in how you host CSS/Javascript in S3 so that you can determine what "version" of resources your app is using. So for example:
s3:bucket_name/css/app-1.css
s3:bucket_name/css/app-2.css
The version of the CSS/Javascript resources is updated each time you push a new version into production.
By going down this path you kinda look at S3 as the final resting place for a piece of Javascript/CSS when it is ready to go into the wide world of production. Once there, you know it will never change. If CSS/Javascript does change, then the user has to fetch a new resource from S3 as the version will be incremented. You can hook this into your build process so that your main app is always referencing the latest version of CSS/Javascript. I found this has two useful functions:
Makes it very easy to determine which version of a resource your application is running with
Makes it very easy to cache resources (either with browser or something like CloudFront) as you know they will never change
Hope that helps.
I've got a few HTML pages with the requisite images, css and other bits and pieces, all static content no CGI required. I currently host it on an Amazon EC2 image that I need to have up and running for a different application. Ideally I'd like to move the hosting of the static content off the EC2 image so that it's independent of any single EC2 instance. I'd like to host it on one of the free or at least pay as you go cloud options.
The options I've come across are:
Windows Azure, in this case I haven't been able to get .html pages working and even if it is possible would it mean I'd have to update the whole Windows Azure app everytime I needed to update an image? Or is there an easy way static web content could be served up from Azure blobs?
Amazon's S3, I think I'd have to put fully qualified URL's into each HTML page for each image, css etc. file but that wouldn't be too bad. This seems like a reasonable option.
Google's App Engine, only spent 10 minutes looking at it but it seems like it would work as well.
Wordpress, I could just incorporate the HTML into a wordpress blog site but I find the themes a little bit too restrictive, pages can only be so wide etc.
Is there an easier way?
Update:
After some further investigation the two best ways I found are the S3 approach as described by Sug and Windows Azure Blob storage (rather than a Windows Azure service).
The difference between S3 and Azure Blobs is how the CNAME can be managed:
For S3 you'll end up with a CNAME like mybucket.mydomain.com
For Azure you'll end up with a CNAME like *.mydomain.com where * represents whatever you like. To access blobs the path is then *.mydomain.com/container/.
So S3 dictates the CNAME host but gives full flexibility on the resource path. Azure gives full flexibility on the CNAME host but dictates the first part of the resource path.
For serving only static files, using services like AppEngine or Azure will be over kill.
The simplest solution will be to use AWS S3:
1) No coding required
2) Pricing
3) You can easily map a bucket to your own domain or subdomain.
4) Free client tools to manage your buckets as it was dead simple filesystem.
I personally use S3Fox but there are many others (BucketExplorer is another example)
“S3 dictates the CNAME host”
Amazon has a CDN service called CloudFront, that uses an S3 bucket for storage. You only pay for S3 data transfer (I think).
Your bucket contents are copied to Amazon’s CDN, meaning superfast access from around the world. However, because it’s a CDN, files are automatically cached for a long time (so there’s a delay when re-naming or deleting files).
Just using an S3 bucket, and setting up another domain to point to the bucket via a CNAME, might be the best idea.
For simple sites like this, I've had good experiences with Nearly Free Speech.Net.
GitHub.com pages. You just need to know Git basics, check out the gh-pages branch, and put the static content there. It will be available at http://your-name.github.io/your-project/
For example, this is my project's file.