Fiber: 🚀 Implement Fiber Events for Service Discovery

[sujit-baniya]

Is your feature request related to a problem?
No
Describe the solution you'd like
In Fiber, it would be great, if fiber could implement notification using some kind of event functions. This is the most important aspect for Service Discovery. This could be implemented by using some couple of callback functions like:
app.OnStarting
app.OnStarted
app.OnShuttingDown
app.OnShutDown

These changes are more helpful when fiber is behind any load balancers or proxies.

[WLun001]

Service discovery can be achieve with orchestrators like Kubernetes or/and service mesh. My personal opinion is leave this kind of problem to infrastructure level instead of doing it at code level

[sujit-baniya]

@WLun001 yes Kubernetes does that...
In my opinion, Callback functions on different events of fiber will be more helpful for production without Kubernetes or Docker.
This feature is more about doing something on those events rather than Service Discovery stuff.

Service Discovery is just one of the use case.

Other use case could be:
1) OnStarted, bring up all essential services for the app to work. Currently we bring up all those services before the app is actually up. For any reason the app is not able to start, bringing up those services doesn't make sense
2) OnShutDown, bring down all services. Mostly use for cleanup

For e.g.
On start, I want to send email to Admin, Read JSON, Do some migrating stuff, etc.
With current situation, If we do above stuff before the app is actually up and for some reason App is unable to start.
We already send email to Admin (MISINFORMATION), Reading JSON is not helpful at all, etc.

So those events allow to control some stuffs.

[kiyonlin]

leave this kind of problem to infrastructure level instead of doing it at code level

I agree with @WLun001

And hey @sujit-baniya Here are some of my thoughts about your comment above:

1. OnStarted, bring up all essential services for the app to work. Currently we bring up all those services before the app is actually up. For any reason the app is not able to start, bringing up those services doesn't make sense

Look, if app relies on these essential services, they must be setup before app is up unless they are not indeed essential services.

1. OnShutDown, bring down all services. Mostly use for cleanup

Just do cleanup stuff after calling app.Shutdown.

On start, I want to send email to Admin, Read JSON, Do some migrating stuff, etc.
With current situation, If we do above stuff before the app is actually up and for some reason App is unable to start.
We already send email to Admin (MISINFORMATION), Reading JSON is not helpful at all, etc.

In this case, we should send email to Admin immediately why App is unable to start, right?

[WLun001]

In addition to comment above, here is my thought

OnStarted, bring up all essential services for the app to work. Currently we bring up all those services before the app is actually up. For any reason the app is not able to start, bringing up those services doesn't make sense

@sujit-baniya This is infrastructure problem. If your app depends on some other services, then should start with the sequence.

OnShutDown, bring down all services. Mostly use for cleanup

I guess you mean disconnect to all services, as one service should not able or attempt to shut down other services. Here is an example of graceful shutdown

On start, I want to send email to Admin, Read JSON, Do some migrating stuff, etc.
With current situation, If we do above stuff before the app is actually up and for some reason App is unable to start.
We already send email to Admin (MISINFORMATION), Reading JSON is not helpful at all, etc.

This is the problem with readiness of your app. Most orchestrators have readiness checks

[sujit-baniya]

Hi @kiyonlin Thanks for your feedback.
Please help me understand in this situation:

Let's say I'm not using any cloud services or containers or orchestrators. I've couple of fiber application out of which I'm using one of them as load balancer. Other fiber App with their respective IPs and Port are stored on Redis [Manually].
Load Balancer on specific interval goes and pick up those IPs from Redis.

How would I do similar stuff in automated way?

Maybe I'm missing something :)
Sorry for not understanding the stuffs

[WLun001]

What you are doing is building infrastructure to support load balancer and service discovery, which I think of out of scope for a web framework.

Consider the dedicated tools for the following purposes:

• Load balancer : Traefik, Caddy or Nginx
• Service mesh: Linkerd, Maesh, or Istio

[kiyonlin]

@sujit-baniya I also think you need a load balancer like @WLun001 mentioned above.

PS: Nginx has always been my first choice. But maybe you should try Caddy.

[sujit-baniya]

@kiyonlin @WLun001 Thanks for your suggestion. I was trying Caddy before.

[sujit-baniya]

BTW what do you think for above functions OnStarted and OnShutdown implementation in Fiber?

[Fenny]

I'm not a fan of adding more methods to the framework, is it an idea to allow an optional argument to Listen and Shutdown that acts as a callback? Just an idea, still not sure if we need to add this functionality in the first place 😕

app.Listen(":3000")
app.Listen(":3000", func() {
    fmt.Println("Server listening on port 3000")
})

app.Shutdown()
app.Shutdown(func() {
    fmt.Println("Server closed last connection")
})

PS: I used the Load balancing feature in Cloudflare for many years without problems, highly recommended (worth every penny).

[sujit-baniya]

@Fenny yes exactly like an optional callback

[hi019]

This should probably be implemented in the app layer. What about

Started()
defer Shutdown()
if err := app.Listen(":3000"); err != nil {
    // handle err
}

[Fenny]

I think @hi019 and @WLun001 are correct, this should be handled on the application layer. Regarding the callback idea, we think this is not what Rob Pike intended for this language 😅 I'm closing this issue, feel free to re-open. Thank you for your suggestion, keep them coming 👍