Docker Swarm by its own, and also any kind of cloud orchestrator, lacks of API Gateway management.
The main focus of Cloud Platform is to provide orchestration and network communication between microservice. But the Gateway is important as well if you need to expose API to a client (say a ReactJS application, or a mobile application). Generally, the requirement is to expose as many entrypoint, as the GUI Application need for obtaining data.
Thanks to Traefik and a dedicated service that communicate with docker API, it is possible to implement a good API Gateway manager. I developed the idea during Ironman 2018 in Frankfurt am Main (a warm season, a small office, a small company, resting from my training). I implemented this in few weeks
Key features:
- Visual way for defining API entrypoints
- Multistep pipeline definition for each entrypoint (it is possible to use previous steps to compose internal calls)
- Steps can be dragged and arranged in the GUI
- Group Entrypoints by domain
- Switch on/off by domain: control your API
- Security: protect internal services from external access
- JWT token authentication & decode: forward the claim to internal service
- Speedup mock and demo, by direct access to special service serving SQL
- Discover internal services by Labels, thanks to ad hoc service in Golang
- Dedicated discovery service for selecting internal service call
- Expose REST or multipart-form: at entrypoint level
- Mapping incoming JSON payload to internal payload
- Based in Traefik (maintained, opensource project)
Similar projects
A project with some interesting features is https://konghq.com/products/kong-gateway. But this does not implement the pipeline of internal calls.
Conclusion
Being a time constrained project, and leading to a bad practice (rely directly on database structure), turns out to be a game changer for API mockup, and improve the time-to-market to the minimum.
Still I recognise the value of mocking up it quickly, but this generates conflict between (un-educated) developers. Some would talk about “culture”, but really not understanding the negative consequences of a technology look-in in term of release cycles, for me is an educational question.
It looks like a no-code, or low-code solution, but the name that better describe it is: mockup your Rest API.
After mockup, and MVP evaluation, real service must be written.
Are you interested in Consulting Service? Contact me
