Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I want to build an API based application using GO and MongoDB. I'm from Asp.net MVC background. Probably if I make an architecture with MVC web application things to be consider are
Separation of concerns(SoC)
DataModel
BusinessEntities
BusinessServices
Controllers
Dependeny Injection and Unity of Work
Unit Testing
MoQ or nUnit
Integration with UI frameworks
Angularjs or others
RESTful urls that enables SEO
Below architecture could be a solution for my need in MVC based appications
There are resources around the web to build Asp.Net or Java based applications, but I have not find solution to Golang application architecture.
Yes GO is different to C# or Java, but still there are Structs, Interfaces to create reusable code and a generic application architecture.
Consider above points in mind, how we can make a clean and reusable project structure in GO applications and a generic repositories for DB(Mongodb) transactions. Any web resources also a great point to start.
It depends on your own style and rules, in my company, we develop our projects this way:
Configuration is determined by environment variables, so we have a company/envs/project.sh file which has to be evaluated before service (outside the project in the image).
We add a zscripts folder that contains all extra scripts, like adding users or publishing a post. Intended to be used only for debug proposes.
Data models (entities) are in a package called project/models.
All controllers and views (HTML templates) are categorized into "apps" or "modules". We use the REST path as main group delimiter, so path /dogs goes to package project/apps/dogs and /cats to project/apps/cats.
Managers are in their separated package at project's root project/manager.
Static files (.css, .png, .js, etc.) are located at project/static/[app/]. Sometimes is required to have the optional [app/] folder, but it only happens when two apps have dashboards or conflicting file names. Most of cases you won't need to use [app/] for static resources.
Managers
We call a manager, a package that contains pure functions which helps apps to perform its task, for example, databases, cache, S3 storage, etc. We initialize each manager calling package.Startup() before we start to listen, and finalize calling package.Finalize() when program is interrupted.
An example of a manager could be project/cache/cache.go:
type Config struct {
RedisURL string `envconfig:"redis_url"`
}
var config Config
var client *redis.Client
func Startup(c Config) error {
config = c
client, err := redis.Dial(c.RedisURL)
return err
}
func Set(k,v string) error {
return client.Set(k, v)
}
in main.go (or your_thing_test.go):
var spec cache.Config
envconfig.Process("project", &spec)
cache.Startup(spec)
And in a app (or module):
func SetCacheHandler(_ http.ResponseWriter, _ *http.Request){
cache.Set("this", "rocks")
}
Modules
A module is a container of views and controllers that are isolated from other modules, using our configuration I would recommend to not create dependencies between modules. Modules are also called apps.
Each module configures its routes using a router, sub-router or what your framework provides, for example (file project/apps/dogs/configure.go):
func Configure(e *echo.Echo) {
e.Get("/dogs", List)
}
Then, all handlers live in project/apps/dogs/handlers.go:
// List outputs a dog list of all stored specimen.
func List(c *echo.Context) error {
// Note the use of models.Xyz
var res := make([]models.Dog, 0) // A little trick to not return nil.
err := store.FindAll("dogs", nil, &res) // Call manager to find all dogs.
// handle error ...
return c.JSON(200, res) // Output the dogs.
}
Finally you configure the app in main (or in a test):
e := echo.New()
dogs.Configure(e)
// more apps
e.Run(":8080")
Note: for views, you can add them to project/apps/<name>/views folder and configure them the using the same function.
Other
Sometimes we also add a project/constants and a project/utils package.
Here is what it looks like:
Note that in above sample, templates are separated from apps, thats because its a placeholder, directory is empty.
Hope it was useful. Greetings from México :D.
I've also struggled about how to structure my Go web APIs in the past and don't know any web resources that tell you exactly how to write a Go web API.
What I did was just check out other projects on Github and try out how they structured their code, for example, the Docker repo has very idomatic Go code on it's API.
Also, Beego is a RESTful framework that generates the project structure for you in a MVC way and according to their docs, it can also be used for APIs.
I've been building a web APIs in golang for a little while now.
You'll have to do some research but I can give you some starting points:
Building Web Apps with Go -- ebook
github.com/julienschmidt/httprouter -- for routing addresses
github.com/unrolled/render/ -- for rendering various forms of responses(JSON, HTML, etc..)
github.com/dgrijalva/jwt-go -- JSON Web Tokens
www.gorillatoolkit.org/pkg/sessions -- Session Management
And for reference on how some things work together in the end:
Go Web API Repo -- personal project
1. Separation of concerns (SoC)
I haven't worked with SoC directly, but I have my own pattern. You can adapt to whatever pattern (MVC, your own, etc.).
In my code, I separate my code into different packages:
myprojectname (package main) — Holds the very basic setup and configuration/project consts
* handlers (package handlers) — Holds the code that does the raw HTTP work
* models (package models) — Holds the models
* apis (NOT a package)
- redis (package redis) — Holds the code that wraps a `sync.Pool`
- twilio (package twilio) — Example of layer to deal with external API
Notes:
In each package other than main, I have a Setup() function (with relevant arguments) that is called by the main package.
For the packages under the apis folder, they are often just to initialize external Go libraries. You also can directly import existing libraries into the handlers/models without an apis package.
I setup my mux as an exported global in the handlers package like this...
Router := mux.NewRouter()
...and then create a file for each URL (different methods with the same URL are in the same file). In each file, I use Go's init() function, which is ran after global variables are initialized (so it's safe to use the router) but before main() is ran (so it's safe for main to assume everything has been setup). The great thing about init() is that you can have as many of those methods as you want in a single package, so they automatically get ran when the package is imported.
Main then imports myprojectname/handlers and then serves the handlers.Router in main.
2. Dependency Injection and Unity of Work
I haven't worked with Unity of Work, so I have no idea of possible Go implementations.
For DI, I build an interface that both the real object and the mock objects will implement.
In the package, I add this to the root:
var DatabaseController DatabaseControllerInterface = DefaultController
Then, the first line of each test I can change DatabaseController to whatever that test needs. When not testing, the unit tests should not be ran, and it defaults to DefaultController.
3. Unit Testing
Go provides a built in testing with the go test package command. You can use go test --cover to also emit a coverage percent. You can even have coverage displayed in your browser, highlighting the parts that are/aren't covered.
I use the testify/assert package to help me with testing where the standard library falls short:
// something_test.go
//
// The _test signifies it should only be compiled into a test
// Name the file whatever you want, but if it's testing code
// in a single file, I like to do filename_test.go.
package main
import (
"testing"
"github.com/stretchr/testify/assert"
)
func TestMath(t *testing.T) {
assert.Equal(t, 3+1, 4)
}
4. Integration with UI frameworks
I haven't seen any for Angular. Although I haven't used it, Go has a good template engine built into the standard lib.
5. RESTful URLs that enables SEO
Again, I can't help you here. It's up to you: send proper status codes (don't send a 200 with a 404 page as you'll get docked for duplicate pages), don't duplicate pages (pay attention to google.com/something vs google.com/something/; hopefully your framework will not mess this up), don't try to trick the search engine, and so on.
To my mind Go webapp project folder on production server can looks like on your picture just much simpler. Nothing special in assets structure - Static, Templates, Content, Styles, Img, JSlibs, DBscripts etc. usual folders. Nothing special in WebAPI - as usual you design which URI will respond required functionality and route requests to handlers accordingly. Some specifics - many gophers don't believe in MVC architecture, it's up to you surely. And you deploy one staticaly linked executable without dependencies. In your development environment you structure yours and imported/vendored sorce files in $GOPATH as in stdlib done but deploy only one executable in production environment, sure with static assets needed. You can see how to orginize Go source packages just in stdlib. Having just one executable what would you structure on production?
Related
I want to build a web page where I separate Database, Backend and Frontend and make then communicate via REST. I got quite confused about how to structure the project(s). As I read, there are the following approaches:
Make different projects: one for the frontend (let's say Angular) and one for the Backend (Spring) including the database connection. These are completely separated from each other and different IDE's might be used.
Build it in one big project but still use REST for communication (see picture below).
Now what I would like to know is what the difference between these two approaches is? I do not know (and do not ask) which one is the better one, but I cannot even make out reasons or effects to pick one above or below the other one.
This is really question about personal preference, but you have them be in completely different projects and at the same time you can put your JS bundles (from ng build) inside of the resources/static folder (of the Spring app) and it'll work perfectly, assuming you want to run them on the same server.
You can set a proxy config to make it easier like:
{
"/api": {
"target": "http://localhost:8080",
"secure": false
}
}
This way whenever you do a rest call with something like Angulars HttpClient, as long as you put /api in front of the url it'll call your spring backend.
Example:
public fetchResource(id: number): Observable<Resource> {
return this.http.get(`/api/resources/${id}`);
}
I prefer to have my client and api in different projects.
Whenever you want to add the JS bundles to your resources/static folder, you can just create an NPM script to do it for you in package.json.
I'm looking for recommendations on how to best share code between multiple Visual Studio projects. I'm struggling with a fundamental topic and trying to get some ideas to get over it.
My solution has:
Several web app projects
Several standalone process projects, eg Windows Services and/or console apps and/or Azure WebJobs
An example of functionality which is common to all projects is the need to call some common web service, or the need to read and write from Amazon S3, for example.
Where I struggle is this: Obviously the code that implements the common functionality should be broken out on its own, for example in a separate class library project. To talk to S3 for example, the code needs to know my Amazon credentials, S3 endpoints, etc. - all these things would normally be stored in app configuration files. But I don't like the idea of putting config files in class library projects because it binds a particular implementation to them. But in order to not do that, I have to pass in this information from the calling project. So for example the web app's web.config and the console app's app.config files contain this connection information. When calling the S3 code, I would assumingly pass this config info into the shared code.
However, this seems yucky* to me and I'm not sure why. It still feels to me like I'm "binding" the S3 code (for example) to a particular config method, if that makes sense. I'm not sure if my feeling is a mis-formed bias.
*For example, I may have an arbitrary amount of configuration data that would have to be passed in:
Connection strings
Credentials for web services
API endpoints
Arbitrary data from my app's config settings (which some of the callers will need, but others won't, so lots of times the data will just be useless yet I have to do the work of passing something in)
So every time I added a config variable in my main app, I'd have to modify the constructor of the common code. Things would be in constant motion.
Can you give me suggestions on this?
I like to use Configuration objects as parameters, that way the signature never changes, even if you add/remove properties. For instance....
public class AmazonConfigSettings {
public string AWSkey { get; set; }
public string ApiEndpoint { get; set; }
......
}
Your signature could then always look like:
public MySharedClass(AmazonConfigSettings config) { .... }
Even if (when) Amazon overhauls their webservice settings completely.
I am trying to use a shared controller from a module in my app, but I'm not really sure how to do it. Here's what I want to do:
I have two revel apps, a frontend and backend app. The frontend app is used to show the user-facing site, and the backend app is for admin stuffs.
I created a special controller to connect to database as per the booking sample.
I want both the frontend and backend app to use the same controller, to minimize redundancy.
From the sample, when you want to have one controller database, it roughly translate to this:
type DBController {
*revel.Controller
}
type App {
DBController
}
This works when I want to have only 1 app, but when I want to share the controller to another app, I can't import DBController to the app.
Things I've Tried
I tried moving DBController to its own package, and then importing that and inherit from it directly:
// in db.go
package controllers
// import and stuffs
type DBController {
*revel.Controller
}
// in app.go
package controllers
import (
dbc "site.com/modules/controllers"
)
type App struct {
dbc.DBController
// *dbc.DBController
}
This gives me a panic error stating that the route is not found:
panic: Route validation error (in /app/path/routes:7):
revel/controller: failed to find controller App
in both inheriting with and without pointer.
I've also tried Revel's module, with the same code, but different directory and importing via config:
// app.conf
modules.dbcontroller=site.com/modules/dbcontroller
And then in app.go:
type App struct {
DBController
}
But it still didn't work with the same error as before. I'm pretty convinced that the right route is by using module, since the documentation said (emphasis mine):
Modules are packages that can be plugged into an application. They allow sharing of controllers, views, assets, and other code between multiple Revel applications or from third-party sources.
A module should have the same layout as a Revel application’s layout. The “hosting” application will merge it in as follows:
Any templates in module/app/views will be added to the Template Loader search path
Any controllers in module/app/controllers will be treated as if they were in your application.
etc..
But I'm not sure how I can share and derive my controller from here.
TL; DR
How do I share controller in Revel so that I can inherit a controller from other module, roughly like:
import dbc "site.com/modules/dbcontroller"
type App struct {
dbc.DBController
}
so that DBController can be used with several revel apps? Thank you very much.
I am not an authority, but I will make a few observations that might help even though I do not have a complete answer for you.
The first thing about your question that struck me is the use of the term "inherit" -- Go does not support inheritance. It does support embedding. I might have written the question subject as "Reuse controller from module in Revel framework.
Second, I wonder if you are trying to reuse a Revel module between two separate Revel applications or if you are trying to reuse code from a module in two separate parts of one Revel application that just happens to have a front end and a back end. A quick read of the reveal framework makes me think modules were designed for the former, not the latter.
Third, I wonder if perhaps you are confusing files with packages. It was not obvious to me when learning Go that one package can span multiple files.. if the same declaration of "package controller" exists in two files such as db.go and app.go, they are still in the same package.
I'm currently following the Laravel Package documentation, which uses the workbench tool to create a standard package tree consisting of controller, config, views, etc. folders. Basically, most folders you would get in a standard Laravel app tree.
However, I had a couple of questions:
Why is the models folder absent here? (though the same goes for tests and commands)
Should I just create the folder myself and add it to the composer.json autoload classmap?
What classes should live inside src/<Namespace>/<PackageName>? I have noticed that a ServiceProvider is automatically created here, but I can imagine most other files just existing in the standard package directories.
Wockbench represents just a tool for creating other tools, that is triggered through CLI. Workbench is very abstract concept.
Model folder is absent simply because you don't need model in every new package. For example, if you are creating middleware package or you own filter package.
Every new class can be added to package dependent on its purpose and responsibility. It can be done in more then one way.
Classes that are general enough to go into every package are:
Package Service Provider
Facade
Basic Class
But it is not a black box. Consider for example request class - it is bound very early in the application life cycle, so no provider is needed.
I have a small web application written in Go. It is created a base for a larger system and I would like it to be extendable where components can be added/removed without needing this base to be modified in any way.
The structure is currently:
App
Modules
Core
... Core Files Here ...
app.go
main.go
app.go will contain a routing method which should take a web request and based on the request path know which module is responsible for handling the request. Each module/component having its on controller.
Each component will have its own package name so i think this is going to be impossible since go forces an explicit import.
For example i may add a new module/component called say blog such as:
App
Modules
Core
... Core Files Here ...
controller.go
Blog
... Blog Files Here ...
controller.go
app.go
main.go
There are several ways to achieve your goal. Since Go does not support dynamically loaded libraries at the moment, you need to probably recompile your application whenever you add/remove any components. The simplest way therefore would be a yourapp/core package with the following:
an Application type with an ServeHTTP method that acts as your main application
a Component interface that all your components have to implement. Your might want include a BaseUrl() string and a ServeHTTP method there.
a Register method to your Application type, that can be used to add new components to your app.
Your components can then be implemented in separate packages (e.g. yourapp/blog) and they will probably depend on your yourapp/core package.
The only thing that still needs to be "user-editable" is the main.go file, which might look like this:
func main() {
app := core.NewApplication()
app.Register(blog.Blog{
Title: "My Personal Blog",
})
app.Register(...)
app.Run()
}
Another approach might be to define an RPC interface for your components (which might include functions like RegisterComponent, UnregisterComponent and a GetGlobalConfig).
Then, you can run those components in separate processes which has the advantage that you can start/stop/reload those components dynamically and they can not break your main app. Take a look at the net/rpc package and maybe even httputil.NewSingleHostReverseProxy if you want to use this approach instead.