29 ms·

Golang for the API, running on Lambda. React or Vue for the UI. FaaS isn’t a fad, new systems built on an event based architecture are simpler, more cost effec

Golang for the API, running on Lambda. React or Vue for the UI. FaaS isn’t a fad, new systems built on an event based architecture are simpler, more cost effective, and scalable than the traditional application server approach. And the reactive programming pattern is easy and powerful and maps extremely well to modern UI needs. I have a boilerplate Go / Lambda app here: https://github.com/nzoschke/gofaas https://github.com/nzoschke/gofaas I use it with this excellent admin interface framework for CRUD tools: https://github.com/marmelab/admin-on-rest https://github.com/marmelab/admin-on-rest

candiodari 9y ago
Half the source files read like J2EE stuff. An example: // KMS is an xray instrumented KMS client func KMS() *kms.KMS { c := kms.New(session.Must(session.NewSession())) xray.AWS(c.Client) return c } > Golang for the API, running on Lambda. React or Vue for the UI. You forgot "YAML for configuration. Python for ... I'm not even sure what for (linting the configurations ?), but you use lots of it. TOML for golang dependencies. JSON for other pieces of configuration. There is even some XML stuff in there". Even just limiting to Go you're using something like 10 large external libraries. When I read this, I'm like ... sigh not AGAIN. Oh and after starting it, may I just point out, that despite all that work, it's nowhere near as good as a Laravel, Drupal or Ruby-on-rails app, in terms of functionality (speficially, using this, you'll constantly need to write extra tools for basic operations on the database that your tool doesn't support, whereas each of those frameworks have something like Drupal's "admin"). And I might add, more expensive to host than either of those options too.
- nzoschke 9y ago
  Yes static YAML for config. It may be more verbose but it's simpler than Rail's ERB in YAML that requires a the Ruby VM plus application config to interpret. Yes external libraries. 80% of those are for testing (as is the Python stuff). In Go land you should effectively ignore the vendor folder, I check it in for developer convenience and system stability. Compare to Rails which has a massive dependency graph. And one that has to follow your app around for every build and deploy. I will absolutely grant that for SQL CRUD apps, you still can't beat the Rails tooling. Migrations, rake tasks, ActiveRecord, Scaffolding and the Ruby REPL to poke at your models and data are very useful. But decoupled tooling is getting really good. The https://github.com/marmelab/admin-on-rest https://github.com/marmelab/admin-on-rest project is better than Django Admin. The basic CRUD stuff is just as easy, then it's infinitely more configurable with a bit of custom React programming. And it's not coupled to any language, framework or database. Finally cost is effectively zero for all of these options to start. AWS and Heroku offer a generous free tier. Developer time is the real cost to watch. But in terms of raw resource consumption, static Go binaries talking to DynamoDB plus a static React page are obviously less "expensive" than Ruby VMs talking to a dedicated Postgres server and rendering HTML pages.
thefounder 9y ago
How is Lambda better than a PaaS like Appengine(not that appengine would be a good choice) for CRUD apps ?
- nzoschke 9y ago
  I don’t think it’s necessarily better, I’m just sharing the approach I take these days.

candiodari 9y ago

Half the source files read like J2EE stuff. An example: // KMS is an xray instrumented KMS client func KMS() *kms.KMS { c := kms.New(session.Must(session.NewSession())) xray.AWS(c.Client) return c } > Golang for the API, running on Lambda. React or Vue for the UI. You forgot "YAML for configuration. Python for ... I'm not even sure what for (linting the configurations ?), but you use lots of it. TOML for golang dependencies. JSON for other pieces of configuration. There is even some XML stuff in there". Even just limiting to Go you're using something like 10 large external libraries. When I read this, I'm like ... sigh not AGAIN. Oh and after starting it, may I just point out, that despite all that work, it's nowhere near as good as a Laravel, Drupal or Ruby-on-rails app, in terms of functionality (speficially, using this, you'll constantly need to write extra tools for basic operations on the database that your tool doesn't support, whereas each of those frameworks have something like Drupal's "admin"). And I might add, more expensive to host than either of those options too.

nzoschke 9y ago
Yes static YAML for config. It may be more verbose but it's simpler than Rail's ERB in YAML that requires a the Ruby VM plus application config to interpret. Yes external libraries. 80% of those are for testing (as is the Python stuff). In Go land you should effectively ignore the vendor folder, I check it in for developer convenience and system stability. Compare to Rails which has a massive dependency graph. And one that has to follow your app around for every build and deploy. I will absolutely grant that for SQL CRUD apps, you still can't beat the Rails tooling. Migrations, rake tasks, ActiveRecord, Scaffolding and the Ruby REPL to poke at your models and data are very useful. But decoupled tooling is getting really good. The https://github.com/marmelab/admin-on-rest https://github.com/marmelab/admin-on-rest project is better than Django Admin. The basic CRUD stuff is just as easy, then it's infinitely more configurable with a bit of custom React programming. And it's not coupled to any language, framework or database. Finally cost is effectively zero for all of these options to start. AWS and Heroku offer a generous free tier. Developer time is the real cost to watch. But in terms of raw resource consumption, static Go binaries talking to DynamoDB plus a static React page are obviously less "expensive" than Ruby VMs talking to a dedicated Postgres server and rendering HTML pages.

thefounder 9y ago

How is Lambda better than a PaaS like Appengine(not that appengine would be a good choice) for CRUD apps ?

nzoschke 9y ago
I don’t think it’s necessarily better, I’m just sharing the approach I take these days.