Hacker News Reader

Comment by marcus_holmes | Hacker News Reader

I write the server-side in Go, cross-compile to a Linux binary, and set that up as a service on a vanilla Ubuntu box (usually Digital Ocean). Deploying a new version is a matter of sftp'ing the new binary (and any templates, images, etc) over the top of the old one and restarting the service.

If I need a database then I use Postgres, and the setup for that can be a pain, so I get it documented/scripted using Ansible.

If I need something more complex than plain HTML on the client side then I use a Makefile to synchronise Webpack + Babel + React (and the hot reload during development), and the compiled bundle.js becomes another file to copy over.

I realise it's not very 2018, but to be honest I've kinda lost the will to live over learning anything more meta at this point.

View on HN

This is about as 2018 as it gets. Go and Rust are the only modern languages where you don't have to second-guess the stdlib for bad choices (looking at you php/ruby/javascript/etc..) yet provide amazing performance.

Backend: Go (optional embed db: ledisdb / boltdb / leveldb / rocksdb / etc...)

Frontend: create-react-app / create-react-native-app

I find Ruby’s stdlib a pleasure to use.

How many web apps can you name that don’t rely on any external gems? Packaging that mess is a pain in every scripting language.

Anything that runs on JRuby can be packaged as a single file.

And even with MRI, it's not as painful as people make out. Set `$GEM_HOME`, `bundle install`, tar up your app and the gems, stick them on the server.

How far do you make it writing a web app in rust or go without pulling in external packages, then? Or a front-end using only javascript and html?

In Rust, it’s pretty quick. You could write a server yourself, but it would take a lot of work. It’s trivial with a package though.

Steve, what is Rust's equivalent to Go's cross-compilation-- plain old cargo build?

$ cargo build --target=TARGET

a list of default targets-- $ rustc --print target-list aarch64-linux-android aarch64-unknown-cloudabi aarch64-unknown-freebsd aarch64-unknown-fuchsia aarch64-unknown-linux-gnu aarch64-unknown-linux-musl arm-linux-androideabi arm-unknown-linux-gnueabi arm-unknown-linux-gnueabihf arm-unknown-linux-musleabi arm-unknown-linux-musleabihf armv4t-unknown-linux-gnueabi armv5te-unknown-linux-gnueabi armv7-linux-androideabi armv7-unknown-cloudabi-eabihf armv7-unknown-linux-gnueabihf armv7-unknown-linux-musleabihf asmjs-unknown-emscripten i586-pc-windows-msvc i586-unknown-linux-gnu i586-unknown-linux-musl i686-apple-darwin i686-linux-android i686-pc-windows-gnu i686-pc-windows-msvc i686-unknown-cloudabi i686-unknown-dragonfly i686-unknown-freebsd i686-unknown-haiku i686-unknown-linux-gnu i686-unknown-linux-musl i686-unknown-netbsd i686-unknown-openbsd mips-unknown-linux-gnu mips-unknown-linux-musl mips-unknown-linux-uclibc mips64-unknown-linux-gnuabi64 mips64el-unknown-linux-gnuabi64 mipsel-unknown-linux-gnu mipsel-unknown-linux-musl mipsel-unknown-linux-uclibc msp430-none-elf powerpc-unknown-linux-gnu powerpc-unknown-linux-gnuspe powerpc-unknown-netbsd powerpc64-unknown-linux-gnu powerpc64le-unknown-linux-gnu s390x-unknown-linux-gnu sparc-unknown-linux-gnu sparc64-unknown-linux-gnu sparc64-unknown-netbsd sparcv9-sun-solaris thumbv6m-none-eabi thumbv7em-none-eabi thumbv7em-none-eabihf thumbv7m-none-eabi wasm32-experimental-emscripten wasm32-unknown-emscripten wasm32-unknown-unknown x86_64-apple-darwin x86_64-linux-android x86_64-pc-windows-gnu x86_64-pc-windows-msvc x86_64-rumprun-netbsd x86_64-sun-solaris x86_64-unknown-bitrig x86_64-unknown-cloudabi x86_64-unknown-dragonfly x86_64-unknown-freebsd x86_64-unknown-fuchsia x86_64-unknown-haiku x86_64-unknown-l4re-uclibc x86_64-unknown-linux-gnu x86_64-unknown-linux-gnux32 x86_64-unknown-linux-musl x86_64-unknown-netbsd x86_64-unknown-openbsd x86_64-unknown-redox

Thank you

Note that you also may want to use xargo or cargo-xbuild to build other custom targets, and rustup to fetch the stdlib for the targets listed above.

Aren't there also linker issues with cross-building for some targets like i686-pc-windows-msvc? At least, I don't think I ever got it to work properly but I don't recall what the exact problem was.

Some platforms are harder than others, it’s true. And if you link to any C code, you have to deal with that as well. As an example, I just saw this: http://zork.net/~st/jottings/rust-windows-and-debian.html

We’ll get there!

I never use server-side external packages when writing web apps (well, except the bcrypt crypto package, which is an official package but not technically part of the stdlib yet).

Dependencies are evil.

> as 2018 as it gets

sftp'ing a binary to your deploy target? That's more 2008 iyam...

How is this setting things up "quickly" when OP is asking to limit complexity? You're suggesting:

1. Server side in Go 2. Cross-compiling it 3. sftp'ing and restarting the service everytime 4. postgres 5. ansible 6. Makefiles 7. Webpack 8. Babel 9. React

