Re: [go-nuts] How to increase concurrent users in net/http
Would you mind also posting the network tuning parameters you're using along with the os? I know that when I do perf testing for go on linux, I typically need to update a number of tcp related kernel parameters before I get meaningful numbers. M -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] performance optimization
Can you describe what task it is that needs to be updated every microsecond? It seems like there should be a better to resolve the underlying need. M -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Inheritance and OOP: Go one better
I’m not sure how an interface doesn’t satisfy what you’re looking for. Can you describe your use case in a little more detail? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Customized Go template FuncMap example
Given that text and html templates are separate calls anyways, why not just
make separate calls for your custom funcmap? For example:
package template
import (
html "html/template"
text "text/template"
)
func Html(name string, fm html.FuncMap) *html.Template {
return html.New(name).Funcs(fm)
}
func Text(name string, fm text.FuncMap) *text.Template {
return text.New(name).Funcs(fm)
}
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] [ANN] nats-proxy - http in the front; NATS in the back, microservice library for NATS
https://github.com/savaki/nats-proxy
http in the front; NATS in the back
nats-proxy provides an HTTP gateway that simplifies service discovery by
using NATS as the transport layer between services.
client --[http]--> gateway --[nats]--> service
*Start the API Gateway*
// Start the Gateway
nc, _ := nats.Connect(nats.DefaultURL)
gw, _ := nats_proxy.Wrap(h, nats_proxy.WithNats(nc))
http.ListenAndServe(":8080", gw)
*Start the Service*
// Start the Service
h := http.HandlerFunc(func(w http.ResponseWriter, req *http.Request) {
io.WriteString(w, "hello world")
})
nc, _ := nats.Connect(nats.DefaultURL)
r, _ := nats_proxy.Wrap(h,
nats_proxy.WithNats(nc),
)
r.Subscribe(context.Background())
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: go-swagger dynamic API creation
Before writing github.com/savaki/swag, I gave goswagger a try. I think
goswagger is a fantastic library with lots of useful features. However,
for my own use, I found things like:
var findTodos = runtime.OperationHandlerFunc(func(params interface{})
(interface{}, error) {
log.Println("received 'findTodos'")
log.Printf("%#v\n", params)
return items, nil})
a little cumbersome. I also wanted to be able to use automatic code reload
tools like https://github.com/codegangsta/gin and code generation made that
a little more problematic.
Hence was born:
https://github.com/savaki/swag
M
On Monday, March 27, 2017 at 11:39:48 AM UTC-7, Johann Höchtl wrote:
>
> The last time I used it swagger was called swagger.
>
> Lots has changed since it's OpenAPI. A huge framework evolved around it
> https://goswagger.io/
>
> I really like the approach of defining the API entirely dynamically in
> code (and announcements like
> https://groups.google.com/forum/#!topic/golang-nuts/3ebgsgF6W2c, nice!) .
> Unless I misunderstand goswagger.io, nothing prevents the drifting apart
> of the generated code from the YML - api spec.
>
> There is also an example to dynamically generate the swagger spec using
> goswagger.io
> https://goswagger.io/tutorial/dynamic.html
> and I wonder if there is experience using that. Especially is it in
> feature parity with the go generate approach of goswagger.io?
>
> Thank you!
>
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Project architecture
If you're just starting out the project, by all means start with the monolith where everything is together. If you decide it's necessary, over time you can split out the project into what you've discovered you need. Trying to abstract the components you think you'll need too early is a good recipe for heartache. M On Saturday, March 11, 2017 at 9:00:43 PM UTC-8, James Pettyjohn wrote: > > I'm looking at the pros and cons of how to architect a web project. > > 1) One is a single go project for a site. No service dependencies for the > backend at all. Certain aspects of this means a cgo dependency which is not > ideal as it complicates containerization and slows build time. One plus to > this is the simplicity in development - the entire project is self > sufficient and tests are easily checking everything - thought compilation > and startup suffer. > > 2) Another means would be to split out portions of the project. This adds > dev complexity as it requires more services to enable parts of the server, > or run at all. Coordination of service versions becomes an issue. But the > services, now being centrally located, can be deployed and result in > updates to all services using it. I think from the ops perspective this > could be more efficient as you don't inherit the overhead in all projects. > > > Opinions on the above? Another approach entirely? > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Do Go Routines use continuations to allow yelding?
Goroutines are conceptually very similar to threads, but much lighter weight. They are far cheaper than system threads to run. It's not uncommon for go apps to have 50k or more goroutines running. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: A proposal for generic in go
I think I have to agree with most of the posters here about generics. In theory, I miss them. However, in practice, I find that there are usually only a few times during the course of a project where I wish I had generics. And then after writing a few lines of code to do what the generic would have done, I find I stop missing them. M -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
