Comments (5)
Hi! In regards to this feature, one idea from @jvgutierrez was to keep eureka integration out of the scope, and just generate a cmdclient that takes care of the service -> ip address resolution (i've found some "good ones" we can reuse or extend - they lack tests, for instance, especially to guarantee compat with latest versions -, rather than implementing from scratch as i was doing. See https://github.com/ArthurHlt/go-eureka-client or https://github.com/Alcereo/eureka-cli). So an user trying to incorporate this to their CI/CD pipeline can integrate both things... this is closer to the Unix philosophy (do one thing and do it well).
However, and just from my perspective, considering the tool mission (facilitate its integration in the test suite), I'd bet on continuing the service discovery integration, as makes easier the integration with the delivery pipelines (you avoid an extra wrapper/script...), and i think is a common need (we are already resolving dns to ip addresses for free, right? xD). Please, if you don't agree with the approach, raise your hand.
from tcpgoon.
I understand your point on facilitating the integration with the delivery pipeline, but I also see using two tools is something good because if not we are making it too much tangled with Eureka (and other use-cases could need to integrate with other service discovery tools).
I mean, if we can provide an easy way to decouple this it could be easy to reuse for other use cases, and if the current solutions for Eureka doesn't fulfill our requirements, we can always extend them.
from tcpgoon.
A service discovery client in form of a CLI tool could be pretty useful for debugging purposes, ping $(discovery service1-backend)
or nc -zv $(discovery service1-backend) 443
. It can be easily reusable and you keep this tool in UNIX style, (do one thing and do it well)
from tcpgoon.
Hi. Thanks everyone for the feedback, especially @jvgutierrez!! While I also think tcpgoon should just do one thing well, my concern is the discovery client means another binary/script requiring installation; that may not be a problem in most of the scenarios, but one of the project goals is to facilitate as much as possible the integration in your test suite (that's one of the reasons of deliverying also a dockerized version of the tool), so a dependency/second tool requiring stretch collaboration breaks the possibility of shipping and executing all the logic in a "single docker run".
So then, considering this, and bearing in mind this discovery logic should be as decoupled as possible to the main tool logic, the implementation could end up by:
- refactor one of the eureka clients I mentioned before so they conform an standard interface we will make any discovery implementation to follow
- apply dependency inversion: inject the discovery implementation we need as a dependency (keeping it as an external package), so the project is as decoupled as possible, and adding extra discovery implementations do require minimal changes in this project
Do not hesitate to continue sharing your feedback!!
from tcpgoon.
from tcpgoon.
Related Issues (20)
- Docker image generation for easy consumption HOT 2
- Per connection metrics and some stats in final report HOT 2
- Simple version field using the golinker flags HOT 3
- Handle partial successful execution HOT 3
- OS packages generation with man pages HOT 2
- Benchmark the solution...
- New execution modes? HOT 5
- Debug mode can be implemented cleaner
- Assure DNS resolve is done only once HOT 8
- README autoupdater? HOT 3
- Are the wait group we use in the tcpconnect and the closureMonitor overlapping?
- User confirmation not properly processed when run as a container HOT 1
- Coverage reporting, analysis and integration with PRs HOT 1
- Migrate to latest golang version 1.14
- Simple discovery implementation to define the interface we will extend
- Support Docker images testing
- End to end test HOT 1
- mtcpclient.MultiTCPConnect tests
- Migrate to standard repo layout
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tcpgoon.