6 ms·

A little not so related question, what is/are the most used stack for web applications in Go? How common if at all would be a Go backend & React for instance fr

by tempw 10y ago

A little not so related question, what is/are the most used stack for web applications in Go? How common if at all would be a Go backend & React for instance frontend stack?

jagger27 10y ago
That's the beauty of Go. The "most used" stack is just net/http in the standard library. Other toolkits implement and extend its interfaces and work together quite well for the most part. Your choice of front end framework is really a matter of taste.
- tempw 10y ago
  Cool, thank you for the insight!
oelmekki 10y ago
I can't tell about "how common", but a react web client with a go backend API is exactly what I do on my main product, currently. It still has a few problems I haven't managed to solve, though (but not related directly to go). For example, given the visible routing is handled by react-router, I haven't find a way yet to issue proper 404 status (I have a catchall route that renders web client page, then client router displays a "not found" page, but it will be a 200 status). Not that a big deal, because the web client is an application behind auth, and not some public facing pages.
- artursapek 10y ago
  I suggest you adopt a 3rd party router, rather than using pure Go standard library for this. https://github.com/julienschmidt/httprouter https://github.com/julienschmidt/httprouter is the most popular one. It supports a custom 404 handler https://github.com/julienschmidt/httprouter/blob/master/router.go#L147 https://github.com/julienschmidt/httprouter/blob/master/rout...
  - oelmekki 10y ago
    Actually, go routing is not the problem, it's react routing that is : go router only knows about API endpoints, and have a catch all route to serve the web client, which then manage its routing by itself. The advantage in that is that the backend only needs to know about API routes, and the client is totally free to implement whatever routes it wants.
- matt4077 10y ago
  The code that does this for server-rendered js is in https://github.com/ReactTraining/react-router/blob/master/modules/match.js https://github.com/ReactTraining/react-router/blob/master/mo.... There's code to convert URL patterns to regular expressions in https://github.com/ReactTraining/react-router/blob/master/modules/PatternUtils.js https://github.com/ReactTraining/react-router/blob/master/mo..., although that seems to work only for a single pattern and not all. Presumably you should find a way to convert all patterns to a single regex somewhere in the codebase and could use that to check the request in go.
  - oelmekki 10y ago
    Hmmm, indeed. I didn't thought about using react server side rendering and intercepting it to check which status to provide. Good idea, thanks! No, I'll have to think about whether it's worth it adding a whole SSR stack just for that, in my app behind auth :)
- hellcow 10y ago
  Another great 3rd party router is Chi. https://github.com/pressly/chi https://github.com/pressly/chi My company uses httprouter, but if Chi had been available when we started, we'd have used that instead. It follows Go's standard library API (httprouter diverges a little bit with its params) and adds support for Go's Context (which httprouter currently lacks).
  - AsyncAwait 10y ago
    I've been using gorilla's mux, precisely because it follows the stdlib API, will certainly have a look at Chi, thanks for the link.
- tempw 10y ago
  A priory it seemed really ideal to use Go and React so that's good to know. That issue is something I'd hardly find out to happen if just looking up online, thanks for sharing.
  - oelmekki 10y ago
    Note that it's not really about using go, but more about implementing routing on client side : you lose http status for non api urls, whatever the backend language is. But then again, when you have static pages for public facing (and indexed) pages, and you have proper http status for api requests, having or not http status on web client urls is not that a big deal, so that's probably why it's not often mentioned. The only problem it could cause is if someone makes a deep link to somewhere in your app, it will return a 200 status and will be indexed by bots, probably indexing login form for just any url, so that's the annoying point (huge trolling possibilities, btw, there :) ).
    - tempw 10y ago
      Indeed there is this caveat and its exploitation possibilities. I appreciate the thorough insight, thanks for taking the time!
wvh 10y ago
I can't help you with statistics, but it doesn't seem strange to me. I tend to start with (pure) Go for web services. If the frontend gets bothersome, I use something relatively lightweight, like Vue. If the backend gets a bit unwieldy, I add something minimal there, like Alice, httprouter/httptreemux or Chi. There's a lot of options on both ends, but I like to start small until I notice I'd have to start implementing whole stacks, at which point I might add a library close to what I had in mind myself. I work mostly on lower-level projects and services though. I don't know about the most used stack, there are many ways to go depending on what you want to do, but I think the kitchensink approach of gigantic frameworks isn't commonly associated with Go, and I don't think Go really has one go-to stack like say Ruby on Rails. That does mean you'd have to be somewhat familiar with both Go and its community projects to make a decision.

