Hey Team! :wave:
SST looks like a fantastic produ...
# generale
elliotforbes
10/25/2021, 5:47 PMHey Team! đź‘‹
SST looks like a fantastic product that solves, I’m looking at doing a Serverless-Stack course on my website https://tutorialedge.net and just wanted to ask if there are any features you think may be deprecated / any breaking changes I should be aware of coming up that I may want to watch out for when recording the videos.
t
thdxr
10/25/2021, 5:50 PMCool! Are you doing something Go specific?
e
elliotforbes
10/25/2021, 5:51 PMYup! I may eventually venture back into Nodejs/TypeScript but keeping my course topics quite narrow for now.
elliotforbes
10/25/2021, 5:51 PMAny reference repositories featuring a more fully-fledged Go app would be very helpful!
elliotforbes
10/25/2021, 5:53 PMI have to say, the live dev environment is crazy good. đź‘Ś This solves one of my biggest gripes with the likes of
slst
thdxr
10/25/2021, 5:53 PMawesome to hear that and makes sense
thdxr
10/25/2021, 5:53 PMI don't think we have anything super complex using Go but I don't think there's anything particular you need to watch out for
e
elliotforbes
10/25/2021, 5:55 PMVery fair, I was curious to see if anyone has taken the default project structure given by sst and turned it into something more resembling a Go application’s structure.
t
thdxr
10/25/2021, 6:04 PMno but we'd love that
thdxr
10/25/2021, 6:05 PMMy go expertise stopped like 4 years ago so I'm not sure what is the right way to do things today
ö
Ă–mer Toraman
10/25/2021, 7:27 PMDamn I’ve been programming for max 2 years…
j
Joe Kendal
10/26/2021, 2:19 PM@elliotforbes Since we are talking about lambdas, you rarely need more than a few files (main.go, main_test.go, types.go. go.mod, go.sum). Maybe a folder for test events stored in json. But that’s about it. No need for an application project structure. These should be nanoservices
Joe Kendal
10/26/2021, 2:20 PMOr are you talking about using the Go bindings from the JSII translation? If so, I would advise against it.
e
elliotforbes
10/26/2021, 2:23 PMI would tend to disagree here. I always tend to go for a layered approach when it comes to building any service in Go.
You want your business logic to be written independently of your transport layer/storage layer logic.
It makes it far easier to do things like unit testing around your more complex business logic. Having it all tightly-coupled within single files just sounds like a nightmare to me if I was developing production-ready services.
j
Joe Kendal
10/26/2021, 2:26 PM@elliotforbes I would tend to disagree here. When you are building a highly decoupled, event-driven system, you are likely to only need a dynamodb putitem request. That then triggers another lambda which puts it onto EventBridge, that then triggers a StepFunction which fires something into a SQS for another lambda to do something with. Etc.
Joe Kendal
10/26/2021, 2:28 PMIt’s gotten to the point where AWS have said here’s direct SDK integration inside your StepFunctions because it’s pointless making a bunch of lambdas that just do one thing, i.e. call another AWS service
Joe Kendal
10/26/2021, 2:29 PMIf you are building a serverless, cloud-native system you are unlikely to need more than a database write in each lambda
e
elliotforbes
10/26/2021, 2:44 PMIt ultimately depends on your needs. I can see myself needing some fairly complex business knowledge and validation needing to be done within the lambda itself.
This shouldn’t live within a single function/module etc. I personally value splitting this out and being able to unit test use cases incredibly easily and mocking back the responses from dependencies so that I have the most possible confidence in my system.
j
Joe Kendal
10/26/2021, 2:53 PMHaving confidence in your system doesn’t have anything to do with the amount of logic inside each lambda. I think my architecture is reliant on robust AWS services and just joining them together with event triggers.
Joe Kendal
10/26/2021, 2:55 PMThe difficulty is not unit testing, but designing fault-tolerant systems where there are distributed transactions.
Joe Kendal
10/26/2021, 2:58 PMI always write full unit coverage even when it is just mocking a dynamodb operation. Because golang is hard to debug once deployed.
Joe Kendal
10/26/2021, 3:00 PMThis is really just nanoservices as opposed to microservices. The lambda just does one or two database requests and returns the response. So it can fit in under 100 lines in main.go and then full test coverage in main_test.go with mocks and table tests against json stored events
e
elliotforbes
10/26/2021, 3:09 PMYup, if it is a nanoservice then yeah, it’s fine to keep it within the one file. I’m more trying to approach this design from the point of “I want to build a microservice which lives on lambda”
The example I’ll be sort of taking is similar to how I’ve structured a previous course - https://github.com/TutorialEdge/go-rest-api-course/blob/master/internal/comment/comment.go
elliotforbes
10/26/2021, 3:12 PMThis does make me think I need to include something in my course which does highlight the advantages of keeping it nice and light if you are building true nanoservices like you have said.
j
Joe Kendal
10/26/2021, 3:29 PMYou write very clean code but I’m not sure what the future of this industry holds for RESTful APIs and synchronous microservices. I find myself embracing GraphQL for external APIs and events for internal asynchronous communication. All while using off-the-shelf serverless components. Less code, predictable APIs, performant, scalable.
e
elliotforbes
10/26/2021, 3:31 PMGraphQL is something I absolutely want to explore further. It just makes soo much more sense for frontends to define the exact data they need to fetch to populate views.
4 Views