micro

README

Micro

Production-ready template for Go + React / Redux microservice applications. Sample website running micro: https://www.davidado.com/

Description

Micro is a production-ready microservices template.

/cmd is the entrypoint for each service so you can run go run cmd/blog/main.go and go run cmd/user/main.go during development.

/pkg contains all importable packages:

• /blog blog service
• /clean strips user-submitted content of XSS vulnerabilities
• /conn struct containing database and cache connection clients
• /contextkey keys for use with context
• /cookie cookie helper
• /db database and query helper
• /env .env configuration loader
• /errutil error helper
• /fmtdate date helper
• /hash argon2 hash helper
• /logger custom error logger
• /msg sends json messages to the end user
• /onesignal onesignal integration for push messaging
• /paginate pagination helper
• /token JWT helper
• /user user service
• /useragent user-agent helper
• /validate struct validator
• /visitor creates and contains details about a visitor
• /words word count and word censor

/web contains frontend code like React components and public files.

Installation

Development

Copy docker-compose-sample.yml to docker-compose.yml and configure settings according to your environment then run docker-compose up -d.

Production

Refer to docker-swarm-init-deploy-sample.sh for the initial server setup and docker-swarm-deploy-sample.sh for regular deployment.

Edge Server (CDN) Caching

Many API calls are .json requests such as /api/v1/blog/1/blog_1_20190911180259.json to enable caching for large text data. You can configure your server to set a long max-age header for .json responses which tells a user's browser to cache that post for future visits. Better yet, you can place your application behind a reverse proxy like Cloudflare and set a Page Rule like www.yoursite.com/*.json => Cache Level: Cache Everything and Edge Cache TTL: a month so that all requests for that resource are delivered by their CDN. Doing this for one of my popular applications reduced my cloud egress bandwidth costs by 60%.

Addendum

I went the microservices route primarily because in my current monoliths, database schema changes and large updates to big tables (> 50 GB) cause slave lag that affects all other unrelated services. Separating domains into their own databases and codebases was a way to reduce side effects to other services so that a disruption in one does not affect the other (i.e. if the user service goes down, you can still view the blog posts even if you won't see the author).