SideNote:AS much as I like the REST (and all the derivates,wisdom and schools of thoughts) I've recently switched over to "JSON-RPC-Like" mechanism for most of my personal projects. The "-LIke part" is cause I'm omitting some of the stuff like "id" in the call. It boils down to me spending less time trying todo "REST The Right Way".. JSON-RPC just let me get on with it...
Go/Gin is indeed a very good stack for building REST APIs, thanks for sharing!
If someone is interested to compare, I recently wrote a sample React app with a similar server stack: Go/Gin plus gorm (and SQLite, but easy to change): https://github.com/wallix/notes
Personally I find Vue simpler. The conceptual model is simple, and the "syntax" is intuitive and easy to remember. Vue Router and the Vuex state management library are developed together the main Vue library, and as a consequence they feel part of a cohesive whole.
In the end for me using Vue is a more pleasant experience (but I'm not a frontend developer, and obviously YMMV).
I've done a project with the same stack, and our approach ended up being almost exactly the same (I used mod for go dependencies and yarn for vue). One thing I don't really like about it is having the compiled front end site checked in as public in the repo.
I was hoping to find a way for heroku to detect the subproject in the client directory, build it and deploy it as part of the heroku push. I've tried numerous approaches, and all failed for one reason or another. Did you experience the same? Does anyone else have suggestions as to how to make something like that work?
as that is pretty much my day job, i'll chime in with my 2 cents.
building on the deploying server is, of course, an option. It should however be avoided, as you can never be 100% certain that everything is exactly as the code you originally tested against.
that is why software repositories exists... and why github created a releases api [0]. and there are readily available scripts to use this as well [1] (i'm not affiliated in any way, just found that from a quick google). but you'll probably find something for your build tool of choice as well. that is often more stable
but to answer your initial question: yes, that should be possible as well. if everything else fails, you're always able to replace the normal binary start with a shell script which does everything you want and finally start the server process. That is admittedly a hack and another solution is probably preferable, but it's a fallback that always works.
Unsure if this is the right place to ask, but given this is go example project and as being someone new to Golang - I'm looking for advice in couple of topics:
* database migrations - Does it make sense to have a library take care of this for me? Is there a battle tested library?
* orm? does it really affect performance that much? is there a favorite?
It really depends on your project requirements. Most projects have relatively simple requirements for migrations and SQL generation and can easily find tooling in both Golang and other languages by doing a simple Google search.
Similarly for performance you need to assess the needs of your application, prototype, and benchmark to identify bottlenecks. Most people I see asking for performance tips never actually complete enough of the project to experience the performance implications they are so worried about.
To summarize Go has never failed me in a web-oriented project (usually in the context of a REST API). Don't get me wrong, it has plenty of warts. Often you'll feel like you are writing lots of boiler plate. You won't get the advantages (and disadvantages) of "move fast and break things" ecosystems like Node or Rails. I've never regretted choosing Go.
PS: its a more advanced topic but code generation + Golang is transcendant if you find yourself writing lots of boilerplate. Huge boost to productivity when applied correctly.
Just digging into first Golang application (existing, no structure, everything in one folder except templates and static css etc., no front end JS library). No migrations. Had the exact same question.
Thinking Vue for front end also. Very timely main post because have been wondering best way to lay structure on the project. Simple is good and sure don't mind getting away from big framework bureaucracy, but 100 files in a folder can't be the way to go.
Nice work! It's always good to see minimal applications that string different stacks together without going overboard with dependencies.
Suggestion to the developer: Remove the "Calculate" buttons and update mean(), std() and cdf() after clicking "Generate". Repeatedly clicking Statistic's "Calculate" and getting different results (without updating the random numbers) is slightly confusing.
This is my favourite stack :) built webhookrelay.com with Go (although not Gin, just negroni mux) + vue + vuetify fpr material components. Working on both backend and frontend is a joy and I feel super productive.
The main thing with vue is getting project structure right, try grouping per pages and you will be fine!
How would one add Authentication / Database support?
You obviously have the router for the front-end, but with Echo, how would one add authentication support, or should I just look at a different stack such as Django or Ruby on Rails with multiple auth / ORM middleware and use Go as a back-end?
You can easily add authentication to Go via JWT [0]. You can also write middlewares in Go[1] ranging from auth to gzip or anything else you can think of.
Notes which I mentioned in another comment uses JWT https://github.com/wallix/notes and features a minimal auth/login API and client. Just a bit of warning: Passwords are not securely stored (in cleartext) on purpose, since the goal is to then use our (open source) SDK to encrypt passwords and other data.
The downvotes on this are disappointing. This may not be the way to build an application, but the question itself is reasonable and in good faith. I'd like to see fewer downvotes and more helpful explanations why only one backend is necessary.
It is also mostly unnoticeable then too. The slower parts of your service will crowd out httorouter most likely. I'm a bigger fan of stdlib compatible routers.
We have an in-house schema migration utility. Due to the nature of our stack (mostly for historical/legacy reasons), we have multiple languages that can reach in and read different tables. We don't have code-generation ala RoR and a single service that we can update at the same time. We have many, many read slaves and a master DB that we update first in a backwards compatible manner, then update software to work with the new hotness. Disjointed by design. The migration tooling and its stack is orthogonal to our languages we use to write software.
PS. VueJS + GO great stack :)