by tempw 10y ago

A little not so related question, what is/are the most used stack for web applications in Go? How common if at all would be a Go backend & React for instance frontend stack?

jagger27 10y ago

That's the beauty of Go. The "most used" stack is just net/http in the standard library. Other toolkits implement and extend its interfaces and work together quite well for the most part. Your choice of front end framework is really a matter of taste.

tempw 10y ago
Cool, thank you for the insight!

oelmekki 10y ago

I can't tell about "how common", but a react web client with a go backend API is exactly what I do on my main product, currently. It still has a few problems I haven't managed to solve, though (but not related directly to go). For example, given the visible routing is handled by react-router, I haven't find a way yet to issue proper 404 status (I have a catchall route that renders web client page, then client router displays a "not found" page, but it will be a 200 status). Not that a big deal, because the web client is an application behind auth, and not some public facing pages.

artursapek 10y ago
I suggest you adopt a 3rd party router, rather than using pure Go standard library for this. https://github.com/julienschmidt/httprouter https://github.com/julienschmidt/httprouter is the most popular one. It supports a custom 404 handler https://github.com/julienschmidt/httprouter/blob/master/router.go#L147 https://github.com/julienschmidt/httprouter/blob/master/rout...
- oelmekki 10y ago
  Actually, go routing is not the problem, it's react routing that is : go router only knows about API endpoints, and have a catch all route to serve the web client, which then manage its routing by itself. The advantage in that is that the backend only needs to know about API routes, and the client is totally free to implement whatever routes it wants.
matt4077 10y ago
The code that does this for server-rendered js is in https://github.com/ReactTraining/react-router/blob/master/modules/match.js https://github.com/ReactTraining/react-router/blob/master/mo.... There's code to convert URL patterns to regular expressions in https://github.com/ReactTraining/react-router/blob/master/modules/PatternUtils.js https://github.com/ReactTraining/react-router/blob/master/mo..., although that seems to work only for a single pattern and not all. Presumably you should find a way to convert all patterns to a single regex somewhere in the codebase and could use that to check the request in go.
- oelmekki 10y ago
  Hmmm, indeed. I didn't thought about using react server side rendering and intercepting it to check which status to provide. Good idea, thanks! No, I'll have to think about whether it's worth it adding a whole SSR stack just for that, in my app behind auth :)
hellcow 10y ago
Another great 3rd party router is Chi. https://github.com/pressly/chi https://github.com/pressly/chi My company uses httprouter, but if Chi had been available when we started, we'd have used that instead. It follows Go's standard library API (httprouter diverges a little bit with its params) and adds support for Go's Context (which httprouter currently lacks).
- AsyncAwait 10y ago
  I've been using gorilla's mux, precisely because it follows the stdlib API, will certainly have a look at Chi, thanks for the link.
tempw 10y ago
A priory it seemed really ideal to use Go and React so that's good to know. That issue is something I'd hardly find out to happen if just looking up online, thanks for sharing.
- oelmekki 10y ago
  Note that it's not really about using go, but more about implementing routing on client side : you lose http status for non api urls, whatever the backend language is. But then again, when you have static pages for public facing (and indexed) pages, and you have proper http status for api requests, having or not http status on web client urls is not that a big deal, so that's probably why it's not often mentioned. The only problem it could cause is if someone makes a deep link to somewhere in your app, it will return a 200 status and will be indexed by bots, probably indexing login form for just any url, so that's the annoying point (huge trolling possibilities, btw, there :) ).
  - tempw 10y ago
    Indeed there is this caveat and its exploitation possibilities. I appreciate the thorough insight, thanks for taking the time!

wvh 10y ago

I can't help you with statistics, but it doesn't seem strange to me. I tend to start with (pure) Go for web services. If the frontend gets bothersome, I use something relatively lightweight, like Vue. If the backend gets a bit unwieldy, I add something minimal there, like Alice, httprouter/httptreemux or Chi. There's a lot of options on both ends, but I like to start small until I notice I'd have to start implementing whole stacks, at which point I might add a library close to what I had in mind myself. I work mostly on lower-level projects and services though. I don't know about the most used stack, there are many ways to go depending on what you want to do, but I think the kitchensink approach of gigantic frameworks isn't commonly associated with Go, and I don't think Go really has one go-to stack like say Ruby on Rails. That does mean you'd have to be somewhat familiar with both Go and its community projects to make a decision.