Road to shipping 1.0

[Ilya Grigorik]

Goal: ship 1.0 by end of May (this month), or earlier.

We've been running on 0.9.x for a little over a year now and I think we're well past due for 1.0. There are a number of large production apps that are now powered by Goliath, and the core API's have been stable and performing well. 

With that in mind, there is one complication: in 0.9.4 I merged in router support, and in retrospect have not given it enough thought upfront to guard for all the edge cases that it brought with it. To that end, the majority of the currently open bugs are router related, and thats after we already resolved about a dozen over the past few months. After looking at the remaining bugs, I don't see a clean and elegant solution that would solve these problems, hence I think the best strategy is to take a step back and rethink our approach to routing entirely. 

TL;DR: 1.0 will not have a router, it will be mimic the 0.9.3 API.

I do think that adding a router in v1.0+ is a good goal, but as experience shows it'll require some careful thinking and testing. If you do rely on the router currently, then you can lock yourself to 0.9.4 until we come up with a stable solution. 

ig

P.S. Two steps forward, one step back...

[Eric Marden]

Without the router, how would you be able to map URIs to API Classes? Is there documentation about the 0.9.3 api anywhere?

What ways can we help support you in getting to 1.0?

--
Eric Marden
http://ericmarden.com

On Sunday, May 6, 2012 at 7:39 PM, Ilya Grigorik wrote:

> Goal: ship 1.0 by end of May (this month), or earlier.
>
> We've been running on 0.9.x for a little over a year now and I think we're well past due for 1.0. There are a number of large production apps that are now powered by Goliath, and the core API's have been stable and performing well.
>

