<p>Hello there,</p>
<p>I've built two startups using Go as backend in the last three years, and I decided to write a book going over what I think is a good path to having an API-first Go web application for software as a service product.</p>
<p>This is the book l<a href="https://buildsaasappingo.com/">anding page</a>, but I'm interested in getting feedback regarding the table of content:</p>
<ol>
<li>Let's Go: Create a simple web application to get started with Go.<br/></li>
<li>Tests are important: Balance speed of development and importance of tests.</li>
<li>A 50 lines web framework: We craft ourselves a tiny foundation with no dependencies. </li>
<li>The data package: MongoDB because we're creating a SaaS and it's evolving each day.</li>
<li>API-first my friend: Your users want an API, give them on day 1.</li>
<li>Authorization middleware: How users are created and how they can authenticate & authorize requests.</li>
<li>Single page application: Build a lightweight SPA with TypeScript, Preact, Bulma, and webpack.</li>
<li>Billing and subscriptions: We use Stripe to build a full real-world billing system.</li>
<li>Emails & background tasks: Go routines in all their glory, no need for external processes.</li>
<li>Capture and replay: Log failed requests and run them against your dev environment.</li>
<li>Zapier integration: No matter what you'll build, Zapier will be there.</li>
<li>Automated deployment: We build our own CI in Bash and Go (for real).</li>
</ol>
<p>Would you say that I'm missing something here? Any suggestions would be highly appreciated.</p>
<p>I'm not sure about chapter 7 where mixing UI within a Go book could be too much. Also, one chapter to go over a basic UI could be too short. But the reader would have a backend API at the end of the book otherwise...</p>
<p>My humble goal with this book is to demonstrate that Go is a solid choice for building a SaaS products and maybe try to get some RoR and Python devs to discover a new stack. If nothing more than pique their curiosity, that would still be a win I think.</p>
<p>Thank you.</p>
<hr/>**评论：**<br/><br/>733138: <pre><p>Looks very nice. Except for MongoDB.
If I were you, I would write 2 books: this one without chapter 7 & replacing mongo with anything else (sqlite maybe?), and another one just front-end oriented (this one including ch. 7). Just my 2 cents.</p>
<p>Either way, keep it up! </p></pre>dstpierre: <pre><p>It is funny because I'm aligned with what you've said and had considered it at first, but removing the entire chapter felt incomplete.</p>
<p>What's up with MongoDB and the Go community :)? But I hear you, so far it is a recurring feeling. I'm using MongoDB at Roadmap and must say that so far it is not bad for this use case.</p>
<p>Thank you for the feedback.</p></pre>neoasterisk: <pre><blockquote>
<p>What's up with MongoDB and the Go community :)?</p>
</blockquote>
<p>I don't think it has to do with the Go community in particular. In fact I know many gophers who love Mongo especially since we've had a very good driver for a long time now. I think it's actually more of a <a href="http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/">general issue</a>.</p></pre>joper90: <pre><p>But when you google for 'not using mongo' all the articles pretty much point back to that one..?</p></pre>neoasterisk: <pre><blockquote>
<p>But when you google for 'not using mongo' all the articles pretty much point back to that one..?</p>
</blockquote>
<p>Maybe they do, maybe not. What's your point? </p>
<p>Really just think for yourself. Is MongoDB a good fit for your project? if it is then use it. But here we have an author that is writing a book and is asking for feedback. MongoDB can only be used for very, very, very specific data models and situations. As far as I am concerned it's a very bad fit for a learning book.</p></pre>coder543: <pre><p>There are countless articles that explain why you should never, under any circumstances, use MongoDB. The golang community is understating this, if anything, compared to most communities. Use anything and everything else before turning to Mongo. Unless you enjoy losing data, or being unable to do basic things without destroying performance.</p>
<p>Just because you haven't had it blow up in your face <em>yet</em> doesn't mean it's a good idea. Some people get lucky while walking through a minefield, but that luck runs out sooner or later.</p></pre>joper90: <pre><p>But most of the countless articles seem to point back to that one article. </p></pre>coder543: <pre><p>"that one article"</p>
<p>When writing an article like these, it's usually standard practice to link to other corroborating sources. They're not all summarizing a single article. There are a number of unique experience reports and interactions with the MongoDB team which have been written up, and naturally those will link to articles in the same vein.</p></pre>arp242: <pre><p>MongoDB :-(</p></pre>dstpierre: <pre><p>haha yeah, this is generally the response, hmm. I don't want to get too verbose in the "data access" package. But I might use a RDBMS.</p>
<p>Thanks for your feedback :)</p></pre>drink_with_me_to_day: <pre><p>Does it even make sense to use mongodb with Go, wouldn't it become some interface{} hell?</p></pre>natefinch: <pre><p>I worked with mongodb for 3.5 years on Juju. It's not interface{}. It's basically like JSON serialization.... structs in and structs out. </p>
<p>It lowers the barrier of entry, but in my experience, most people that use it really should just use a relational database like postgres, because the lack of relational functionality really hurts the long term stability and velocity of a project. Most projects store highly structured data (see the part about "structs" above)... that's what relational databases are for.</p></pre>arp242: <pre><p>It certainly wouldn't make too much sense conceptually, IMHO. Go is all about safety and being "boring". MongoDB is the exact opposite.</p></pre>coder543: <pre><p>MongoDB, for when you want an <em>exciting</em> database. Maybe you've been sleeping too well at night... well, sleep no more! Introducing Mongo!</p></pre>dstpierre: <pre><p>You still have struct to define your data, this is an example of production code I have `similar.</p>
<pre><code>var account Accounts
where := bson.M{fieldEmail: email}
if err := db.C(collectionAccounts).Find(where).One(&account); err != nil {
}
</code></pre>
<p>I'm thinking of having the data package targeting sqlite and Mongo maybe that could be an idea to have a straight comparison for the reader of the book. Not sure yet.</p></pre>scottjbarr: <pre><p>Maybe use a "Repository" interface and put the data details behind that? You can discuss the pro's and con's of each datastore specifically, without it influencing the whole book as the "business logic" works with the interface.</p></pre>puffybunion: <pre><p>This looks great. If it doesn't take anything from the rest of the book, I don't think it's a bad idea to have the UI chapter as well.</p>
<p>Would love to get my hands on this when it gets published!</p></pre>dstpierre: <pre><p>Thank you. That's the issue with the UI chapter, I feel it is going to be huge, so I either will do a quick one or not at all.</p>
<p>You can keep in the loop via my <a href="https://twitter.com/dominicstpierre" rel="nofollow">Twitter account</a></p></pre>musale13: <pre><p>Code optimization techniques? Go tracer... etc I am usually interested in such kind of tools. </p></pre>dstpierre: <pre><p>Yes thanks for the suggestion, that could be a good one to replace the UI chapter.</p></pre>NSABeaver: <pre><p>When is the target release date of the book ?</p></pre>dstpierre: <pre><p>I'm sorry, I don't have an ETA at the moment. Ideally sooner than later. I will have a more valid ETA in the following week.</p></pre>absdevops: <pre><p>Might be a little unrelated to projects, but something like advanced manipulation of structs would be cool</p></pre>Neorift: <pre><p>What kinds of struct operations fall into that category?</p></pre>absdevops: <pre><p>So a while back on here I was helped with <a href="https://gist.github.com/arehmandev/87a63bf5964ce4a8833294fb831c6373" rel="nofollow">this json transformation</a> - it would be nice to see more solutions to real world tiny issues like this</p></pre>peartreeer: <pre><p>Love the sections (except I'd also throw my hat in to say use a relational database). Only thing I'd like to know more about, which would be filtered throughout the book is best debugging tips and tricks you may have. Go's pretty awesome about tracing but if you've come across any particular helpful tricks that's always nice for the reader.</p>
<p>Looking forward to it's release!</p></pre>dstpierre: <pre><p>Thank you that's a good suggestion, it could be a good chapter replacing the UI one if I remove that one.</p></pre>dstroot: <pre><p>Some thoughts:
1) I echo the Mongo DB comments - use Postgres
2) SPA's are a little unique and I don't see how Go fits except to serve the assets. I'd use Vue or React and also GraphQL if I was starting from scratch today for an SPA.
3) If I was starting today I would have full tracing throughout my apps. Check out the HotRod example in Jaeger!
4) Auth is a minefield, if you can do it justice it would be very beneficial. Users auth with ID/Pswd, or OAuth (use FB and Google) and app uses JWT(?). I like JWT but refreshing them is awkward and canceling them is hard.</p>
<p>Orthogonal: I am a "mini-angel" investor. Did your startups succeed? If so, why? If not, why not? </p>
<p>Cheers,
Dan</p></pre>dstpierre: <pre><p>Thanks for the suggestions, point 3 and 4 are very important. I was planning on having Slack as an OAuth source and JWT for authenticating requests.</p>
<p>re: startups succeed. I left LeadFuze after almost 2 years when the product was fully built I'd say, we were doing good. I started Roadmap after leaving LeadFuze. We've had a pretty strong starts, some roller-coaster startup-like adventure. Now it is just me at the moment, we were 4 after I launched the MVP.</p></pre>matiasbaruch: <pre><p>It might be interesting to include a section about Redis (or similar software).</p></pre>dstpierre: <pre><p>Yes absolutely, I think if I decide to remove the UI chapter that will leave some room for caching and other techniques, good point thanks :)</p></pre>NilByDefault: <pre><p>Great stuff, I'll be your reader! One question, do you use Docker anywhere in your process? For example, building SPA must require lots of dependencies, which I would bundle in a docker image. The same applies to Mongo, spinning up MongoDB within a container seems a way easier to me. Unless, your custom built CI does the same))</p></pre>dstpierre: <pre><p>Thank you, that is so re-comforting to hear :). I wasn't planning on using Docker, but maybe that could be easier to get started. The CI is more a CD in fact, looks like I did a typo there, It is a small Go app that automates the deployment of the app from a GitHub branch with multiple app environment bound to specific GitHub branch like master=production, staging, dev. </p></pre>
