nicola / isawake

:sunrise: The (eventually) biggest crowdsourced database of people awake, sign up with a pull-request
http://isawake.me
27 stars 25 forks source link

Using github to host the website #6

Closed nicola closed 10 years ago

framp commented 10 years ago

DNS-wise it's pretty easy, just a wildcard A record. But on github you can have only one domain per repository It can't be done, as of now

..without writing a post receive git hook on a remote server which would trigger a hub create username.isawake and push the appropriate code

Doesn't look nice and - given the other features we're planning - we need a server

mtt87 commented 10 years ago

KISS, I see 2 options:

Use a random email for Amazon AWS free tier for 1year, we have everything we need.

or

I have a new DigitalOcean droplet (London) that right now is just for experiments so we can host everything there.

nicola commented 10 years ago

I am not sure this is correct. Basically, the A name of isawake will point to the github server. *.isawake.com will point as a CNAME to isawake.com. That should work I think.

Should we give it a try? I actually don't know how to get a website for a repo.

mtt87 commented 10 years ago

They suggest to not do it anyway: https://help.github.com/articles/tips-for-configuring-a-cname-record-with-your-dns-provider

"Do not use wildcard DNS records (e.g. *.example.com) with GitHub Pages! A wildcard DNS record will allow anyone to host a GitHub Pages site at one of your subdomains."

nicola commented 10 years ago

Wow. I am now scared whether this would be an issue with our existing system. We could eventually use subfolders. What is your opinion on this? It would not make sense though..

mtt87 commented 10 years ago

What do you mean? Actually is not on Github no?

nicola commented 10 years ago

Nope, but the * is not really clear to me.

framp commented 10 years ago

AFAIK the github CNAME file does not allow wildcards (I tried to set that up last year and it didn't work). Without the CNAME, even if we're able to point our subdomains to github we won't be able to make github understand it should serve this repository.

Btw, I don't see that as a problem. If we want to support jawbone integration or other cool things, a static host won't suffice.

nicola commented 10 years ago

Agreed

On Jul 24, 2014, at 4:13 PM, Federico Rampazzo notifications@github.com wrote:

AFAIK the github CNAME file does not allow wildcards (I tried to set that up last year and it didn't work). Without the CNAME, even if we're able to point our subdomains to github we won't be able to make github understand it should serve this repository.

Btw, I don't see that as a problem. If we want to support jawbone integration or other cool things, a static host won't suffice.

— Reply to this email directly or view it on GitHub.

framp commented 10 years ago

The coolest thing ever would be using something like js-github to create a repo for each of our users when they register.

In this way we could simply point *.isawake.me to github and then rely on github pages to do the rest. Every repo should host the website on its gh-pages branch and link to remote .js and .css file on the main repo to let us upgrade JS and CSS whenever we want.

The only thing which I'm not sure about is if we will be able to use the github API using JS only - but that guy managed to do it (and so can we)

nicola commented 10 years ago

oh man, that's very complex. What I would do is that they automagically for the repo, send the pull request with their new nickname.json.

mtt87 commented 10 years ago

It looks overkill to me and is adding another layer to develop, maintain and debug.

KISS please :smile:

nicola commented 10 years ago

@mtt87 my wait is quite straight forward if they log in through github.

framp commented 10 years ago

Not really, they stil have to create a file and send a pull request (and we would need to approve it). So either we implement github api or they'll have to learn git (and then wait).

Plus, my way has the added advantage of making isawake entirely hostable on github pages!

nicola commented 10 years ago

I think we are on different pages. In my way, they just have to accept oauth, fullstop, we will fork for them, and pull request for them. They basically just authenticate.

mtt87 commented 10 years ago

@framp Generally speaking I like the idea of MVP and all this sound a bit overkill/overengineering to me.

I don't think we will receive thousands of request :smile:

Anyway feel free to build it, it's an open project :smile:

framp commented 10 years ago

If we still have to fork for them and pull request for them client-side, the extra effort required to clone a repo and commit some changes is pretty low :) I'll show you a proof of concept as soon as I have time