Writing web servers in Go is extremely easy. https://golang.org/doc/articles/wiki/

Cross-compiling with Go is done by setting two environment variables. That's it. This is not like the mess of C++ cross-compiling. In LiteIDE it is simply a matter of choosing Linux from a drop-down: https://www.wut.de/pics/screenshot/e-505ww-07-pide-000.png

SFTP is not exactly hard. Nor is `nohup ./server &`.

From 5 on I agree though - is that 4 build systems? Insanity. I would just make a static web page with normal HTML forms or whatever and Go templates. If you really need client-side Javascript, I'd just use jQuery, or something similar and lightweight like minifiedjs.

yeah, I use straight HTML wherever possible. But for some things it isn't possible, or suitable. I'd love a simpler client-side environment. Any suggestions welcome... I'm looking at Vue.js now, recommended from comments here.

I've enjoyed using Elm for client side development.

I second this; Go + React.js (Vue.js in my case)

I talked about it just a couple of hours ago [1].

[1] https://news.ycombinator.com/item?id=17215658

That's interesting... I think I'll spend a couple of days playing with Vue to see if I can get rid of Webpack and Babel, because they're an enormous pain to set up (especially as they keep changing their config schema every major version release - I think I've climbed Webpack's config learning cliff three times now).

React doesn't need webpack or babel. People just see lots of benefit in using them, but there are tutorials out there on how to use just React.

It can be as simple as a script tag at the bottom of your html and then writing ES5 React.

Vue apps depends on webpack as well. But the vue-cli makes the whole set up a breeze. Especially v3 (currently in beta)

If the website you're building is simple you could even have vanilla html pages then attach vue to the divs that need that extra interactivity, then you won't any fancy loaders.

I try dozen of tools for a cross-platform app and finally settle on use vue.

Every time I use node and look at his insanity and get depressed.

So, I dislike STRONGLY the use of Webpack and friends. Is a chore because JS is even more nuts now, and everything assume you want node nonsense everywhere.

So, I persist and do this:

I introduce:

> Non non-sense javascript front-end setup with vue

https://gist.github.com/mamcx/1d3aa692b0d34b0fae696c12292a1a...

Using local .js/.css files downloaded from a cdn, then using cat to concat in the correct order all the deps, and finally let to build your css/js as you please for your logic.

Build time is zero after the first try.

P.D: Maybe using unix pipes I could minimify and stuff like that, but I don't need that.

If you just have a Vue file script tag in your document, you're good to go. If you want single file components, hot module reloading, Babel features, etc, you'll need Webpack. Luckily, the current and beta versions of the vue-cli make these non-existant problems. Just install using the cli and it's good to go, no setup needed.

How do you handle server side rendering? This is one of the reasons I chose to go full Node+React.

Vue also has server side rendering.

Check out gatsbyjs.org for server side react rendering.

Look up express-vue

nuxt.js is an all in one vue framework that has ssr and a really cool file based routing functionality

Your start is good but you add complexity on top of it. Install Golang on your VPS, clone the source code on it and compile it there instead of messing with cross compilation.

Also use sqlite to avoid the pain of setting up a SQL server, there is no need for it.

You can then easily get systemd to supervise your binary.

This is how I host all my web apps, the main difference is that I don't use Go but Nim. If you want a great framework match up then check out Jester + Karax, see how I developed the Nim Forum using this combination.

Better would be to just use docker.

Please explain. I still don't understand the use-case for docker...

How is docker going to make my life easier in this example?

> instead of messing with cross compilation.

To be fair, cross-compilation in Go is as simple as setting and environment variable.

Why put the source on the VPS? Go cross compilation is much easier then you make it sound.

    GOOS=linux GOARCH=amd64 go build

Nim can't beat that.

That's awesome, I didn't realise it was that easy with Go.

Of course, I would say keeping the source on the VPS is just as easy.

And what about zero downtime deploy (upgrading the app binary and updating the database schema)? It's difficult to do without some kind of reverse proxy and without a database server.

How often is that really required? OP asked for a quick deploy, for most apps it's enough to put the db into read-only mode and then update the schema. Upgrading the app binary is as simple as replacing it on the file system and then restarting the service.

The more often we deploy with CI/CD, the more we need zero downtime deploy. Putting the DB in read-only mode is not that simple, because the app needs to be able to work in a degraded read-only mode.

Yeah DB migrations are a pain in the bum. I do them manually because I still haven't found a tool that handles them properly.

But by the time there's significant data to migrate to the new schema, any schema change is usually due to a major version change or feature implementation, and the migration is part of a wider pain-in-the-bum situation.

For me this is the response to 'how do you build stable/scaleable/.../good web apps in 2018', but sadly not to 'favorite way of getting a web app up quickly in 2018?'.

The whole process of starting a new VM for every little project seems to me like overkill and developing components if you just want to get a prototype out the door can be difficult as the components will most likely have such a poor quality that you can't reuse them for anything else.

With that said, I am 100% pro Golang Server + Vue.js UI when it comes to building something which will be definitely more than a prototype (no shortcuts taken).

whats the level of your app's complexity?

Your description would seem good for something management etc has down on paper / a design document.

How is it possible that you sftp the new binary while the sever is running? It won’t let you because the file is in use.

Unlike windows, Linux allows you to delete a binary while it's running (the binary file is not locked).

Windows allows you to rename it.

%s/react/vuejs/

Reply on news.ycombinator.com