> With that in mind, there is one complication: in 0.9.4 I merged in router support, and in retrospect have not given it enough thought upfront to guard for all the edge cases that it brought with it. To that end, the majority of the currently open bugs are router related (https://github.com/postrank-labs/goliath/issues?milestone=1&state=open), and thats after we already resolved about a dozen over the past few months. After looking at the remaining bugs, I don't see a clean and elegant solution that would solve these problems, hence I think the best strategy is to take a step back and rethink our approach to routing entirely.

[dan sinclair]

We left the routing to a higher level. We setup our APIs to be single purpose and then used Nginx or HAProxy to route to the correct API (or round-robin to a set of APIs) as needed.

dan

[Ilya Grigorik]

On Sun, May 6, 2012 at 7:12 PM, dan sinclair <d...@everburning.com> wrote:

We left the routing to a higher level. We setup our APIs to be single purpose and then used Nginx or HAProxy to route to the correct API (or round-robin to a set of APIs) as needed.

dan

On Sun, May 6, 2012 at 6:35 PM, Eric Marden <eric....@gmail.com> wrote:

Without the router, how would you be able to map URIs to API Classes? Is there documentation about the 0.9.3 api anywhere?

What ways can we help support you in getting to 1.0?

The main argument for the router is for code organization + runtime re-use: create separate classes, mount them in a single runtime and let it run. Each class has its own middleware, everyone is isolated, etc. Good times.

In practice, Goliath was designed with a "as close to the metal" API for a reason: we run endpoints which need to handle continuous load for one specific service. Hence, a process is responsible for a single route, and more often than not, we would have multiple goliaths load-balanced behind haproxy for redundancy and failover. We implemented the "routing" at haproxy level, which also allowed us to easily manage and scale out the clusters. 

Example config, with failover and routing for two endpoints / clusters: https://github.com/postrank-labs/goliath/wiki/HAProxy

From experience, when you're running larger services as described above, you *want* the process isolation where each cluster serves a single purpose. As such, we never had a need for an internal router. This is our experience at PostRank, and from what I've seen in terms of adoption from other larger organizations, they ended up replicating the same pattern.

Note: you can build your own poor-mans router right in response(env) method, if you need to.. 

ig

[Andrew Le]

This sounds great, Ilya. What can we do to help?

//A

[Justin Ball]

We're glad to help however we can. Not sure if it is relevant to a 1.0
release but it would be handy to have a place to contribute middleware
so if the community builds something useful it's easy to share/find.
We've built a few things I'd be happy to contribute.

Justin

[Andrew Le]

Maybe a goliath-contrib repo is in order?

//A

[Ilya Grigorik]

On Mon, May 7, 2012 at 1:13 PM, Andrew Le <and...@andrewdle.com> wrote:

Maybe a goliath-contrib repo is in order?

+1 to that. Perhaps as part of 1.0 we can also move some of the middleware
out of core and into contrib. I'd love to keep the core small and focused.

ig

[Karl Freeman]

+1 to a goliath-contrib as I'd love a place to put up some middleware I've been writing. Although the removal of router from Goliath would cause me some issues. Eg I've headed down the path of separating out each endpoint with its own class ( http://cl.ly/GRpJ ) which for the most part has been working out as a great move. Not only for testing but for nice organisation. I can understand that its causing some issues but perhaps instead of just nuking it could we depreciate it?

I can understand the HAProxy path but this change currently means I'm a little stranded. Is there a possible external lib that could 'fit' in where the router was?

Cheers for the hard work with Goliath

Karl.

[Karl Freeman]

Ok, maybe not stranded but locked to 0.9.4.

[Andrew Le]

To Karl's points: would routing work well as a contrib package?

//A

[dan sinclair]

Karl,

The problem is, the router is very inter-twined with the guts of Goliath. It's not really possible to deprecate without it still causing issues.

To that end, if you've already got your application split into separate API endpoints and you've just got a single router at the top level it would be very easy to split apart. Move each of the endpoints to their own file, and move the routing logic from the router to Nginx or HAProxy. It should be a pretty small jump I believe.

dan

[dan sinclair]

Good question and the only answer I have is, I don't know. The current implementation is very much twined with Goliath. It adds hooks into the API class for registering the various get, post, etc endpoints. It adds stuff into the builder and a few other places.

If it could be moved to an external contrib package that would be awesome, but I don't know off hand if it's possible. Sounds like a fun project for someone to pickup, heh.

dan

On Tue, May 8, 2012 at 9:00 AM, Andrew Le <and...@andrewdle.com> wrote:

[Eric Marden]

> To Karl's points: would routing work well as a contrib package?

I think this is a great idea if we can make it happen.

--
Eric Marden
http://ericmarden.com

On Tuesday, May 8, 2012 at 11:00 AM, Andrew Le wrote:

> To Karl's points: would routing work well as a contrib package?
>
> //A
>
> On Tuesday, May 8, 2012 5:55:34 AM UTC-7, Karl Freeman wrote:
> > Ok, maybe not stranded but locked to 0.9.4.
> >
> > On Tuesday, 8 May 2012 13:48:47 UTC+1, Karl Freeman wrote:

> > > +1 to a goliath-contrib as I'd love a place to put up some middleware I've been writing. Although the removal of router from Goliath would cause me some issues. Eg I've headed down the path of separating out each endpoint with its own class ( http://cl.ly/GRpJ ) which for the most part has been working out as a great move. Not only for testing but for nice organisation. I can understand that its causing some issues but perhaps instead of just nuking it (https://github.com/postrank-labs/goliath/pull/179) could we depreciate it?

> > >
> > > I can understand the HAProxy path but this change currently means I'm a little stranded. Is there a possible external lib that could 'fit' in where the router was?
> > >
> > > Cheers for the hard work with Goliath
> > > Karl.
> > >
> > > On Monday, 7 May 2012 21:43:10 UTC+1, Ilya Grigorik wrote:
> > > >
> > > >
> > > > On Mon, May 7, 2012 at 1:13 PM, Andrew Le <and...@andrewdle.com (mailto:and...@andrewdle.com)> wrote:
> > > > > Maybe a goliath-contrib repo is in order?
> > > >
> > > >
> > > > +1 to that. Perhaps as part of 1.0 we can also move some of the middleware
> > > > out of core and into contrib. I'd love to keep the core small and focused.
> > > >
> > > > ig
> > > >
> > > > >
> > > > > On Mon, May 7, 2012 at 1:00 PM, Justin Ball <justi...@gmail.com (mailto:justi...@gmail.com)> wrote:
> > > > > > We're glad to help however we can. Not sure if it is relevant to a 1.0
> > > > > > release but it would be handy to have a place to contribute middleware
> > > > > > so if the community builds something useful it's easy to share/find.
> > > > > > We've built a few things I'd be happy to contribute.
> > > > > >
> > > > > > Justin
> > > > > >
> > > > > > On Mon, May 7, 2012 at 1:56 PM, Andrew Le <and...@andrewdle.com (mailto:and...@andrewdle.com)> wrote:
> > > > > > > This sounds great, Ilya. What can we do to help?
> > > > > > >
> > > > > > > //A
> > > > > > >
> > > > > > > On Sunday, May 6, 2012 7:26:01 PM UTC-7, Ilya Grigorik wrote:
> > > > > > > >
> > > > > > > > On Sun, May 6, 2012 at 7:12 PM, dan sinclair <d...@everburning.com (mailto:d...@everburning.com)> wrote:
> > > > > > > > >
> > > > > > > > > We left the routing to a higher level. We setup our APIs to be single
> > > > > > > > > purpose and then used Nginx or HAProxy to route to the correct API (or
> > > > > > > > > round-robin to a set of APIs) as needed.
> > > > > > > > >
> > > > > > > > > dan
> > > > > > > > >

> > > > > > > > > On Sun, May 6, 2012 at 6:35 PM, Eric Marden <eric....@gmail.com (mailto:eric....@gmail.com)>

> > > > > > > > > On Sun, May 6, 2012 at 6:35 PM, Eric Marden <eric....@gmail.com (mailto:eric....@gmail.com)>

[Ilya Grigorik]

On Tue, May 8, 2012 at 9:10 AM, Eric Marden <eric....@gmail.com> wrote:

> To Karl's points: would routing work well as a contrib package?

I think this is a great idea if we can make it happen.

I think it absolutely can. The grape example in the other thread is already
a good demo.

ig 

[Ilya Grigorik]

Re, other things we could get some help with is JRuby + Goliath: currently looks to be broken (doh). 

A bit more detail here: https://groups.google.com/forum/?fromgroups#!topic/goliath-io/lqZ4FQ4s4nk

ig

[Олег Герман]

Wouldn't you backport bug fixes to 0.9.4 branch?
Cause lack of router is inacceptable to many.

2012/5/7 Ilya Grigorik <igri...@gmail.com>:

[Ilya Grigorik]

On Tuesday, May 15, 2012 7:12:15 AM UTC-7, Duke wrote:

Wouldn't you backport bug fixes to 0.9.4 branch?
Cause lack of router is inacceptable to many.

You can freeze the commit ID just prior to the router drop in your Gemfile. Once again, I do hope we can bring the router back in a post 1.0 branch, but that will take some time to stabilize. In the meantime, 1.0 and 0.9.3 will be effectively the same (modulo router).

ig

[Ilya Grigorik]

Hey all. I think we're almost there with 1.0.. 

Need to resolve or figure out what we're going to do with two outstanding bugs:

- https://github.com/postrank-labs/goliath/pull/180 - should reconcile that before 1.0

- https://github.com/postrank-labs/goliath/issues/167 - this one is tricky.

Do we have any JRuby goliath users? I wouldn't want to ship a broken 1.0 for JRuby, but at the same time all signs point to a bug in EM/JRuby, not in Goliath. =[

Are there any other issues that anyone thinks need to resolved before we ship 1.0?

ig

[Eric Marden]

There is a small one, but its not a show stopper: You can serve OPTIONS requests, but can't test them. I can make time tomorrow night to create a pull request since I already did this for PATCH requests. OPTIONS is used by javascript clients in pre-flight requests when making non-indempodent requests like PUT or DELETE. It would be nice to be able to cover those in tests, at least for completeness.

--
Eric Marden
http://ericmarden.com

[Ilya Grigorik]

On Tuesday, May 22, 2012 11:21:01 PM UTC-7, Eric Marden wrote:

There is a small one, but its not a show stopper: You can serve OPTIONS requests, but can't test them. I can make time tomorrow night to create a pull request since I already did this for PATCH requests. OPTIONS is used by javascript clients in pre-flight requests when making non-indempodent requests like PUT or DELETE. It would be nice to be able to cover those in tests, at least for completeness.

Sounds good - thanks!

Got the JRuby stuff fixed.. https://github.com/postrank-labs/goliath/commit/9b8c74e7a57c0e1caafecc72579493e1d7ed31ba *facepalm*

ig

[Karl Freeman]

Sounds great, thanks for taking the time out. Im doing a CORS implementation so testing out OPTIONS requests will be dead handy.

[Matthias Jakel]

that would be really nice!

[张浩翔]

Nice. 

[Karl Freeman]

Hey,

Sorry to bring this all up again however figured It would be best to keep continuity.

I've been keeping a separate fork roughly up to date which keeps the router in. Its not perfect but I've not faced many problems. I wanted to check before spending too much time on it whether the original idea of possibly bringing back the router is still something that would be considered? I know there are some blockers still outstanding with tmm1/http_parser.rb which look to be resolving themselves and that the router was removed due to complexity ( and for the most part lack of internal use from original contributors ).

If some people got behind re-writing the router would this have support? or has the thinking changed that Goliath is better without it and that work should be directed towards a more abstract solution? 

p.s Doing an intial bit of research mustermann could be used as a large chunk of the routing logic.

p.p.s Varnish / Haproxy routing logic infront of ports is a great way of doing things but I found when separating my application like this ( as it currently stands right now ) that the overhead of running lots of small endpoints vs internal routing caused issues on small VM's 

[Karl Freeman]

*VM's should actually equal VPS's

[Ilya Grigorik]

Hey Karl.

The decision to drop the router wasn't really due to lack of use, but due
to all the bugs it rippled out... Majority of the open bugs were all
related to the router, and the design of it didn't lend to any easy fixes.
If all of those past issues could be addressed, I see no reason why we
couldn't bring it back. Although, I would probably like to see it as a
separate module (e.g. goliath-router gem, or similar).

For context see: https://github.com/postrank-labs/goliath/issues/143 and
https://github.com/postrank-labs/goliath/issues/143#issuecomment-4044950

ig

--
You received this message because you are subscribed to the Google Groups "Goliath.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to goliath-io+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.