Comments (13)
Angular seems a bit heavy for an app like this. React would be choice for KISS it.
from congo.
I don't know my angular from a hole in the wall, so wide open to all suggestions. First contributor with working PR wins? :)
from congo.
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.
from congo.
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?
from congo.
I can say that when it comes to knocking out a web app, I miss early Rails. Not today's rails, but early rails.
from congo.
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 [email protected]
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
#4 (comment).
from congo.
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!
from congo.
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
from congo.
Yup, souds good, been following go-kit since inception too and that "scaling out" strategy seems to be the way forward.
from congo.
beautiful. Sounds like a good plan to me.
On May 25, 2015, at 10:15 PM, Eric Duncan [email protected] 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 #4)
app.congo.com -> static, hosted on cdn, built with React, talks with api for authAttendee 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 #4 (comment).
from congo.
👍 Haven't worked with React yet, but am excited to. Sounds like it's solid and quite popular.
from congo.
@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
from congo.
@kiasaki we need a bit of infrastructure before we can get moving further on the front end, it's in the works!
from congo.
Related Issues (15)
- Create Data Models For initial entities HOT 19
- Create basic REST framework HOT 32
- Organize weekly hangout / Other communication tools HOT 1
- Investigate using GoKit for everything we possibly can HOT 3
- CLA? Ownership of Code? HOT 2
- Inspiration HOT 2
- Community HOT 8
- Much better documentation about what we're building and why HOT 10
- Role based access control HOT 3
- Create list of Current GopherCon services to examine possible integration points HOT 3
- CI HOT 1
- Embed Caddy & pieces of hugo?
- add task for generating RSA keys HOT 3
- Package description should be updated to refer to this project. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from congo.