Add API I/O Abstraction

86 views
Skip to first unread message

Owen Rubel

unread,
Nov 24, 2014, 11:20:49 AM11/24/14
to grails-de...@googlegroups.com
Hi all,

I've been working on several high level api concepts for awhile (with Grails being my language of choice) and have been branching out recently to see how well this works with other languages, scalability, adaptability, etc to make sure it could fit a universal model of adaptability for adoption. I'm to a point where I feel I can present this as something I would like the Grails main body to adopt.

To explain, API's exist of two sets of functionality: resource management and I/O for that resource management. When we build API's, we commonly move the I/O to a service but we still have to attach it somehow via a service call or an annotation.

As a result of this I/O binding to the controller/method for API's, I/O becomes an architectural cross cutting concern because once we extend the request/response out to request/response tooling (proxy. api gate, MQ, etc) all I/O functionality and data for API's need to be replicated in the architecture.

Also, internally, if we have forwards, we create a new thread/process that has to go out and come back in rather than using the existing thread.

Node.js uses something called Strongloop and Loopback which are basically the handlerInterceptor to do a handoff between the preHandler/postHandler so forwards, batching, chaining, etc can be internalized.

But BEYOND that, we can create a common apiObject which can be shared across the architecture and all instances, which stores a common set of api data that can be preloaded at runtime, is reloadable on the fly and is shared by all the architecture.

And the best part... this completely separates the controller so you require ZERO annotations!

and it is working in the grails api toolkit. I'd like to go ahead and merge this and was wondering about thoughts and requirements.

Jeff Scott Brown

unread,
Nov 24, 2014, 11:24:32 AM11/24/14
to grails-de...@googlegroups.com

> On Nov 24, 2014, at 10:20 AM, Owen Rubel <oru...@gmail.com> wrote:
>
> I'd like to go ahead and merge this and was wondering about thoughts and requirements.

It isn’t clear to me where you would like to merge something. Are your changes made to grails-core?



JSB

--
Jeff Scott Brown
jbr...@gopivotal.com

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/



Owen Rubel

unread,
Nov 24, 2014, 11:44:16 AM11/24/14
to grails-de...@googlegroups.com
Well I'd like to merge them in. I'm working on spring-boot right now to convert these changes to something that will work with grails 3.0

Jeff Scott Brown

unread,
Nov 24, 2014, 12:00:28 PM11/24/14
to grails-de...@googlegroups.com

> On Nov 24, 2014, at 10:44 AM, Owen Rubel <oru...@gmail.com> wrote:
>
> Well I'd like to merge them in. I'm working on spring-boot right now to convert these changes to something that will work with grails 3.0
>
> On Monday, November 24, 2014 8:24:32 AM UTC-8, jbrown wrote:
>
> > On Nov 24, 2014, at 10:20 AM, Owen Rubel <oru...@gmail.com> wrote:
> >
> > I'd like to go ahead and merge this and was wondering about thoughts and requirements.
>
> It isn’t clear to me where you would like to merge something. Are your changes made to grails-core?
>
>

Will any of the changes require code changes in grails-core or is it all in spring-boot?

Owen Rubel

unread,
Nov 24, 2014, 2:01:14 PM11/24/14
to grails-de...@googlegroups.com
Well the great thing about grails is that it is modular and they made the environment modular. API development is added as a modular component. With this, you can add api as a modular component without requiring annotations; you merely need to pass through the handlerInterceptor. This makes it so I/O can be more easily handled through the architecture as you 'build for now but build to scale'.

So an apiObject can separate you I/O data for the api but this enables it to easily be shared with any and all architectural components and placing I/O checks in handlerInterceptor enables preHandler/postHandler handoff for a single threaded request/response

This also allows us to have further conversations on apiChaining, etc for improved API in Grails which puts Grails WAY out in front of the curve.

Søren Berg Glasius

unread,
Nov 24, 2014, 2:18:05 PM11/24/14
to grails-de...@googlegroups.com
to me it sounds more like a Grails plugin that you can select to add to your project, and in that sense it sounds like a great plugin!


Best regards / Med venlig hilsen,
Søren Berg Glasius

40 Stevenson Ave, Berkeley, CA 94708
Mobile: (+1)510 984 8362, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.

--
You received this message because you are subscribed to the Google Groups "Grails Dev Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-disc...@googlegroups.com.
To post to this group, send email to grails-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/dce5ba4a-1e7d-47ae-8cbf-e5bf6c27bbc0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Jeff Scott Brown

