draft: appview: service layer #800

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/* : domain-level services
```

Each handlers are pure by receiving all required dependencies as
parameters. Ideally 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/* : domain-level services
```

Each handlers are pure by receiving all required dependencies as
parameters. Ideally 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/* : domain-level services
```

Each handlers are pure by receiving all required dependencies as
parameters. Ideally 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/* : domain-level services
```

Each handlers are pure by receiving all required dependencies as
parameters. Ideally 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/* : domain-level services
```

Each handlers are pure by receiving all required dependencies as
parameters. Ideally 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/* : domain-level services
```

Each handlers are pure by receiving all required dependencies as
parameters. Ideally 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>

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.

Signed-off-by: Seongmin Lee <git@boltless.me>