<p>Hi there, </p>
<p>I’ve been <strong>trying</strong> out Go on AWS Lambda using Apex and am currently struggling to figure out the best way to structure my application. Even though my application is very small, I am trying to structure it in the same way a larger app would be structured (for learning purposes) and also in a way that is very testable. Currently, I have come up with a few solutions.</p>
<ol>
<li> Structure it like a normal web application in Go (with the route, controller and models packages). This is the easiest way and it also allows me to learn the quickest as there are many resources for this structure. However, this structure means that my entire codebase will be deployed onto each Lambda, which doesn’t really embrace the philosophy for serverless apps.</li>
<li> Structure it like a normal web application, but each function is its own “web app”. So each function will have its own controller and model. This encourages the highest separation but it makes things very complex. Also this is not keeping the code short and sweet.</li>
<li> Make a package for each data domain (accounts, announcements, blog) and split the code appropriately. This means that some Lambdas will share some unused code with each other but not all.</li>
</ol>
<p>TL;DR How do I structure an Apex serverless Go application?</p>
<hr/>**评论：**<br/><br/>itijara: <pre><p>I don't have experience structuring Go applications in Lambda, but I do for Java applications and I will say that much depends on your use case. </p>
<p>Are you using this to set up a JSON endpoint or webpage? If so, why use lambda. It is a long running process and should probably just be set up in an EC2 instance (maybe with Containers). If you just like the convenience of Lambda, you could put the entire thing in a single Lambda instance and not worry so much about architecture. </p>
<p>I think Lambda is most useful for event based data pipelines. e.g. a push notification system, converting a file to a PDF when it is uploaded to S3, chron job triggers, etc. Otherwise, the package system in Go should be good enough to handle the modularity you need to decouple various components.</p></pre>RavernKohDev: <pre><p>Might I know why a JSON endpoint is a long running process?</p></pre>itijara: <pre><p>It's not really, but the server should probably be continuously running so there is no latency.</p></pre>BraveNewCurrency: <pre><p>But that negates two of the benefits of Lambda:</p>
<ol>
<li>Cost (not paying when not in use)</li>
<li>Security (not worrying about the <a href="https://meltdownattack.com/" rel="nofollow">latest horrible new bug</a> with a cool logo that everybody else must stay up all night to patch.)</li>
</ol></pre>
