Created an Example HTTP Function

[aneeshsharma]

Created a basic HTTP function that returns a message when called. We can build the backend on top of this from hereon. There is one thing that needs to be noted - the go build had to be done to output a static binary because when compiling normally, there is a glibc version mismatch. I haven't looked into how to fix this issue yet but it might not be necessary to fix and we can simply use the static build as the deployment.

[daltonfury42]

I was trying to look for a good folder structure and found this project: https://github.com/koltyakov/az-fun-go-sp

Can you check if this is possible?

Idea is that all things related to AzureFunctions should go to AzureFunctions, and outside of it, there should be minimal references to it. Say, tomorrow if we decide to host on AWS Lambda, it should hopefully require us to create another folder and add AWS plumbing there.

[maaverik]

Just to clarify, is the high-level plan to port all the logic from Java as-is and replace the current AWS setup with Azure serverless?

[aneeshsharma]

@daltonfury42 I will look into the folder structure.
Will update you soon.

[daltonfury42]

Just to clarify, is the high-level plan to port all the logic from Java as-is and replace the current AWS setup with Azure serverless?

Yes, move the entire backend from Java/Postgres to Serverless/MongoDB.

We will try to keep the business logic independent of mongo and azure.

[maaverik]

@daltonfury42 I will look into the folder structure. Will update you soon.

A slightly different take on the folder structure. This seems to be something a lot of people agree on based on the stars. Following it strictly seems too much, but I feel like using this as a guideline is a good idea since a lot of routing, CI scripts and DB logic will come in later. Adding a go.mod file is also a standard I believe for dependency management.

[daltonfury42]

This is a really good find. I missed these because I was googling for “serverless golang project folder structures”. I will be back home in a few hours and will study the repo more. What are your thoughts? My initial thoughts: 1. Let’s keep azure function specific stuff somewhere? 2. Shall we go with /internal and no /pkg for simplicity? Or should we go other way around? 3. /cmd we should have for our main.go. 4. Is it okay to keep the app name as “queue”? Then it will be /cmd/queue/main.go /internal/queue/.. etc

…

On Sat, 20 Nov 2021 at 2:58 PM, Nithin ***@***.***> wrote: @daltonfury42 <https://github.com/daltonfury42> I will look into the folder structure. Will update you soon. A slightly different take on the folder structure. This <https://github.com/golang-standards/project-layout> seems to be something a lot of people agree on based on the stars. Following it strictly seems too much, but I feel like using this as a guideline is a good idea since a lot of routing, CI scripts and DB logic will come in later. Adding a go.mod <https://go.dev/blog/using-go-modules> file is also a standard I believe for dependency management. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACV4EOHNGZQDLCWXFIS36U3UM5S43ANCNFSM5IL2SHTQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[aneeshsharma]

For Azure Functions, the structure has to be like -

| /MyQueueFunction
|   function.json
|
| host.json
| local.settings.json
| handler.exe

Ref: https://docs.microsoft.com/en-us/azure/azure-functions/functions-custom-handlers#application-structure

So, we can have this inside of AzureFunction/

The source for the handler can be inside AzureFunction/internal

So it can look like

| /MyQueueFunction
|   function.json
| /internal/handler/
|   main.go
|   token.go
| host.json
| local.settings.json
| handler.exe

The host.json takes the path to the executable which is our custom handler. So, the source doesn't necessarily have to be together with the Azure Functions configuration files (just the executable is required). I think it is also possible to have the go application just be a normal HTTP server application and then when we build the application, we can simply place all the configuration files and the handler executable inside a single directory.

This can make sure we are not just limited to azure functions and if needed it would be possible to deploy the application as a standalone executable or as a container.

So, finally it would be like

/internal/handler
    main.go
    token.go
/build
/AzureFunction
    /MyQueueFunciton
        function.json
    host.json
    .
    .
Makefile
go.mod
.
.

[daltonfury42]

This looks good. Minor modification, will this work:

1. Move main.go out of internal, other go devs might be more used to this.
2. Have a mux.go, it will be nice to have all routes defined in one place.

/internal
    /handler
        mux.go
        createqueue.go
        createtoken.go
        ...
    /persistance (storage layer, will come later)
    /service (for business logic, will come later)
/cmd
    main.go
/build (we can remove if this need not be in git)
/AzureFunction
    /CreateQueueFunction
        function.json
    /CreateTokenFunction
        function.json
    ...
    host.json
    .
    .
Makefile
go.mod
.
.

[aneeshsharma]

I've reorganized the files a bit to reflect the structure we decided. I've yet to move the function logic itself to /internal. So, right now everything is in /cmd/handler/main.go.

• Added a Makefile to build the project
• Currently I pass CGO_ENABLED=0 along with linker flags to compile the binary as static
• make would also zip the contents of /AzureFunctions (and output it to /build)
• This zip can be used to deploy the function

CGO_ENABLED=0 disables CGO. That along with -static linker flag are needed to compile a static bianry. I am not sure why CGO_ENABLED is important. Shouldn't passing the -static flag itself link all libraries dependent on C anyways? It still uses dynamic C libraries until I set CGO_ENABLED=0.

Reason I want to compile as static is because when I deploy the dynamic binary, there is a version mismatch for glibc on Azure Functions.

I am still working on the deployment which seems to be broken from VS Code Azure tools since I moved the Azure Function files. Installing Azure CLI tools was taking a lot of time so I will try with that tomorrow again.

[daltonfury42]

We can merge this PR as is, and the pending items can be done a follow up PR.

[daltonfury42]

@maaverik Aneesh is added as a collaborator, so will be able to merge his PRs.