tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@gmail.com>
Subject Re: [DISCUSS] Tuscany.js - an assembly model for Node.js micro-services
Date Sat, 24 Oct 2015 03:30:38 GMT
> Superagent is a pretty impressive node REST client, in case you wanted to

Yes, Superagent is very nice. I've also been using Request [1] ... works
really well!

[1] https://www.npmjs.com/package/request

- Jean-Sebastien

On Wed, Oct 21, 2015 at 8:36 AM, Ole Ersoy <ole.ersoy@gmail.com> wrote:

> Hi Jean-Sebastian,
> Honestly I have not had a chance to play with Seaport yet (Hope to get to
> it soon).  Someone else also asked about maintenance here:
> https://github.com/substack/seaport/issues/72
> Looks like he's still waiting on a response.  I imagine you could take a
> REST HATEOAS approach to WRT communicating what services are related to /
> referenced by a particular service:
> https://spring.io/understanding/HATEOAS
> Superagent is a pretty impressive node REST client, in case you wanted to
> experiment.  I'm also working on a Maven like build system for Node called
> VerdiJS.
> https://github.com/verdijs
> It will use self contained modularized Gulp based tasks for compiling ES6,
> Coffescript, etc. like this one:
> https://github.com/verdijs/verdijs-task-clean
> And utilize the same type of standard directory structure that Maven uses.
> https://github.com/verdijs/verdijs-pli
> Cheers,
> - Ole
> On 10/21/2015 01:00 AM, Jean-Sebastien Delfino wrote:
> Hi Ole,
> Seaport looks nice and could maybe become part of a Node-friendly
> solution. It looks like a registry like many other registries out there
> allowing me to lookup a service name@version and get its host:port, but
> pretty light weight.
> Do you know if Seaport would also allow me to store the fact that a
> service X references service Y? (as that's really what I'm looking for with
> SCA references bound to services, locating service Y is only a small part
> of the story...)
> Also is Seaport still actively maintained?
> Thanks!
> - Jean-Sebastien
> On Sun, Oct 18, 2015 at 11:07 PM, Ole Ersoy <ole.ersoy@gmail.com> wrote:
>> Hello Jean-Sebastien,
>> You may also want to have a look at [Top 10 Browserling Inventions](
>> http://www.catonmat.net/blog/top-10-browserling-inventions/).
>> I think you would be interested in the Seaport Service Registry, Ploy,
>> Airport, Upnode, and Bouncy.
>> Cheers,
>> - Ole
>> On 10/19/2015 12:25 AM, Jean-Sebastien Delfino wrote:
>>> Hi all,
>>> It has been a while...
>>> Today I was reflecting on what I've been doing in the last two years,
>>> mostly micro-services on Node.js, and I'm starting to think that the
>>> original ideas behind SCA and Tuscany may be useful to me again. So you may
>>> hear a bit more from me on this list again in the next few weeks...
>>> My new world is very different from the world we initially created
>>> Tuscany for: Node.js, Javascript everywhere, isomorphic Web apps, simple
>>> REST 'services', simple middleware and databases, and not much technical
>>> complexity getting in the way of writing business logic. Many of the issues
>>> we were trying to address with SCA like multi-language, multi-protocol,
>>> complexity of the JEE platform and WS stack, weird objects requiring
>>> injection etc, don't exist anymore in my new world.
>>> That's great as developing Web micro-services has become really easy! So
>>> easy that I have so many micro-services in my apps now that sometimes it
>>> gets a bit hard to keep track which service calls which, what's that
>>> service address, what I need to change when that service moves or gets
>>> updated, or what's involved when something goes wrong and I need to find
>>> which service broke.
>>> That's a serious problem, and something that made me think about SCA and
>>> Tuscany again. Despite all the greatness of Node.js and REST and
>>> micro-services, I'm probably still missing some kind of assembly model like
>>> we had with SCA. Something that would model my app as as an assembly of
>>> micro-services. Something that would allow my services to reference each
>>> other without having to update environment variables all over the place
>>> with their addresses. Something that would allow me to understand that a
>>> service broke because another service that it references is currently down.
>>> Something that would provide a description of my service call graphs for
>>> debugging for example. Right now, it's really easy for me to develop
>>> micro-services and wire them together, but I don't have a good way to model
>>> that wiring.
>>> Maybe what I'm looking for is a small subset of the original SCA
>>> concepts: a description of my app as an assembly of services, Javascript
>>> friendly, simple and lightweight, declarative but programmable, and
>>> distributed and dynamic as my services need to move around to scale out or
>>> when a Cloud region goes down. So, I'm going to spend some of my spare time
>>> on this, evenings and weekends, and try to put together a new variation of
>>> Tuscany for Node.js. I'd like to figure out if that good old SCA can help
>>> me again with my little micro-services issues.
>>> I'm thinking about calling that new variation of Tuscany 'Tuscany.js',
>>> and maybe put it in a new 'js' sub-folder in the Tuscany repo besides the
>>> existing java and cpp folders.
>>> I'd love to work on it with other folks in the community if they're
>>> interested! Thoughts?
>>> - Jean-Sebastien

View raw message