Service Fabric Support #1091
-
|
I believe I saw Service Fabric support was pulled from the upcoming release (here). Is there any information available on why this is the case and what the roadmap looks like for it's inclusion? Thanks Carl |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
We have marked service fabric support as not in the 1.0 release because we don't have enough usage to consider it baked, and the implementation is using polling rather than notifications so we don't think it will scale well. Once we declare something as released, it implies support and a high degree of API/Protocol stability that we are not comfortable stating for SF support in its current form. That being said, we are not deleting the code, we're just not giving it the stamp of approval. We'll gladly accept PRs to improve it. The more feedback we get on it, the more comfortable we'll feel about calling it done. If you need it, I'd suggest building from your own fork so you can quickly make any necessary fixes, and then push them upstream, without being dependent on YARP for the turn around. The code in there is not rocket science, and should be readily understandable (if its not then that is also valuable feedback). |
Beta Was this translation helpful? Give feedback.
-
|
Update: We had a meeting with the SF team and a couple of other folks. We have a team who has an updated version of the SF integration with YARP that is architected much better. We are working on a plan for productization of that, so more info will be coming soon, stay tuned. 😺 |
Beta Was this translation helpful? Give feedback.
-
|
We are monitoring this closely as we are trying to find an alternative to Traefik for accessing APIs hosted in stateful partitions. Excited! |
Beta Was this translation helpful? Give feedback.
-
|
Also very interested in this work. Please keep us updated. Also using Traefik, which is a pain to work with in SF. |
Beta Was this translation helpful? Give feedback.
We have marked service fabric support as not in the 1.0 release because we don't have enough usage to consider it baked, and the implementation is using polling rather than notifications so we don't think it will scale well. Once we declare something as released, it implies support and a high degree of API/Protocol stability that we are not comfortable stating for SF support in its current form.
That being said, we are not deleting the code, we're just not giving it the stamp of approval. We'll gladly accept PRs to improve it. The more feedback we get on it, the more comfortable we'll feel about calling it done.
If you need it, I'd suggest building from your own fork so you can quickly ma…