4 ms·

This is well written. I gave a talk at the (unaffiliated) Hacker News London Meetup on composing a microservice architecture and why I think a framework to bin

by tekacs 12y ago

This is well written. I gave a talk at the (unaffiliated) Hacker News London Meetup on composing a microservice architecture and why I think a framework to bind today's disparate components needs to exist: http://vimeo.com/118895501 http://vimeo.com/118895501 I don't so much believe that any language is perfectly poised to implement this, however - we're working on a framework[1] that focuses on making every language a first-class participant. Furthermore, it's self-hosting, with most of the core itself implemented as communicating microservices. It's possible to reimplement bits of the core in different languages! We've been waiting to finish a polished implementation before releasing anything (and talking to individual companies about their needs), but I'm starting to think that's a bad idea. :) [1]: http://wym.io/ http://wym.io/

aikah 12y ago
What's the difference between a spec and a "multi-language" framework? I mean there is none. You can't have a multi language framework without a strict interface therefore a spec. Now what you provide seems to be the actual framework and just not a spec,which is great, but how is it different from Rest or SOAP, in essence? Also,since languages are vastly different(in features), don't you think it will limit what your framework can do? Great talk anyway. I believe however,that having a central authority that orchestrates services is better than micro services that can talk directly to each other.In my opinion,some kind of mediator is mandatory,one that registers services and manage service communication.
- tekacs 12y ago
  Addressing each of your points in turn: - What's the difference from a spec? There used to be a FAQ on our site emphasising that at its core _wym_ is a spec. Our reference implementation, itself made up of multiple pieces (wymd, wymsy, oneweb, ...) provides a way to actually make use of that spec and to validate all the guarantees of the strict interfaces. Also, I'm not a fan of entities who would define a spec in isolation without a reference implementation alongside it - where's the proof that you're making the right decisions? We provide that implementation to keep ourselves grounded. - Won't multi-language limit features? Not really. For one thing, since we're self-hosting we can't afford to lack power and expressivity. For example everyone has the ability to refer to types (as per generics) else we wouldn't be able to implement the core. ;) Our interface language - it's quite simple, to make the addition of new language bindings trivial, but we expose built-in services to use more powerful features simply by switching which nodes you're holding on to - there's a data-implementation divide, where a node needn't understand a feature in order to deal in its data. The net effect is that language bindings can be created trivially and evolved to support features as a good way of dealing with them is found (e.g. in the simplest case, Javascript Int64 support). - Having a central authority is better. This is an interesting one :D - I agree, in a way. A wymd cluster self-starts a consensus using a lock service, performs master election and then uses this consensus service for registration and discovery. We have an elected distributed authority. :P
touristtam 12y ago
sorry about the off topic, but wym.io w/o js enabled on the page shows this: > function (){ return React.renderComponentToString(Application(null)); } Just looks a bit messy tbh. ;)
- tekacs 12y ago
  Hm, that's interesting. I went to great lengths to ensure it rendered without JS (since it's all React)! :P I'll look into it. Thanks. :)
  - e12e 12y ago
    Looking at the source-code sent to the browser, I'm afraid there's scant evidence of that. I take it the idea was that the snippet in the body (as mentioned above) was to be rendered on the server? If you figure it out, please let us know/write it up -- being able to use react and have it work without javascript would be a very nice feature.
    - tekacs 12y ago
      Ask and I shall deliver. Fixed. :P I'll upload our build setup right about when I write a blog response to the OP's post. :) The chief point to note is that the components need to render as you want non-JS viewers to see them when they're passed the default props/state.

by tekacs 12y ago

aikah 12y ago

What's the difference between a spec and a "multi-language" framework? I mean there is none. You can't have a multi language framework without a strict interface therefore a spec. Now what you provide seems to be the actual framework and just not a spec,which is great, but how is it different from Rest or SOAP, in essence? Also,since languages are vastly different(in features), don't you think it will limit what your framework can do? Great talk anyway. I believe however,that having a central authority that orchestrates services is better than micro services that can talk directly to each other.In my opinion,some kind of mediator is mandatory,one that registers services and manage service communication.

tekacs 12y ago
Addressing each of your points in turn: - What's the difference from a spec? There used to be a FAQ on our site emphasising that at its core _wym_ is a spec. Our reference implementation, itself made up of multiple pieces (wymd, wymsy, oneweb, ...) provides a way to actually make use of that spec and to validate all the guarantees of the strict interfaces. Also, I'm not a fan of entities who would define a spec in isolation without a reference implementation alongside it - where's the proof that you're making the right decisions? We provide that implementation to keep ourselves grounded. - Won't multi-language limit features? Not really. For one thing, since we're self-hosting we can't afford to lack power and expressivity. For example everyone has the ability to refer to types (as per generics) else we wouldn't be able to implement the core. ;) Our interface language - it's quite simple, to make the addition of new language bindings trivial, but we expose built-in services to use more powerful features simply by switching which nodes you're holding on to - there's a data-implementation divide, where a node needn't understand a feature in order to deal in its data. The net effect is that language bindings can be created trivially and evolved to support features as a good way of dealing with them is found (e.g. in the simplest case, Javascript Int64 support). - Having a central authority is better. This is an interesting one :D - I agree, in a way. A wymd cluster self-starts a consensus using a lock service, performs master election and then uses this consensus service for registration and discovery. We have an elected distributed authority. :P

touristtam 12y ago

sorry about the off topic, but wym.io w/o js enabled on the page shows this: > function (){ return React.renderComponentToString(Application(null)); } Just looks a bit messy tbh. ;)

tekacs 12y ago
Hm, that's interesting. I went to great lengths to ensure it rendered without JS (since it's all React)! :P I'll look into it. Thanks. :)
- e12e 12y ago
  Looking at the source-code sent to the browser, I'm afraid there's scant evidence of that. I take it the idea was that the snippet in the body (as mentioned above) was to be rendered on the server? If you figure it out, please let us know/write it up -- being able to use react and have it work without javascript would be a very nice feature.
  - tekacs 12y ago
    Ask and I shall deliver. Fixed. :P I'll upload our build setup right about when I write a blog response to the OP's post. :) The chief point to note is that the components need to render as you want non-JS viewers to see them when they're passed the default props/state.