nodejs loopback could be the inspiration for a new golang framework

<p>Hi, this is not a criticize for the golang community, but everyday I see a new go framework, which is just a small change with the other 300 go existing framework and mostly them are inspired by sinatra/express</p> <p>Recently I found nodejs loopback and I think than it&#39;s great, seems like Rails for this decade (for api creations) and a big step further over express</p> <p>what I like about this framework is how use the command line, you define your model (and types) using the command line, then this create a functional CRUD and you can test your api with swagger, so it generates the whole documentation, it&#39;s a 1-2-3 punch combination</p> <p>it&#39;s a step further over the goa framework because it requires less boilerplate (I think than it&#39;s more friendly the cli to define the model over define the whole api using plain go) .</p> <p>also I found great how it handles authentication and authorization, pretty simple and sweet</p> <p>again, I&#39;m not criticizing the go frameworks but I think than loopback is a step further and would be the next rails in the future, would be great have something like this for go, what do you think about it???...</p> <hr/>**评论：**<br/><br/>8bitcow: <pre><p><a href="https://loopback.io/" rel="nofollow">loopback.io</a></p></pre>shuwatto: <pre><p>So maybe we don&#39;t really need web frameworks in go in the first place?</p></pre>hockeyhippie: <pre><p>Continually running into limitations of loopback is what got me writing APIs in Go in the first place. :)</p></pre>PacNinja: <pre><p>What kinda limitations?</p></pre>dontloopback: <pre><p>I have been there and done that</p> <p>We decided to write 2 new projects with loopback months ago. </p> <p>After we spent 3-4 days around the docs and tutorial by running things and trying out some features, we started to write 2 services per project to see how it&#39;s going. </p> <p>Then we realized one damn thing. Even you generate REST API and change json configs etc. It is not enough for writing your business logic. </p> <p>We thought it will be enough if we change json configs by adding some default embeded fields, filters etc.</p> <p>Then only way left is writing handlers yourself for most routes it provides. This is where we left loopback and moved golang and what it provides. </p> <p>If your APIs data doesn&#39;t need more than short and simple CRUD db queries and one-to-one mapping to REST endpoints, then go for it. </p> <p>Loopback can handle simple business logic where decades ago you may write with 2-tier archs. I was there and it was a lot of mess.</p> <p>For other cases where you need to have API paths return filtered, processed results depending on the user and users relation with other users dynamically, say a timeline., then please consider something else.</p> <p>Maybe loopback + adding more middlewares for business logic + use default ones if developer doesn&#39;t override them</p> <p>I wrote that long because we lost around 2 weeks for 4 developer time on that</p></pre>nilslice: <pre><p>Check out <a href="https://ponzu-cms.org" rel="nofollow">Ponzu</a> - it has some of what you&#39;re looking for from loopback e.g. CLI generators etc and an API. But, it&#39;s a bit more tuned for CMS-style systems, although you can mold it to do a lot. </p> <p>Ps - it&#39;s my project, so excuse the shameless plug! I think it might be useful for you though. Anyway, if you have any questions about it feel free to ask. </p></pre>cesarliws: <pre><p>I don&#39;t know loopback, but the command line tools seems like Artisan command-line interface included with Laravel.</p></pre>