#Looking for someone to review a small project
13 messages · Page 1 of 1 (latest)
post it on github
This is it! https://github.com/hassanshaikley/demo
- Do not call
GenServerfunctions outside of module that implement behaviour - You have race condition in your application supervisor.
BearCountershould be aboveEndpoint - I do not see reason for
BearCounterSupervisor
Ok, I'm coming from the Erlang side, but just a comment on bear_counter.ex ; I would collect my API functions (e.g those using GenServer.call) at the top, then collect the GenServer callbacks, and at the bottom of the file any Helper code. In the Erlang emacs-mode there used to exist a gen-server skeleton, not sure if something similar exist in the Elixir world.
In Elixir most of that skeleton is not needed as Elixir's wrapper provide default implementation for all functions except init/1
also in your handle_call's you return the 'state', is that intentional? usually you would return ':ok' or '{:ok, a_result_value}' or '{:error, reason}'
aha, ok, but for those that you do implement, I would gather them together right after the API functions (but as I said I'm an Erlang guy 🙂 )
There is No possibility for failure so no reason to return error tuple
yes, well the example is a bit too simple I guess since the state just is the counter itself
@sage cairn 1. Ah that was an oversight
2. How is there a race condition?
3. Makes sense.. I may just leave it anyways, though.
@glass raven Don't I already have the GenServer callbacks at the bottom and public functions at the top?
Regarding returning {:ok, result} I don't really see the need right now!
I think the race condition is happening because of the Endpoint therefore the BearCounterController is waking up first. At that time the BearCounter is not ready for use. That is why you should write the BearCounterSupervisor above the Endpoint.