unread,
Nov 24, 2014, 2:39:16 PM11/24/14
to grails-de...@googlegroups.com
I am sorry to be difficult but please read the questions asked in my previous 2 messages in this thread. I am trying to find out if you have made code changes that you would like merged into grails-core. It may be that you have answered that and I am just missing it. I know that Grails is modular. I know that an api can be added without requiring changes to grails-core. We have had good for support for that sort of thing since the beginning. What I am trying to find out is if your particular changes that you want merged are to be merged into grails-core. 

Thanks. 


Jeff

Sent from my iPhone

Jeff Scott Brown

unread,
Nov 24, 2014, 2:52:46 PM11/24/14
to grails-de...@googlegroups.com
The original message says "I'd like to go ahead and merge this...".  I am just trying to clarify what the "this" is there, and were it is that you would like to merge it.  

Thanks again. 



Jeff

Sent from my iPhone

Owen Rubel

unread,
Nov 24, 2014, 4:21:10 PM11/24/14
to grails-de...@googlegroups.com
Ah ok, my fault. I'd like to 'contribute' it to the main Grails branch. That should clarify. And Soren is right that it makes a good plugin but I feel that this would provide a very good direction for the community with api development, simplify development for api's (which is what Grails is all about), and reduce processes/threads.

Grails (and many communities) has been to focus on tying directly to the Domain object but the real issue has been to abstract the I/O to a higher level. Node resolved this with LoopBack and StrongLoop and I did this in Grails with the HandlerInterceptor with even better results than Node as alot of Node implementations do not have access to the java libs and full integration that a Java framework has.

That being said you can simplify API development and reduce processing/throughput and increase functionality.

If there are any question, I would LOVE to pop on down to Pivotal HQ and talk to some of the guys or even do an online chat. Can even share the video for the SpringOne talk I gave on the topic.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

Jeff Scott Brown

unread,
Nov 24, 2014, 4:30:39 PM11/24/14
to grails-de...@googlegroups.com

> On Nov 24, 2014, at 3:21 PM, Owen Rubel <oru...@gmail.com> wrote:
>
>
> If there are any question, I would LOVE to pop on down to Pivotal HQ and talk to some of the guys or even do an online chat.

FYI… Going to Pivotal HQ wouldn’t help with access to the Grails team. I live closer to Pivotal HQ than any other members of the team and I live about 2,000 miles east of there. We do most of our communication within the team via video chat.

Owen Rubel

unread,
Nov 24, 2014, 5:53:20 PM11/24/14
to grails-de...@googlegroups.com
LOL. Ah... ok then. :)

Well I can provide whatever is needed and am more than happy to if it would mean people understanding the concept at the very least; doesn't even have to mean it leading to adoption internally... but I think alot of people would see the benefit to moving towards this way of doing it eventually.

Jeff Scott Brown

unread,
Nov 25, 2014, 8:55:24 AM11/25/14
to grails-de...@googlegroups.com

> On Nov 24, 2014, at 3:21 PM, Owen Rubel <oru...@gmail.com> wrote:
>
>
>
> If there are any question, I would LOVE to pop on down to Pivotal HQ and talk to some of the guys or even do an online chat.

A good next step would be to write up a slightly more detailed description of the problems being solved and summarization of the planned implementation (or if an implementation already exists, describe it). Having a more clear understanding of the problems that your proposal aims to solve and how it does that will help us move forward.

Thanks a lot for taking time to help.

Owen Rubel

unread,
Nov 25, 2014, 10:54:40 AM11/25/14
to grails-de...@googlegroups.com
Should I submit back here when I have it finished?

Jeff Scott Brown

unread,
Nov 25, 2014, 11:08:09 AM11/25/14
to grails-de...@googlegroups.com

> On Nov 25, 2014, at 9:54 AM, Owen Rubel <oru...@gmail.com> wrote:
>
> Should I submit back here when I have it finished?
>

Sure.



Jeff

Owen Rubel

unread,
Nov 25, 2014, 11:47:23 AM11/25/14
to grails-de...@googlegroups.com
Here you go... let me know if this works.


On Tuesday, November 25, 2014 5:55:24 AM UTC-8, jbrown wrote:
API Abstraction Proposal.doc

Owen Rubel

unread,
Nov 29, 2014, 12:31:28 PM11/29/14
to grails-de...@googlegroups.com
Well thank you. I like to think the Grails API Toolkit is a great plugin too. :)

I would just like to see it adopted as more of a standard for extensible, scalable api development for a 'build for now but build to scale' environment.
To unsubscribe from this group and stop receiving emails from it, send an email to grails-dev-discuss+unsub...@googlegroups.com.

To post to this group, send email to grails-de...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages