Consumer/Producers (front end applications)

[bketelsen]

Decide on preferred technologies for front-end apps - which would include:

• Conference admin app
• Conference public website / CFP app
• Others?

Angular, React, Go web apps all options.

[eduncan911]

Angular seems a bit heavy for an app like this. React would be choice for KISS it.

[bketelsen]

I don't know my angular from a hole in the wall, so wide open to all suggestions. First contributor with working PR wins? :)

[eduncan911]

Are we wanting to create a go web application?

Or, using something like NodeJS to serve the React single page app? (No logic in nodejs, just serves the static React site, and forwards/filters requests to the Go api back end)

First option is nice to jeep it all in go, but requires a lot of http finese (compression/gzip, routing, security, etc).

Second option is to use a dumb nodejs web app to serve the static pages, and to forward requests to the go web api back end. This has the advantage sepeating the frontend from the back end development as well, with front end gurus free to just run node with all their fancy frontend tools in a stand alone environment.

[bketelsen]

it's a delicate issue. I want to say publicly that you can use Go to build a full-stack app. But I think that it is easier, more productive to do front-end work in Javascript. I don't know because I haven't done the JS side of it. I have written full web apps in Go. single binary, single repo, one stop shop would be easier for deployment. But is it better? It isn't as flexible as an API that doesn't care how the pages are served. Maybe that's our starting point. API. We'll worry about consuming it later?

[bketelsen]

I can say that when it comes to knocking out a web app, I miss early Rails. Not today's rails, but early rails.

[eduncan911]

Very true. Lots of opinions either way, and I myself have done full stack Go in a single binary.

Yes, API first... An API that can be consumed by multiple consumers (web app, mobile apps, website widgets via JS, etc).

Which, if using Gorilla mux (as I mentioned in another issue), you can sub-route them separately and keep it all in Go anyways.

/api/v1/ -> routes to apirouter.go / -> rroutes to webrouter.go

And you can keep them separate, Even separate namespaces if you wish.

On Sat, May 23, 2015 at 1:21 PM, Brian Ketelsen notifications@github.com wrote:

I can say that when it comes to knocking out a web app, I miss early Rails. Not today's rails, but early rails.

— Reply to this email directly or view it on GitHub https://github.com/gopheracademy/congo/issues/4#issuecomment-104927772.

[kiasaki]

I've been doing more and more frontend recently and I must say that I am all for an API first approach with a dumb static frontend for the admin and the website.

React has some really nice properties for prototyping fast as well as keeping that code and making it grow in a full-fledged production app. You need the help of a good build system 'tho, Gulp or Grunt and Webpack or Browserify do a great job at this.

The "marketing" website could even be done with hugo.

You'd end up with something similar to:

congo.com -> static, hosted on cdn, built with (plain go | hugo | middleman)
api.congo.com -> Go based API (see PR #4)
app.congo.com -> static, hosted on cdn, built with React, talks with api for auth and interactions

I would be glad to help set this up and get cracking on some frontend work!

[eduncan911]

Exactly my thoughts. And it fits with the go-kit/microservices approach to scale out later that I am working on:

Launch:

congo.com -> static, hosted on cdn, built with (plain go | hugo | middleman)
api.congo.com -> Go based API (see PR #4)
app.congo.com -> static, hosted on cdn, built with React, talks with api for auth

Attendee registration gets overloaded, time to scale out the /attendee micro service:

congo.com -> no change, still points to static registration page
api.congo.com -> deploy with /attendee routes redirecting to below /api...
app.congo.com -> deploy with /attendee routes point to below...
attendees.congo.com -> change static routes for /attendees to use this dns, scale over 5x servers

[kiasaki]

Yup, souds good, been following go-kit since inception too and that "scaling out" strategy seems to be the way forward.

[bketelsen]

beautiful. Sounds like a good plan to me.

On May 25, 2015, at 10:15 PM, Eric Duncan notifications@github.com wrote:

Exactly my thoughts. And it fits with the go-kit/microservices approach to scale out later that I am working on:

Launch: congo.com -> static, hosted on cdn, built with (plain go | hugo | middleman) api.congo.com -> Go based API (see PR #4 https://github.com/gopheracademy/congo/issues/4) app.congo.com -> static, hosted on cdn, built with React, talks with api for auth

Attendee registration gets overloaded, time to scale out the /attendee micro service: congo.com -> no change, still points to static registration page api.congo.com -> deploy with /attendee routes redirecting to below... app.congo.com -> deploy with /attendee routes point to below... attendees.congo.com -> change static routes for /attendees to use this dns, scale over 5x servers

— Reply to this email directly or view it on GitHub https://github.com/gopheracademy/congo/issues/4#issuecomment-105360150.

[codeithuman]

:+1: Haven't worked with React yet, but am excited to. Sounds like it's solid and quite popular.

[kiasaki]

@bketelsen How do we get cooking? Is there a start date? Where you waiting for the GopherCon hack day to kick-off?

Maybe it's just me, is there a mailing list to follow or a gitter to be in the know? Found the slack, asked invite, sorry

[bketelsen]

@kiasaki we need a bit of infrastructure before we can get moving further on the front end, it's in the works!