Go-app is a package to build progressive web apps with Go programming language and WebAssembly.

go-app

Circle CI Go build Go Report Card GitHub release pkg.go.dev docs Twitter URL

Go-app is a package for building progressive web apps (PWA) with the Go programming language (Golang) and WebAssembly (Wasm).

Shaping a UI is done by using a declarative syntax that creates and compose HTML elements only by using the Go programing language.

It uses Go HTTP standard model.

An app created with go-app can out of the box run in its own window, supports offline mode, and are SEO friendly.

Documentation

go-app documentation

Install

go-app requirements:

go mod init
go get -u github.com/maxence-charriere/go-app/v8/pkg/app

Declarative syntax

Go-app uses a declarative syntax so you can write reusable component-based UI elements just by using the Go programming language.

Here is a Hello World component that takes an input and displays its value in its title:

type hello struct {
	app.Compo

	name string
}

func (h *hello) Render() app.UI {
	return app.Div().Body(
		app.H1().Body(
			app.Text("Hello, "),
			app.If(h.name != "",
				app.Text(h.name),
			).Else(
				app.Text("World!"),
			),
		),
		app.P().Body(
			app.Input().
				Type("text").
				Value(h.name).
				Placeholder("What is your name?").
				AutoFocus(true).
				OnChange(h.ValueTo(&h.name)),
		),
	)
}

Standard HTTP

Apps created with go-app complies with Go standard HTTP package interfaces.

func main() {
    // Components routing:
	app.Route("/", &hello{})
	app.Route("/hello", &hello{})
	app.RunWhenOnBrowser()

    // HTTP routing:
	http.Handle("/", &app.Handler{
		Name:        "Hello",
		Description: "An Hello World! example",
	})

	if err := http.ListenAndServe(":8000", nil); err != nil {
		log.Fatal(err)
	}
}

Getting started

Read the Getting Started document.

Contributors

Code Contributors

This project exists thanks to all the people who contribute. [Contribute].

Financial Contributors

Become a financial contributor and help us sustain go-app development. [Contribute]

Individuals

Organizations

Support this project with your organization. Your logo will show up here with a link to your website. [Contribute]

