Shared I/O State

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Shared I/O State

orubel
Since Grails 3 mvc binds the request/response to the controller, I/O state can't be shared with other services in a distributed microservice architecture.

How does Grails propose sharing I/O state in a distributed microservice architecture without massive duplication so that edge cases can handle functionality early and late.

For example, if the proxy wanted to do checking based on the rules for the endpoint (ie what roles are associated, what request method is associated, what data should be sent with request, etc) and reject or forward, it should be able to and also synchronize the data should changes be made at the source. Same with MQ or other services.

Also, loopbacks should be able to be done without the request having to go out and come back in to the service; there should be a level of autonomy.

How does Grails handle this?

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/3a56035c-9e28-4ff2-b6c0-dd62c61a3074%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Shared I/O State

orubel
Got a response back from OCI:

"The framework continues to evolve to broaden the types of applications which it is very well suited for. In 2017 we will have very exciting announcements related to micro services in particular"

Unfortunately, this does not state whether they will be solving this issue

On Tuesday, December 27, 2016 at 2:14:24 PM UTC-8, [hidden email] wrote:
Since Grails 3 mvc binds the request/response to the controller, I/O state can't be shared with other services in a distributed microservice architecture.

How does Grails propose sharing I/O state in a distributed microservice architecture without massive duplication so that edge cases can handle functionality early and late.

For example, if the proxy wanted to do checking based on the rules for the endpoint (ie what roles are associated, what request method is associated, what data should be sent with request, etc) and reject or forward, it should be able to and also synchronize the data should changes be made at the source. Same with MQ or other services.

Also, loopbacks should be able to be done without the request having to go out and come back in to the service; there should be a level of autonomy.

How does Grails handle this?

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/81121377-4b28-4d5a-a53c-f434fc34c82b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Shared I/O State

orubel
In reply to this post by orubel
Will be speaking on this at U of Wash Tech Talks. Stop on by if you want to see a Groovy IOT example that runs 100K requests in 30 secs with full Spring security install

On Tuesday, December 27, 2016 at 2:14:24 PM UTC-8, [hidden email] wrote:
Since Grails 3 mvc binds the request/response to the controller, I/O state can't be shared with other services in a distributed microservice architecture.

How does Grails propose sharing I/O state in a distributed microservice architecture without massive duplication so that edge cases can handle functionality early and late.

For example, if the proxy wanted to do checking based on the rules for the endpoint (ie what roles are associated, what request method is associated, what data should be sent with request, etc) and reject or forward, it should be able to and also synchronize the data should changes be made at the source. Same with MQ or other services.

Also, loopbacks should be able to be done without the request having to go out and come back in to the service; there should be a level of autonomy.

How does Grails handle this?

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/83a55232-8939-47ef-9a1e-1b07b63a1b33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Shared I/O State

orubel
In reply to this post by orubel


On Tuesday, December 27, 2016 at 2:14:24 PM UTC-8, [hidden email] wrote:
Since Grails 3 mvc binds the request/response to the controller, I/O state can't be shared with other services in a distributed microservice architecture.

How does Grails propose sharing I/O state in a distributed microservice architecture without massive duplication so that edge cases can handle functionality early and late.

For example, if the proxy wanted to do checking based on the rules for the endpoint (ie what roles are associated, what request method is associated, what data should be sent with request, etc) and reject or forward, it should be able to and also synchronize the data should changes be made at the source. Same with MQ or other services.

Also, loopbacks should be able to be done without the request having to go out and come back in to the service; there should be a level of autonomy.

How does Grails handle this?

--
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 [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/grails-dev-discuss/ca376d98-7cb7-457f-9010-24f3b5a13ebe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.