boltless.me
targeting
master
from
sl/uvpzuszrulvq
Obviously file naming of appview/web/handler/*.go files are directly against to go convention. Though I think flattening all handler files can significantly reduce the effort involved in file naming and structuring. We are already grouping core services by domains, and doing same for web handers is just over-complicating.
Signed-off-by: Seongmin Lee git@boltless.me
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : services
```
Each handlers are pure by receiving all required dependencies as
parameters. Typically we should not pass base dependencies like `db`,
but that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : services
```
Each handlers are pure by receiving all required dependencies as
parameters. Typically we should not pass base dependencies like `db`,
but that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : services
```
Each handlers are pure by receiving all required dependencies as
parameters. Typically we should not pass base dependencies like `db`,
but that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
Obviously file naming of appview/web/handler/*.go files are directly
against to go convention. Though I think flattening all handler files
can significantly reduce the effort involved in file naming and
structuring. We are already grouping core services by domains, and doing
same for web handers is just over-complicating.
```
- appview/web/routes.go : define all web page routes
- appview/web/middleware.go : define middlewares related to web routes
- appview/web/handler/*.go : http handlers, named as path pattern
- appview/service/* : services
```
Each handlers are pure by receiving all required dependencies as
parameters. Typically we should not pass base dependencies like `db`,
but that's how it works for now.
Now we can test:
- http handlers with mocked services/renderer
- internal service logic without http handlers
Signed-off-by: Seongmin Lee <git@boltless.me>
tangled.org