8 ms·

In light of your further questions, I feel like I should post. We're working on a microservice framework which: - does the routing to and from the actual

by tekacs 12y ago

In light of your further questions, I feel like I should post. We're working on a microservice framework which: - does the routing to and from the actual microservices - provides a structured enough interface (through our small language), that it can: - cache the results of requests out to any service - allow services to find and rely upon each other to compose functionality - run one lightweight runtime per service per machine (which never shuts down, but has little overhead due to its lack of state) - serve static assets both to clients and to microservices requesting them - allow services written in differing languages to talk to each other Perhaps this gives you a picture of what might fit the job description of a microservice framework? :P ... and if this sounds what HTTP servers do, you'd be partially right, but building such apps today is pretty non-trivial and hard to orchestrate. The focus on microservices is making it much more possible to build apps like this and we're personally betting on an approach which focuses on allowing each microservice to express as much as possible in its own little corner (using our language, which we use both for app structure and communications and gives different programming languages a neutral meeting point). We're over at http://wym.io/ http://wym.io/, where there's a demo of our language builder, for now. Hopefully this is low key enough. :P

amelius 12y ago
This sounds very useful. One further question. Say a service A calls service B. And let's say service B needs several seconds to complete, and emits a progress indicator every second (I assume this is possible?) Will A be able to read these progress indicators also every second, and send its own progress indicator to its caller?
- tekacs 12y ago
  It depends on the case, but an easy way to emit progress indicators in our system is to make the long-running service a generator. It looks like this: g = wym('/email') #=> Generator(id=<...>) g.on('value', (v) -> ... ) and /email looks like: function next(inp) { ... } return generator(next); Sending values in uses a slightly different syntax, and manually walks the generator through. :) A more trivial way is to pass in a callback for the service (we call them routes) to send its updates back to, but this requires more code to send values in. Edit: to be clear, using a Generator as above isn't very microservice-ey and will trigger our framework to start tracking local state to keep the generator around, which it will auto-free when it believes it can. This is a necessary evil with any long-running code, though. Better is to break up the code so that it may be called multiple times to progress state and returning generator('/someRoute') if possible. :P

by tekacs 12y ago

amelius 12y ago

This sounds very useful. One further question. Say a service A calls service B. And let's say service B needs several seconds to complete, and emits a progress indicator every second (I assume this is possible?) Will A be able to read these progress indicators also every second, and send its own progress indicator to its caller?

tekacs 12y ago
It depends on the case, but an easy way to emit progress indicators in our system is to make the long-running service a generator. It looks like this: g = wym('/email') #=> Generator(id=<...>) g.on('value', (v) -> ... ) and /email looks like: function next(inp) { ... } return generator(next); Sending values in uses a slightly different syntax, and manually walks the generator through. :) A more trivial way is to pass in a callback for the service (we call them routes) to send its updates back to, but this requires more code to send values in. Edit: to be clear, using a Generator as above isn't very microservice-ey and will trigger our framework to start tracking local state to keep the generator around, which it will auto-free when it believes it can. This is a necessary evil with any long-running code, though. Better is to break up the code so that it may be called multiple times to progress state and returning generator('/someRoute') if possible. :P