Ask HN: What's your favorite way of getting a web app up quickly in 2018?
I am still frustrated with the amount of incidental complexity required whenever I want to do this. My latest attempt was to use a Digital Ocean droplet with Django pre-installed. I guess the biggest issue there was setting up something so that I could easily deploy my local version to the droplet (ended up using git/Github), and ensuring those two environments were in sync. I looked into Docker in some detail about a year ago, and I think it's the only pretty good solution for this I've come across—but there's a steep up front cost in learning/setup etc. (or so it seems).
What services and technologies do you use when you'd like to quickly build a web app which may never be more than a prototype, but may also turn into something real? A big aspect of what I'm wondering is about automatically setting something up for keeping local/production environments in sync, quickly deploying to production, and not having to mess with a bunch of server configuration things, user accounts, security, etc.
568 comments
[ 2.4 ms ] story [ 307 ms ] thread- Scott Bell
My opinion is that when you're starting out, just go with a PaaS like Heroku. You can simply maintain a separate dev/prod branch and it'll automatically update the server.
All the issues you mentioned can be solved it just takes some investment somewhere (time if you do it today yourself / money to pay a PaaS or someone else to do it).
We personally use Kubernetes to solve these issues since we get stateless builds and simply have environment variables that change things like database connections, api keys, etc between our various environments. But again this took a few weeks to setup.
It's now a viable option.
2. create-react-app for front-end
3. digital ocean for hosting
I just cp files from local to server and use a couple different bash scripts for dev vs prod.
https://github.com/klenwell/hip-flask
For a more full-featured boilerplate kit, see:
https://github.com/gae-init/gae-init
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.
Backend: Go (optional embed db: ledisdb / boltdb / leveldb / rocksdb / etc...)
+
Frontend: create-react-app / create-react-native-app
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
We’ll get there!
Dependencies are evil.
sftp'ing a binary to your deploy target? That's more 2008 iyam...
I talked about it just a couple of hours ago [1].
[1] https://news.ycombinator.com/item?id=17215658
It can be as simple as a script tag at the bottom of your html and then writing ES5 React.
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.
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.
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
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.
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).
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.
How is docker going to make my life easier in this example?
To be fair, cross-compilation in Go is as simple as setting and environment variable.
Of course, I would say keeping the source on the VPS is just as easy.
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.
Your description would seem good for something management etc has down on paper / a design document.
If you're into that, or have CPU/RAM requirements that would be prohibitively expensive on Heroku then give it a try (I run it for a couple things on a cheap but powerful dedicated machine). If you're just doing something simple it's probably not worth it, just get a hobby dyno and go that route.
I haven't actually used it but looks pretty cool
1. npm install -g now
2. run 'now' command in the folder containing your app files
The files are uploaded, your app is deployed and your clipboard contains the URL. So simple it's like cheating.
https://zeit.co/now
2) Managed Postgres on GCP/AWS
3) Frontend framework of the day, like React or Vue.
4) Take 1-2 hours in the beginning to set up ci/cd (like Circle) to make things 10x more convenient.
Can you expand more on what you do here?
On the other hand if you're willing to ask for help there are plenty of freelance IT admins who would set up a digital ocean box with the DIY equivalent of Heroku.
Also, just because you use Heroku for your app servers (dynos) doesn't mean you have to use it for everything.
I think the main competition for Heroku these days is AWS and GCP. The workflow for deploying directly to managed cloud services has improved drastically over the last few years, so you might not need the niceties that Heroku offer.
Leaving a box with no monitoring and no on-site skill capable of fixing it is a bad idea. That box will explode at some point and it's going to explode at the worst possible moment, and you'll loose tons of business (and/or data) while you scramble to get someone to repair it.
Unless you have people ready to jump in and fix it should it break, don't risk it and just let Heroku handle it.
I have read similar comments to the ones here about scaling and cost, so I might bump into that at some point.
To implement the server side I typically generate Java JAX-RS skeleton code that can run in Jetty using Swagger codegen. You fill out implementation code and the app is off and running.
On the client side I generate Angular client stubs using Swagger codegen, then fill build services and UI components on top. For CLIs or other tools you can take a similar approach or just write the REST calls directly.
Code generation from an OpenAPI spec makes this process a lot quicker as it takes care of most of the boilerplate code necessary to process REST requests. It's especially helpful for making quick changes and also helps you to get to a stable, easily understandable API which is necessary if you decide to turn the service(s) into a real product.
Docker is incidentally a godsend for systems with multiple services, especially if you work in polyglot environments.
Yes Ember is still great. Ember data has gotten bloated though so I say pull that shit out IMO unless you are really used to it.
Ember v3.0 is all modular now, so you can just strip out modules until you get down to Glimmer. Versus React or Vue where you start with basically nothing and build upwards.
Exact opposite philosophy, but way faster for building 90% of CRUD apps.
Seriously, don’t overlook this combo. Auth just works. Hosting built in, no backend or database server to maintain. No API, just subscribe to a collection right from the view. It just works (and is easily swapped for the real deal if you need it).
I made a guide/boilerplate to show you how (includes auth, CRUD, full text search, stripe subscriptions):
http://getfirefly.org/
For me, time I’m writing unnecessary code or learning libraries I don’t already know is time I’m not spending thinking about the product. I’m a designer who just wants to ship.
I am open to suggestions though. What would you recommend for, say, auth instead? I’ve tried rails, Django, node/mongo, etc; even hosting a small db on compose.io comes with a chunky base fee, and I still have to do way too much work for user accounts/search/APIs/ORM. There’s a reason Firebase is popular with the yoof.
Change my mind though!
- huge community supporting a codebase initially private
- open source now so you can host it anywhere
- 3rd party online instances to quickly start [1][2]
[0][http://parseplatform.org/]
[1][https://sashido.io]
[2][https://back4app.com]
[3][https://https://www.nodechef.com/parse-server]
Full pricing: https://firebase.google.com/pricing/
Sure, but which one? :)
Maybe I am biased because I develop most of my applications in React. But if you don't want to bother with any backend application and just want to get out quickly, build your React application with Firebase. That's how I do it and that's why I also covered my whole boilerplate process in a comprehensive tutorial [0].
- [0] https://www.robinwieruch.de/complete-firebase-authentication...
.. what's going to be neat to see is how that "essentially the same thing" changes over time.
deepstreamhub.com is another neat SaaS that's worth looking into for some cases that Firebase might not handle as well ... there are probably yet other SaaS products that cover other specifics and will be still more in the future..
.. obvious mention re. SaaS products is that they could evaporate at any time. warranty void where prohibited. all states except ... idk, AK, for some reason.
>> " Now let's connect our databases to our app by adding their "keys" to our app's environment ("env") files. You should generally keep connection keys like this secret, so first we'll rename our environment files to keep them from getting committed into git (the new filenames are listed in .gitignore). "
https://github.com/sampl/firefly
Thanks for trying it out!
Now that React is supported, it's even easier for throwing together web apps.
Came here to recommend this myself.
I built an SPA with React + Firebase (auth, db, hosting, and all) to help my wife and I track our kids allowance and spending in just over a day: https://parentbank.actridge.com/ (did I mention Firebase hosting allows HTTPS on custom domains?)
It's an awesome combo that is seriously under-utilized.
The piece I wouldn't mind cutting out is heroku. If you do end up going the docker route, docker-machine is nice for being able to quickly put things up, "push" updates to digital ocean:
https://docs.docker.com/machine/examples/ocean/
Frontend will either be React or plain ol' JS depending on how complex the idea is.
Elixir is like if Erlang and Ruby had a child. It's a functional languages, so I guess there's a bit of a curve there. Plus you get stuff like macros, which are incredible, but I thought was some kind of voodoo magic the first time I encountered them.
There's a pretty decent tutorial on the elixir site, and the phoenix site if you want to learn.
As for the learning curve, I didn't struggle with it for very long at all, but your results may vary.
https://elixir-lang.org/getting-started/introduction.html
https://hexdocs.pm/phoenix/overview.html
In general, you don't need to know any Erlang to start working with Elixir. In time, as you advance your knowledge and start looking at more advanced features, you'll need the ability to read Erlang at some point, but that's actually pretty trivial: Erlang syntax is one of the simplest/smallest out there. It's much better in this case than it's with Clojure and Java.
The functional nature of Elixir may be a little weird, but, if you're worried about this, it's not taken to the extreme like in Haskell. At the end of the day, you do have a process dictionary (don't use it), and normal IO. It's true for both Erlang and Elixir, but Elixir adds some improvements on top of that: in Elixir, you can re-bind a variable (Erlang has single assignment only), you get the familiar syntax for accessing elements of collections (`coll[:keyname]`), the `if` is "fixed" to be normal if-then-else (the usual Erlang construct is dubbed `cond` in Elixir) and so on. It's FP but in the spirit of OCaml rather than Haskell: pragmatic and striving to be convenient without pulling the users' minds through a monad.
Now, Phoenix is another thing altogether. As far as frameworks go, Phoenix is very well designed, with a couple of orthogonal concepts being composed into a highly functional whole. To be honest, I didn't use Phoenix yet, personally - I did some code review for colleagues, but my own projects are written with Plug for now. Plug is a library which is comparable to WSGI spec in Python plus some additional utils, like in Werkzeug. Phoenix is built on top of Plug, so I figured learning it first is not a bad idea.
Turns out you can get by with Plug (and eventually some "plugs" packages from other people) for quite a while; the experience is like with Flask or Sinatra. You have to know what you want, exactly, but if you do, it's trivial to build a basic framework out of the available plugs. It's actually a strong selling point of the whole tech: as I mentioned, Plug is as much a library as a specification (with the same motivation as WSGI) and it's great for interoperability of components. The whole stack is composable and extensible at the same time, which is not that easy to pull off as far as framework designs go.
Documentation is decent, although its searchability is less so, I had a good time with devdocs.io for the core language and with hexdocs for plugs. It's definitely grokkable, and I'd say worth a try.
Once deployed, the best material on running beam apps is for Erlang, as well as ops tools like recon, and so you'll start learning and using it more then.