Hi - apologies if this is well covered territory, I may have been using the wrong terminology when searching?
I’m looking for a way to build and version Elixir services (microservices?) independently of the main Phoenix UI. I want the Phoenix UI to ‘know’ when a particular service is available and provide links/etc, but also provide friendly information when a service is unavailable (due to patching, code upgrades, network issues, …).
Part of me wonders if I should build a separate registry (maybe even just in Ecto) to know what services have been ‘registered’ and ‘should’ be available - but aren’t. That seems to require the UI to be updated [to a minor degree, for routing at a minimum?] whenever a new service is added… which seems relatively reasonable (some of the ‘services’ may be Nerves based IOT devices - so… dynamic).
The other part of me wonders, should/does a dynamic and function-location agnostic application framework like Elixir/Phoenix have a way for me to run the edge-ui components of a dynamic system like this from the edge implementation (Phoenix remote routes?) - with dynamic routing when available - and a way to still let users know THEY didn’t do something wrong when it is not available?
Generally all of this is possible, but you need to deal with the extended state of those requirements. The state for the UI is no longer just data provided by a service expected to be available, but the state the UI renders needs to include availability statuses and such. Also you app needs to be able to return all those statuses instead of crashing on unavailability.
I’m however not aware of anything prebuilt you could use here for the registration portion of services. Registry would do, but requires processes to be up. I can imagine services to not give you access to register some of it’s processes that freely.
Is there a problem with using nodes for this? You can check their availability and you can always have well-known functions in your codebase that would allow checking for specific versions/features. You can iterate on that later by adding a layer of metaprogramming that excludes manual factors when defining them by hand.
Is there a specific use-case in mind for this feature to be in place? People usually need this when they want to run code on a different machine, the classical example being doing expensive computations. IMO FLAME covers this use-case extremely well and by having a unified codebase that can run on 1 or n numbers of different machines, a majority of issues that are symptoms of what are you trying to solve simply disappear.
