feat: add local dev support for Go scheduled functions

[karagulamos]

Summary

The PR is part of an ongoing effort to improve functions support for Go. In this specific case, we sprinkle the CLI with magic dust to enable the detection of scheduled functions in Go and improve the dev experience for anyone wishing to try this out locally.

With this update, users should now see the default message for locally run scheduled functions in their browser

You can find relevant code here.

NOTE: next_run is only present in request.Body if the Go function is scheduled.

[github-actions]

📊 Benchmark results

Comparing with 3df8f95

Package size: 380 MB

⬆️ 0.00% increase vs. 3df8f95

^  380 MB  380 MB  380 MB  380 MB  380 MB  380 MB  380 MB  380 MB  380 MB  380 MB  380 MB  380 MB  380 MB 
│   ┌──┐    ┌──┐    ┌──┐    ┌──┐    ┌──┐    ┌──┐    ┌──┐    ┌──┐    ┌──┐    ┌──┐    ┌──┐    ┌──┐    ┌──┐  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
│   |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |  |    |▒▒|  
└───┴──┴────┴──┴────┴──┴────┴──┴────┴──┴────┴──┴────┴──┴────┴──┴────┴──┴────┴──┴────┴──┴────┴──┴────┴──┴──>
    T-12    T-11    T-10    T-9     T-8     T-7     T-6     T-5     T-4     T-3     T-2     T-1      T    

Legend

• T-30 (3df8f95): 380 MB
• T-29 (6e47ae1): 380 MB
• T-28 (6ecc6ce): 380 MB
• T-27 (337b969): 380 MB
• T-26 (3d5ed50): 380 MB
• T-25 (acc9a65): 380 MB
• T-24 (44de2ad): 380 MB
• T-23 (42887e7): 380 MB
• T-22 (832b0ea): 380 MB
• T-21 (c89e191): 380 MB
• T-20 (836fad2): 380 MB
• T-19 (e01c624): 380 MB
• T-18 (a1aa28f): 380 MB
• T-17 (0f4f556): 380 MB
• T-16 (ecfd4b9): 380 MB
• T-15 (5e54994): 380 MB
• T-14 (9a77099): 380 MB
• T-13 (eb5c3b9): 380 MB
• T-12 (c99c9a5): 380 MB
• T-11 (f14434c): 380 MB
• T-10 (5036333): 380 MB
• T-9 (c8abe69): 380 MB
• T-8 (066841c): 380 MB
• T-7 (f87d9e6): 380 MB
• T-6 (88acdfd): 380 MB
• T-5 (03c34a4): 380 MB
• T-4 (3aa1fc6): 380 MB
• T-3 (e9c1789): 380 MB
• T-2 (fa32955): 380 MB
• T-1 (27366a4): 380 MB
• T (current commit): 380 MB

[eduardoboucas]

Thanks for picking this up!

You're doing a lot of work that is already handled elsewhere.

First of all, you're finding and parsing the config file, which you don't need to. If you look at the FunctionsRegistry class, you'll see that one of the parameters it receives is config. This is the config object fully parsed and normalised, ready for you to use.

Secondly, zip-it-and-ship-it is what should tell us the schedule information about a function, if it exists. It does this by merging the function configuration we pass to it (which we extract from config.functions) with any in-source config declarations, when applicable.

So one of the problems I'm seeing is that we're not passing that configuration object when we call listFunctions here. If you pass a config parameter with the value of this.config.functions, you'll see that any functions with a schedule defined in the config file will come back with the schedule property correctly populated. This handles all the parsing you're replicating in this PR.

Once that's in, I believe the only thing left to do is to pass that schedule property in the NetlifyFunction constructor here, and make NetlifyFunction set that property internally if it's passed in the constructor, as opposed to relying on the build step.

If any of this isn't clear, feel free to drop any questions here or ping me directly and we can pair. 🚀

[karagulamos]

If any of this isn't clear, feel free to drop any questions here or ping me directly and we can pair. 🚀

Super thanks for the feedback, and I should be able to handle the changes. However, considering this was my point of reference, I believe we no longer need to return the schedule from ZISI with this change and can remove it from the code. Any reason we shouldn't?

[mraerino]

doesn't zisi parse the in-code schedule configuration?

[eduardoboucas]

Let's think about how the schedule is declared and how it makes its way to us:

• In the TOML: We have access to this information upfront (i.e. before building a function), because we have an in-memory representation of the config. This is what we need to pass to zip-it-and-ship-it, as mentioned in feat: add local dev support for Go scheduled functions #4491 (review).

• In the code: We don't have access to this information until we build a function, so we need to get this data from zip-it-and-ship-it. If you remove this, only the TOML declarations will be considered. The data coming from zip-it-and-ship-it for Go functions will be redundant, since it's not possible for the function's build command to generate additional schedule data (because we don't support in-source declarations in Go). However, that's not true for JavaScript/TypeScript, so we need to make sure we consider data coming from both sources (i.e. config and ZISI), so the best way is to always pass the config to ZISI and use the value it returns as the single source of truth, because it will do the job of considering both sources.

Does that make sense?

[karagulamos]

Does that make sense?

Figured it out, but this makes a lot of sense, thanks.

[karagulamos]

This is resolved.

[eduardoboucas]

🚀

[eduardoboucas]

🚢 🚢 🚢