> Superagent is a pretty impressive node REST client, in case you wanted to experiment.
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.er...@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.er...@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 >>> >> >> > >
