Add feature to allow ceryx to be used as data by-pass proxy
Hello there! I'm happy user of ceryx for around a year now and I've implemented a small set of features for a specific use-case at my startup: using ceryx as configurable proxy to by-pass a cluster application for database access.
The following merge request is rather big, but all the changes are important to enable this use-case / feature / pattern. Let me explain to you what is happening. I hope you can appreciate the additions and I'm happy to make adjustments wherever necessary.
The base material explaining the use-case on a rather theoretical basis is a document from the Eclipse Ditto documentation, Data By-Pass Pattern. The basic idea is to place a random UUID with a "hidden" source URL together with authorization information in ceryx and return a 303 to the client which then is able to get a database query executed by calling ceryx with the UUID, without ever seeing the actual query or credentials. The environment is a cluster application which is not suited to pipe big amounts of data like in a database query.
To enable this I've added several things which are all explained in more detail in the README.
- Ability to use arbitrary strings as source
- Ability to use request uri params for targets
- Ability to provide headers for ceryx calling the target, e.g. for Authorization or Host headers
- Ability to provide a TTL to automatically clean up and invalidate routes after a certain amount of time
As said previously I'm using this modified Ceryx for about a year now and I think these features could benefit more people out there.
Tell me what you think! :)
More ideas:
- Ceryx could execute queries in advance, cache them and discard after TTL runs out
👍
Hi @w4tsn thanks a lot for your proposal and your kind works. We will get back on this next week, in order to review the use case, semantics and implmentation.
After thinking about this a bit more: I'm totally with you regarding your opinions and ideas on where to go from here but honestly I believe that all those requests is actually killing this MR because it extends the scope to something that I think is worth at least one more MR. Do you see any way of getting this MR merged and starting from there to tackle the refactor and new features?