feat: subscription installer #266
Conversation
| @@ -183,57 +184,158 @@ if Code.ensure_loaded?(Igniter) do | |||
| end | |||
| end | |||
|
|
|||
| def setup_application(igniter) do | |||
There was a problem hiding this comment.
I created these two functions because it felt like there was a pattern. Looking at it afterwards, this all feels pretty phoenix specific with Pheonix.Socket and Endpoints.
I would refactor this and make these defps that are called as part of setup_phoenix. WDYT?
|
As subscriptions are opt in at the moment, we should also make it a flag for the installer to add it? |
|
@zachdaniel could you give this an quick glance please and let me know if I should continue this way? |
|
Do you think subscriptions could just be unflagged now? I feel like no one uses it because it's behind a flag 😆. Lets just open it up and install this automatically. |
|
Some tests would be good to add, specifically for the complex case of adding the parser |
The parser part is actually not new 😅 but I agree. I'll look into adding some installer tests in general. |
@zachdaniel I feel pretty good about it after the experiment I made last week. Only thing to consider is that we should maybe rename the pubsub option in the subscription dsl. Because the way Absinthe subscriptions are called you actually need to configure the Endpoint here and not the PubSub directly? At least it tripped me up, when I implemented subscriptions last week. Not sure I'm happy with just calling it enpoint either though? |
|
I think that module is anything with a broadcast function right? |
It's something that implements the Absinthe.Subscription.Pubsub so i guess pubsub is probably the right word. It just tripped me up because I tried to configure the |
Contributor checklist