A proposal for a fast, resilient and scalable service architecture. No dependencies.

• scalable on the fly
• no inter-service dependencies
• no dependency on startup order
• automagic reconnection

• http-client (like a browser)
• http-server and tcp-client (api)
• tcp-server (services)

The browser calls the api which calls service x which responds and the api relays data back to the client. Ports: api http/5001, people tcp/5002, pets tcp/5003, remote tcp/5004.

Clients connect to services on startup and try to reconnect on any socket end event during runtime. Services ignore socket end events as they can have multiple connections running. Clients exit if unsuccessful at connecting to all services. Services and clients exit and restarts on exceptions.

start the show

$ npm start

api

GET /people # returns people
POST /people?name=<string> # creates person
GET /people/pets?owner=<string> # returns pets by owner
GET /status # check status for all services
GET /hash?text=<string> # get md5 for supplied string from remote api

scale on the fly

$ pm2 scale <app> <n>

make remote service use proxy

$ HTTP_PROXY=http://<host>:<port> pm2 restart remote --update-env

connect directly to service

# one shot
$ echo -ne '{"cmd":"status"}' | nc <host> <port>
# or interactive mode
$ nc <host> <port>
> {"cmd":"status"}

$ npm test

• do tests
• add scale up and down to tests
• remove watcher from tests
• validate inputs
• compare bufferSize to payload before write
• log worker id
• add remote api service
• add timeout to remote api calls
• add basic auth
• add websockets
• use TLS
• deploy somewhere, monitor (w appmetrics or pmx) and run load-cron
• add support for HTTP_PROXY
• add message queue for disconnects/restarts like axon
• try send msg to process or use trigger
• try nc interactive mode
• use PM2 watch for dev
• add handler for service server error, close
• api polling for connection
• new service abstraction
• service exit and api reconnect on socket end
• catch uncaughtException, print error and exit?
• run w PM2
• add middleware to router
• use --max-memory-restart and --max-restarts
• service status end point
• connect to services in parallell
• use cluster
• cluster always keep n workers
• persistant connections between api and services
• refuse http requests during api reconnection
• make people own pets
• use persistant db
• make a router
• proper error handling
• figure out how to make req.pipe(people, { end:false }).pipe(res) work without ending the people stream