You're probably stuck creating a package layout.

As you know, the wrong package layout can lead to an umaintainable mess:

• Ripple effects

  Every change cascades into further changes. "Fingers crossed that we didn't forget anything" will be a common thought before deploying.

• Brittle tests

  Tests that mirror the logic of the code they're testing. Even refactoring will break tests.

• Unhappy teams

  All the firefighting will eventually lead to burned out developers. You'll find yourself or your colleagues venting after work: "this sucks, we should do a rewrite".

It is possible to structure packages well, you're just not sure how to do it yourself.

You've experienced yourself how the standard library and packages like the Gorilla Web Toolkit are structured. It is possible to structure things well and maintain them over years and years.

However, those are libraries... and you're building a web app.

Well, what if that didn't matter? What if you could use the same principles to create maintainable and composeable packages for your app?

You'd be able to iterate quickly on that backlog of tasks. Heck, you'd probably have the first integration test passing in an hour or two.

You know how to do it in other Languages or Frameworks. Why is Go so difficult?

Implicit interfaces have a big impact on code organization.

Organizing Go apps like Laravel, Django or Rails apps will lead to much copy-pasting, awkward names and overengineering. In Go an ebook or blog package is usually preferred over a models or data package.

But how do you combine such value oriented packages with the technical concerns of your typical web app?

• Dealing with incoming requests: Web forms, JSON requests or events.
• Formatting outgoing data and responses.
• Authenticating users.
• Storing state in database(s).
• Dealing with external services.
• Monitoring and logging.

All while keeping maintenance and testing in mind.

Value is the key to get moving again.

Just like the models package, those concerns can be split and organized according to the value they provide.

Ofcourse, this entirely depends on the kind of web app you're building.

For one app it might make sense to have an auth.User struct, for another it might work better for the auth package to accept a game.User instead.

But, with some guidance you can figure this out.

Q&A

Will this teach me how to build a web app from scratch?

No. This guide is intended to be read in a few hours, it can't help you build an entire app from scratch.

However, a well-documented production-ready example app will be available that applies the principles and tactics described in the guide. If you don't mind reading code (a good skill to practice regardless) it's suitable for self-study.

How much Go experience do I need?

It will help if you have gone through the typical http package related tutorials and attempted to build something. Preferably a web app.

Some of the issues in the guide might not fully "click" if you haven't ran into them (yet), but it never hurts to be aware.

How much web development experience do I need?

The guide won't go into the details of HTTP, SQL, Docker or other tech. It focuses on the Go side of things.

Other questions?

Contact me at w@willem.dev.