Comments
  • Example crashing right away after go build or go run

    Example crashing right away after go build or go run

    I tried to just go build the example project then execute the binary, but it crashes right after it starts. The weird thing is if I use macpack to build it then it doesn't crash. I'm guessing the app wrapper provides data where the raw build does not.

    Go ENV

    GOARCH="amd64"
    GOBIN=""
    GOEXE=""
    GOHOSTARCH="amd64"
    GOHOSTOS="darwin"
    GOOS="darwin"
    GOPATH="/Users/euforic/go"
    GORACE=""
    GOROOT="/usr/local/Cellar/go/1.7.5/libexec"
    GOTOOLDIR="/usr/local/Cellar/go/1.7.5/libexec/pkg/tool/darwin_amd64"
    CC="clang"
    GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/3x/0rnfwj_x1jz2p0gzh_gg7_600000gn/T/go-build912724629=/tmp/go-build -gno-record-gcc-switches -fno-common"
    CXX="clang++"
    CGO_ENABLED="1"
    

    Crash Output

    INFO  2017/01/30 14:00:47 driver.go:31: driver *mac.Driver is loaded
    INFO  2017/01/30 14:00:47 component.go:62: main.Hello has been registered under the tag Hello
    INFO  2017/01/30 14:00:47 component.go:62: main.AppMainMenu has been registered under the tag AppMainMenu
    INFO  2017/01/30 14:00:47 component.go:62: main.WindowMenu has been registered under the tag WindowMenu
    fatal error: unexpected signal during runtime execution
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7fffb3c24b52]
    
    runtime stack:
    runtime.throw(0x41a1554, 0x2a)
    	/usr/local/Cellar/go/1.7.5/libexec/src/runtime/panic.go:566 +0x95
    runtime.sigpanic()
    	/usr/local/Cellar/go/1.7.5/libexec/src/runtime/sigpanic_unix.go:12 +0x2cc
    
    goroutine 1 [syscall, locked to thread]:
    runtime.cgocall(0x4141160, 0xc42004df20, 0x0)
    	/usr/local/Cellar/go/1.7.5/libexec/src/runtime/cgocall.go:131 +0x110 fp=0xc42004def0 sp=0xc42004deb0
    github.com/murlokswarm/mac._Cfunc_Driver_Run()
    	??:0 +0x41 fp=0xc42004df20 sp=0xc42004def0
    github.com/murlokswarm/mac.(*Driver).Run(0xc420010280)
    	/Users/euforic/go/src/github.com/murlokswarm/mac/driver.go:56 +0x14 fp=0xc42004df28 sp=0xc42004df20
    github.com/murlokswarm/app.Run()
    	/Users/euforic/go/src/github.com/murlokswarm/app/app.go:43 +0x35 fp=0xc42004df40 sp=0xc42004df28
    main.main()
    	/Users/euforic/go/src/github.com/blevein/play/examples/mac/hello/main.go:31 +0x30 fp=0xc42004df48 sp=0xc42004df40
    runtime.main()
    	/usr/local/Cellar/go/1.7.5/libexec/src/runtime/proc.go:183 +0x1f4 fp=0xc42004dfa0 sp=0xc42004df48
    runtime.goexit()
    	/usr/local/Cellar/go/1.7.5/libexec/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc42004dfa8 sp=0xc42004dfa0
    
    goroutine 17 [syscall, locked to thread]:
    runtime.goexit()
    	/usr/local/Cellar/go/1.7.5/libexec/src/runtime/asm_amd64.s:2086 +0x1
    
    goroutine 5 [chan receive]:
    github.com/murlokswarm/app.startUIScheduler()
    	/Users/euforic/go/src/github.com/murlokswarm/app/ui.go:11 +0x51
    created by github.com/murlokswarm/app.init.1
    	/Users/euforic/go/src/github.com/murlokswarm/app/ui.go:17 +0x35
    
  • v9 Testing/Feedback

    v9 Testing/Feedback

    Hello there,

    I know it is pretty close to the v8 release but I had been working on a new version that removes the need to call Compo.Update() to update what is displayed on the screen.

    Unfortunately, it brings some API changes and since some of you are using this package, I wanted to share that work with you and get some feedback before releasing the new version.

    Install

    go get -u -v github.com/maxence-charriere/go-app/v9@3653b5c
    

    Then replace your imports in your code

    What changed

    • No need to call Update anymore!
    • Compo.Defer() has been removed. Now all Dispatch()/Defer() are done from Context.Dispatch(func(Context))
    • Context.Dispatch(func()) is now Context.Dispatch(func(Context)), and UI elements are always checked before launching Component lifecycle event or HTML event handlers
    • Context has now a Defer(func(Context)) method that launches the given function after a component has been updated. It can be handy to perform action after the display is complete, like scrolling to a given location
    • Context has now an After() function that launches a function on the UI goroutine after the given time without blocking the UI
    • There is a new Component lifecycle event: OnUpdate(Context): it is launched only when a component gets updated by a parent, and should replace a scenario where a Compo.Defer() call was called in a Render() app.UI method
    • Context is now an interface. Fields are now methods:
      • Src => Src()
      • JSSrc => JSSrc()
      • AppUpdateAvailable => AppUpdateAvailable()
      • Page => Page()
    • Context has now a Context.Emit(func()) method that launches the given function and notifies parents to update their state. This should be used when implementing your own event handlers in your components, in order to properly update parent components that set a function to the event handler
    • Context has now method to encrypt and decrypt data
      • Encrypt(v interface{}) ([]byte, error)
      • Decrypt(crypted []byte, v interface{}) error
    • Context has now a method that returns device id: DeviceID() string
    • [EXPERIMENTAL] Changed the API for Stack()

    API design decisions

    • This release focuses mainly on getting the usage of the package more reactive
    • The API is designed to make unrecommended things difficult. A good example would be calling a Context.Dispatch() inside a Render() method
    • With the exception of Handler and JS-related things, everything that you might need is now available from Context. Still thinking about whether I should move Compo.ResizeContent() and Compo.ValueTo in Context though

    Please let me know what you think and where it makes things difficult to solve your problem. I will try to help you solve those and/or iterate to make things better.

    @pojntfx @beanpole135 @ZackaryWelch @mar1n3r0

    Thanks

  • Next: Windows

    Next: Windows

    Hello, some stuff are happening here. I'm writing changes that will bring better support for multi-platform dev. Would like to know what is the next driver you would like to be implement.

  • Recaptcha

    Recaptcha

    Hello. anyone know about getting recaptcha to properly work?

    I have it setup to prompt user with a captcha after they click register like so: https://streamable.com/4if31l

    However whenever the captcha submits the form it completely ignores my form submission handler:

    func (c *register) OnCaptchaComplete(ctx app.Context, e app.Event) {
    	e.PreventDefault()
    	print("Captcha complete")
    }
    

    here is the snippet for the element

    app.Div().Class("flex justify-center").Body(
    	app.Form().
    	ID("register-captcha-form").
    	OnSubmit(c.OnCaptchaComplete, nil).
    	Body(
    	&components.Captcha{Callback: "registerCaptchaCB"}),
    	),
    ),
    

    Is there a way to easily prevent the captcha from submitting normally and passing in the response and properly send to my handler with the recaptcha response so I can use the data to build a request to the api?

    I know I can just read the query value for the g-recaptcha-response but is there anyway I can prevent recaptcha from submitting a post / get request to the form action?

  • Support for push manager

    Support for push manager

    It would be nice to add subscription bootstrap into page.js (https://github.com/maxence-charriere/app/blob/c5fc1cb2b7861d05ca80284f2e38b1b7c46a69b7/internal/http/page.js)

    And callbacks to goapp.js

  • How to make wasm reactive?

    How to make wasm reactive?

    The way Go treats wasm as an application means it runs and exits. This is quite limiting compared to modern JS frameworks with their reactive APIs which allow real-time reactivity on external changes. Is this even possible with the current state of things? Maybe keeping dedicated channels open infinite? This would allow all kind of things from state management stores to webhooks to websockets etc.

    Go takes a different approach, Go treats this as an application, meaning that you start a Go runtime, it runs, then exits and you can’t interact with it. This, coincidentally, is the error message that you’re seeing, our Go application has completed and cleaned up.

    To me this feels more closer to the .NET Console Application than it does to a web application. A web application doesn’t really end, at least, not in the same manner as a process.

    And this leads us to a problem, if we want to be able to call stuff, but the runtime want to shut down, what do we do?

    https://www.aaron-powell.com/posts/2019-02-06-golang-wasm-3-interacting-with-js-from-go/

    Here is an example:

    I would like to connect the app to an external state management store and make it re-render on state changes. By the time the state changed the runtime has exited, hence unless there is a channel open to keep it alive it can't react to external events after exit.

  • Custom Handler

    Custom Handler

    It would be nice if app made it easier to work with a custom Handler. For cases like #501 , I could implement my own handler and have fine grained control.

  • TypeError: WebAssembly: Response has unsupported MIME type 'text/plain; charset=utf-8' expected 'application/wasm'

    TypeError: WebAssembly: Response has unsupported MIME type 'text/plain; charset=utf-8' expected 'application/wasm'

    Getting this error

    TypeError: WebAssembly: Response has unsupported MIME type 'text/plain; charset=utf-8' expected 'application/wasm'
    
    package ui
    
    import "github.com/maxence-charriere/go-app/v9/pkg/app"
    
    type Home struct {
    	app.Compo
    }
    
    func (h *Home) Render() app.UI {
    	return app.Html().Body(
    		app.Head().Body(
    			app.Meta().Name("charset").Content("utf-8"),
    		),
    		app.Body().Body(
    			app.H1().Text("Hello World"),
    		),
    	)
    
    }
    
    package cmd
    
    import (
    	"net/http"
    
    	"mypackagepath/ui"
    	"github.com/maxence-charriere/go-app/v9/pkg/app"
    	"github.com/spf13/cobra"
    )
    
    // uiCmd represents the ui command
    var uiCmd = &cobra.Command{
    	Use:   "ui",
    	Short: "",
    	RunE: func(cmd *cobra.Command, args []string) error {
    		app.Route("/", new(ui.Home))
    		app.RunWhenOnBrowser()
    		http.Handle("/", &app.Handler{
    			Author:       "A name",
    			Description:  "domain.tld is an URL shortener service",
    			LoadingLabel: "Yo! Wait up, it's loading...",
    			Name:         "Some Name",
    			Title:        "domain.tld - shorturl service",
    			Version:      "1",
    		})
    
    		return http.ListenAndServe(":7890", nil)
    	},
    }
    
    func init() {
    	rootCmd.AddCommand(uiCmd)
    }
    
  • State management

    State management

    Looking for some broad feedback here.

    I have explored further the idea of implementing component composition also known as slots as described here: https://github.com/maxence-charriere/go-app/issues/434.

    While it definitely works in terms of simply compiling the HTML string the complexity it introduced in maintaining state between the root component and children components brought some questions up.

    The simplicity of using Go structs as state management pattern is very appealing but at the same time easily shows its limitations once the app goes beyond the scope of one page - one component structure. Surely with this pattern we can communicate between pages with HTML5 API storage solutions as long as there is no sensitive data. But as long as we outgrow this pattern in-memory state management becomes inevitable.

    This was an issue which most of JS frontend frameworks faced in their early stages and it evolved in to separate global state management modules and tools like Vuex for example.

    Global state management solves all those problems when scaling from small to enterprise-like apps but comes at a cost with it's own caveats and extra stuff to think about and handle.

    What are your thoughts on this ?

    Do you think this will become a hot topic in the near future as the project evolves or it's beyond the scope of current usage requirements ?

    Do you see the same pattern applied or a different technique Go can make use of to make it possible to scale apps ?

  • Implements custom elements with xml namespaces (for SVG)

    Implements custom elements with xml namespaces (for SVG)

    I added namespaces to elements and added a method to create custom tags. The reason is, that I wrote an auto converter that can translate HTML to go-app declarative syntax. While experimenting with it, I found that SVG support was missing. But adding all of the SVG seems to be a lot of work. After making a simple variant for custom elements I realized that this will not work for SVG because those elements need to be in a special namespace. So I added namespace support.

    I think my implementation is quite nice. I added a test and documentation with an example of the usage:

    func SVG(w, h int) app.HTMLCustom {
    	return app.Custom("svg", false, app.SVG).
    		Attr("width", w).Attr("height", h)
    }
    
    func Circle(cx, cy, r int, stroke string, width int, fill string) app.HTMLCustom {
    	return app.Custom("circle", false, app.SVG).
    		Attr("cx", cx).
    		Attr("cy", cy).
    		Attr("r", r).
    		Attr("stroke", stroke).
    		Attr("stroke-width", width).
    		Attr("fill", fill)
    }
    
    func (c *Dynamic) Render() app.UI {
    	return SVG(100, 100).Body(
    		Circle(50, 50, 40, "black", 3, "red"),
    		app.Text("Sorry, your browser does not support inline SVG"),
    	)
    }
    

    Of course, it adds the "xmlns" field to every element. But I think this is better than having another interface for SVG.

    I am contemplating if there should be an "xmlns" method instead which sets the namespace for every element. That may be a better solution than adding the namespace to the Custom() method. Maybe I try that too and push a commit that uses this later on.

    EDIT: There is another implementation using an XMLNS() method on the elements instead of the many parameters to Custom(). See below!

  • v9.6.0

    v9.6.0

    Summary

    • Go requirement bumped to Go v1.18
    • Custom elements (Elem and ElemSelfClosing)
    • Prevent component update
    • Engine optimization that ensure a component update is done once per frame cycle
    • Customizable app-worker.js template
    • Some documentation tweak

    Fixes

    • fix #753
  • fix: remove infinite loop in replaceRoot

    fix: remove infinite loop in replaceRoot

    Hi @maxence-charriere

    I ran into infinite loop when tried implementing something like this:

    package main
    
    import (
    	"log"
    	"net/http"
    
    	"github.com/maxence-charriere/go-app/v9/pkg/app"
    )
    
    type compo struct {
    	app.Compo
    }
    
    func (c *compo) Render() app.UI {
    	return app.Div().Body(new(compoA))
    }
    
    type compoA struct {
    	app.Compo
    	isLoading bool
    }
    
    func (c *compoA) OnNav(app.Context) {
    	c.isLoading = true
    }
    
    func (c *compoA) Render() app.UI {
    	b := new(compoB)
    	b.IsLoading = c.isLoading
    	return b
    }
    
    type compoB struct {
    	app.Compo
    	IsLoading bool
    }
    
    func (c *compoB) Render() app.UI {
    	return app.If(c.IsLoading, app.Div().Text("is loading")).Else(app.A().Text("is not loading"))
    }
    
    func main() {
    	app.Route("/", new(compo))
    
    	app.RunWhenOnBrowser()
    
    	http.Handle("/", &app.Handler{
    		Name:        "Hello",
    		Description: "An Hello World! example",
    	})
    
    	if err := http.ListenAndServe(":8000", nil); err != nil {
    		log.Fatal(err)
    	}
    }
    
  • Documentation issue in go-app page

    Documentation issue in go-app page

    How do I compose a web page?

    Say I want to have a menu, some element in the html body and an html footer.

    I can't seem to wrap my head around composing components together to form a webpage.

    return app.Head().Body(&Menu{}).Div().Body(app.H1().Text("Welcome"))

    If a component can only render independent of other components, how do we put them together?

    tx

  • Component level action trigger global level handler

    Component level action trigger global level handler

    The actionDemo component is used for action handler test only.
    The problem is that both comp1 and comp2 value are changed when the "Inc" button of comp1 is clicked.

    package comp
    
    import (
    	"fmt"
    	"github.com/maxence-charriere/go-app/v9/pkg/app"
    )
    
    type (
    	actionDemo struct {
    		app.Compo
    	}
    
    	actionCompo struct {
    		app.Compo
    		FName string
    		value int
    	}
    )
    
    func (this *actionDemo) Render() app.UI {
    	return app.Div().
    		Body(
    			&actionCompo{
    				FName: "comp1",
    			},
    			&actionCompo{
    				FName: "comp2",
    			},
    		)
    }
    
    func (this *actionCompo) OnMount(ctx app.Context) {
    	ctx.Handle("value", func(context app.Context, action app.Action) {
    		this.value += action.Value.(int)
    	})
    }
    func (this *actionCompo) Render() app.UI {
    	return app.Div().
    		Body(
    			app.Span().Body(
    				app.Text(this.FName),
    				app.Text(": "),
    				app.Text(fmt.Sprintf("%d", this.value)),
    				app.Button().
    					Text("Inc").
    					OnClick(func(ctx app.Context, e app.Event) {
    						ctx.NewActionWithValue("value", 1)
    					}),
    				app.Button().
    					Text("Des").
    					OnClick(func(ctx app.Context, e app.Event) {
    						ctx.NewActionWithValue("value", -1)
    					}),
    			))
    }
    
  • Sanity check:  go-app as a generic decentralized app framework

    Sanity check: go-app as a generic decentralized app framework

    Hi All and Maxence,

    I'm thinking of using go-app as a layer in a decentralized app. By "decentralized app" I mean browser-side persistence, lateral communications between browsers, and so on -- more details below. I see that @oderwat and @mlctrez are apparently already playing with similar ideas: #789.

    Is this a reasonable use of go-app, given current capabilities and roadmap? As far as I can tell so far, the answer to this is "yes". But I have an entire group of people who will be following along and working with me on this effort, and so am checking in here first before we commit several weeks to a POC.

    Background

    I host a working group developing a collaboration platform for other groups and teams. This effort is a spinout from the Nation of Makers community, though not exclusive to nor an official effort of that organization; standard disclaimers apply. So far it's just me and a handful of other folks having weekly video calls to think this through.

    The platform is to be open-source, written in Go, though as I mention in a reddit post, I'm not finding many existing examples of Web3-style apps in Go -- most apps in this space appear to still be javascript, with a little Rust. My guess is that Go/WASM is still too new; the payload size may be a contributing factor.

    I believe go-app might be a good fit for filling this gap.

    Proposal

    If we were to use go-app, we would work with @maxence-charriere and everyone else here to discover and work out any issues that might be lurking with using go-app as a generic-enough framework for decentralized apps, including support of the wishlist items below. Go-app already supports most of this, or at least doesn't get in the way.

    Wishlist

    By "Web3-style" I don't mean necessarily defi-related. I do mean the following items, adapted from another reddit post:

    • decentralized to the extent that the app can be served from e.g. github pages and run client-side in WASM, likely using IndexedDB for persistence.
    • able to communicate with other nodes through multiple protocols e.g. websocket, webrtc, nats, etc.
    • able to run the same code "headless" in server-side nodes to provide additional persistence and relays between firewalled clients
    • SEO-friendly enough that googlers can find content rendered on server nodes
    • interoperable with a few javascript libraries (e.g. the tiptap editor)
      • likely a micro-frontend architecture style, with comms via the DOM
    • be future-proofed enough that we don't need to deal with breaking changes in the framework
      • go-app does appear to be using semver -- do I have that right? Have there been any hiccups with breaking changes at non-major release points?

    Thanks All,

    Steve

  • Feature request - cross origin setting for manifest link

    Feature request - cross origin setting for manifest link

    I have a use case where I would like to include credentials ( in my case cookies ) in the manifest request.

    See the gotchas section on this link https://web.dev/add-manifest/#link-manifest

    I've tested this small change locally and it resolves the issue.

    image

    I can submit a PR with the changes but would like some advice:

    • How to configure the setting on and off? Environment variable, app.Handler field, or other?
    • Are there other links ( icon, apple-touch-icon ) that would also need to be considered?
    • Have I missed an obvious way to achieve this without code changes?
🚀‏‏‎ ‎‏‏‎‏‏‎‎‎‎‎‎Copper is a Go toolkit complete with everything you need to build web apps.

Copper Copper is a Go toolkit complete with everything you need to build web apps. It focuses on developer productivity and makes building web apps in

Jan 7, 2023
Flamingo Framework and Core Library. Flamingo is a go based framework for pluggable web projects. It is used to build scalable and maintainable (web)applications.
Flamingo Framework and Core Library. Flamingo is a go based framework for pluggable web projects. It is used to build scalable and maintainable (web)applications.

Flamingo Framework Flamingo is a web framework based on Go. It is designed to build pluggable and maintainable web projects. It is production ready, f

Jan 5, 2023
beego is an open-source, high-performance web framework for the Go programming language.
beego is an open-source, high-performance web framework for the Go programming language.

Beego Beego is used for rapid development of enterprise application in Go, including RESTful APIs, web apps and backend services. It is inspired by To

Jan 1, 2023
beego is an open-source, high-performance web framework for the Go programming language.
beego is an open-source, high-performance web framework for the Go programming language.

Beego Beego is used for rapid development of enterprise application in Go, including RESTful APIs, web apps and backend services. It is inspired by To

Jan 8, 2023
letgo is an open-source, high-performance web framework for the Go programming language.

high-performance Lightweight web framework for the Go programming language. golang web framework,高可用golang web框架,go语言 web框架 ,go web

Sep 23, 2022
A web app built using Go Buffalo web framework

Welcome to Buffalo Thank you for choosing Buffalo for your web development needs. Database Setup It looks like you chose to set up your application us

Feb 7, 2022
Web framework for creating apps using Go in Google AppEngine

Welcome to app.go v3.0 app.go is a simple web framework for use in Google AppEngine. Just copy the app folder to your working folder and import it fro

Mar 21, 2021
Rest-and-go-master - A basic online store API written to learn Go Programming Language
Rest-and-go-master - A basic online store API written to learn Go Programming Language

rest-and-go(Not maintained actively) A basic online store API written to learn G

Jan 12, 2022
Short basic introduction to Go programming language.
Short basic introduction to Go programming language.

Go, Go! Short basic introduction to Go v1.17.6 programming language Go Logo is Copyright 2018 The Go Authors. All rights reserved. About This work was

May 30, 2022
Nov 15, 2022
Vektor - Build production-grade web services quickly
Vektor - Build production-grade web services quickly

Vektor enables development of modern web services in Go. Vektor is designed to simplify the development of web APIs by eliminating boilerplate, using secure defaults, providing plug-in points, and offering common pieces needed for web apps. Vektor is fairly opinionated, but aims to provide flexibility in the right places.

Dec 15, 2022
based on go lang build WEB development framework for go lang beginners .

based on go lang build WEB development framework for go lang beginners .

Oct 31, 2021
Start and finish your Go apps gracefully, even in the case of panics

Relax Relax - verb antonym for panic. In the context of Go programs, relax means to make critical failures less severe so that graceful shutdown is ne

May 7, 2023
An app skeleton for very simple golang web applications

Golang App Skeleton This is a skeleton for a golang web application optimized for simplicity and rapid development. Prerequisites Go 1.15 or greater O

Oct 16, 2022
A framework for apps written entirely in YAML, powered by ytt.

yapp A framework for apps written entirely in YAML, powered by ytt. Highly experimental! Do not use! # start the server... go run . -f examples/hello-

May 6, 2022
⚡ Rux is an simple and fast web framework. support middleware, compatible http.Handler interface. 简单且快速的 Go web 框架,支持中间件,兼容 http.Handler 接口

Rux Simple and fast web framework for build golang HTTP applications. NOTICE: v1.3.x is not fully compatible with v1.2.x version Fast route match, sup

Dec 8, 2022
Roche is a Code Generator and Web Framework, makes web development super concise with Go, CleanArch
Roche is a Code Generator and Web Framework, makes web development super concise with Go, CleanArch

It is still under development, so please do not use it. We plan to release v.1.0.0 in the summer. roche is a web framework optimized for microservice

Sep 19, 2022
A powerful go web framework for highly scalable and resource efficient web application

webfr A powerful go web framework for highly scalable and resource efficient web application Installation: go get -u github.com/krishpranav/webfr Exa

Nov 28, 2021