
What tech stacks are indie hackers using for their apps, and why? - ChanningAllen
https://www.indiehackers.com/round-table/what-tech-should-you-use-in-2018
======
1996
Python for the code, Postgres for the backend, Markdown for the frontend.
Because I am too lazy to reinvent the wheel, and most of that is good enough.

I would have much preferred to use Perl, R, dotnet, or just about anything
else, but there was an already made library in Python that was good enough for
90% of my needs, and 100% with some elbow grease, so my lazyness made me learn
Python instead!

But wait- it gets dirtier than this! The code is done is Vi, with no care in
the world about version control (rsync does most of what I need: backups), and
deployed to servers by manual SCP, with no automatic tests, no care about CD
or automatization - yet: as I need more and more servers, I realize I have to
spend time learning say ansible to provision them faster than a copy paste of
bash (I have low standards but I won't do curl|bash, just... no) but I am
delaying that as much as possible to concentate on implementation.

The servers are on Debian VMs on Azure, just because they gave me free credits
and do not perform as bad as AWS. When the free credits run out, I will move
to DO. Then I will see what else I can use, and that will be the right time to
care about ansible or whatever.

It is as ugly as I can get away with to get my MVP out, using tech from 1996
lol.

~~~
eagsalazar2
People saying they wouldn't use git don't know git. I admit it does take
investment to learn but once you are over the hump it is insanely easy and
useful (yes even easier than rsync and 10x more useful). Especially when you
consider that using rsync precludes your from collaborating even with one
other person which is crazy easy if you use github (for example). People not
using git: get over the hump, it is worth it, even on little side projects.

~~~
na85
Git's UX is horrible for people who don't know git, i.e. git beginners. All
the documentation and error messages are written as if the user is already
intricately familiar with the inner workings of git. As a result, it's very
hard to learn because you don't know what you're about to do without hours of
googling cryptic error messages.

Perfect example that happened to me today:

    
    
        $ git push
        fatal: The current branch insert_branchname_here has no upstream branch.
        To push the current branch and set the remote as upstream, use
    
        git push --set-upstream origin insert_branchname_here
    

What does it mean to "set the remote as upstream"? That phrase makes no sense
to me. Is that going to overwrite master on origin? I have no idea, but I'll
be damned if I am going to hit enter and risk overwriting my upstream branch,
so I Ctrl+C out of there and had to read a bunch of awful reference docs
posing as a tutorial.

Git is just plain terrible in almost every way. It just happens to be less
terrible for certain workflows than CVS/SVN/mercurial/whatever.

~~~
randomsearch
To save you some time and unhappiness:

Yes, git’s UX is absolutely terrible. It is an abomination. It is the worst
command line tool I’ve extensively used in that regard. For a long time I
stubbornly used mercurial, which is vastly superior.

But, it has become a de facto standard. This is a tragedy. But it is a fact.

So it is best just to spend time learning it, find a subset of commands and
make a cheat sheet you can refer to, and accept that the world is imperfect.
Hopefully at some point in the future git will die and we will transition to
the next big thing, and they will get it right that time.

There are many such things in the world of tech, and in most cases it is best
to say “yes, it’s awful, but no, I can’t change it, and rather than expending
energy on hating it (which is totally justifiable) I will expend the energy on
minimising its damaging impact to my productivity and focus on accelerating my
work elsewhere.”

I say this because I have spent so many hours ranting about git and every time
it gets in my way (git submodules anyone?) I used to get so stressed by its
design that it would hurt my productivity.

Be the Zen Dev: acknowledge it, isolate it, keep it at arms length.

Tips: Make a cheat sheet, use a minimal feature set, don’t try to do anything
clever with it, and always have a way out (eg backups! Take copies of your
directory before dealing with lesser know commands! Try things out on dummy
repo’s before breaking your own, etc.).

~~~
Redoubts
> But, it has become a de facto standard. This is a tragedy. But it is a fact.

I feel this sentiment so often in this field. It’s really distressing.

~~~
exolymph
Are you familiar with "worse is better"? Sometimes what makes a technology a
pain to use is also what makes it competitive.

------
nickjj
I'm working on a new project as a solo developer.

I'm writing it in Elixir and Phoenix (Elixir's goto web framework) with
PostgreSQL to back my data. For the front end, I'm using good old fashioned
server side rendered templates and Turbolinks with sprinkles of Javascript
where needed.

Despite having worked with Flask and Rails for the last 6-7 years I'm going
for Elixir this time around because there are aspects of the app that lend
itself well to what Phoenix has to offer and I'm using this as an opportunity
to grow as a developer. Every time I learn a new language / framework I find
myself leveling up in other technologies I know.

So far I'm super excited with the way things are turning out. I'm still pretty
early on in the project but I've gotten a decent amount of functionality
implemented already.

I'm really surprised Elixir isn't more popular. The language author and the
supporting community is awesome, and I've been the happiest I've ever been
working with this tech stack. Of course I'm still drinking the "omg this is
new and awesome" kool-aid, but even without really knowing everything too
well, I'm able to accomplish real world tasks and that's all I care about in
the end.

~~~
brandonmenc
I'm using exactly this stack for my current personal project - Elixir/Phoenix
and Turbolinks.

Sprinkling in either Elm or Vue for the one or two complicated widgets I'm
going to need, but I haven't committed to either one yet.

~~~
mercer
I've settled on Elixir/Phoenix for the backend.

On the front-end I might still experiment, but I think I'll settle for at
least a decent chunk of time on this:

1\. React + Styled Components (so html/css/js is finally no longer decoupled
in a way that just makes no sense) 2\. Page.js or something similar for
routing, because I've been bitten too often by react-router and like, and the
idea that routing is it's own thing makes sense to me. 3\. Baobab.js or
something similar for state management: basically, A. a single state object
with B. a kind of cemtralized action-flow to change this state, and C.
listeners of sorts within various components that trigger a re-render (cursors
in the case of Baobab). I could go full-on redux, but it doesn't seem,
necessary and I kind of relish running into the situation where, as my apps
grow, it turns out to be immediately obvious why Redux does what it does.

I'd be very curious to get some feedback on my choices, and/or alternative
suggestions. In particular regarding 3.

EDIT: to be clear, this is for full-on SPA's with no kind of crawling/SEO
needs.

------
jimmy1
Go and, honestly, sqlite with backups written to S3. It's the absolute
cheapest. I can run multiple apps on a t2.nano (t2.micro if I am feeling
fancy). My apps cost something like $1.50 to run a month, and they can easily
handle medium-sized traffic, plus Go is just so dead simple to deploy. scp a
build binary, and boom I am done. Once the app grows and more
collaboration/developers/requirements call for it, I will add more
infrastructure.

~~~
startupdiscuss
Do you use a framework? Do you do everything server side with Go or do you
have a JS library on the front-end?

~~~
jimmy1
net/http and REST api all the way down, I for the most part try to stick to
the stdlib as much as possible. The few exceptions are logging (I like
zerolog) the sql driver, and auth. I do keep the front/backend separation
because doing site hosting in S3 with a cloudfront cache is pennies on the
dollar (.63 cents a month) and I tend to lean towards using vue.js more these
days. I have been known to just serve the html statically directly from go as
well, and use go templates in the past, and use minimal jquery where it's
needed (I still like jquery :-/, not everything needs to be full-blown SPA-
mode)

------
robotkdick
Not that I'm counting, but there are 20 mentions of React, 13 mentions of Vue,
10 mentions of Python, 9 mentions of Go, 8 mentions of rails. The OP had a
couple mentions of Wordpress.

AND Zero mentions of Meteor, lol!

I think I'm the only indie developer using Meteor and Blaze, but I have to say
they make my life WAY better. Granted, it took some time to figure out exactly
how to optimize the stack to make it scale correctly, but NOW Meteor is the
only solution I've heard of that does this:

 _Meteor now automatically builds two sets of client-side assets, one tailored
to the capabilities of modern browsers, and the other designed to work equally
well in all supported browsers, so that legacy browsers can continue working
exactly as they did before. This “legacy” bundle is equivalent to what Meteor
1.5 and 1.6 delivered to every browser, so the crucial difference in Meteor
1.7 is simply that modern browsers will begin receiving code that is much
closer to what you originally wrote._

The apps I build now run like native apps in a modern browser. Laser fast.
It's beautiful, like the first time using broadband.

After everyone and their mother proclaimed Meteor to be dead, they rose from
the grave and locked in like Godzilla. I don't begrudge anyone their choices,
but if you haven't taken a look at Meteor lately, having used Wordpress,
Rails, Ember, React, and vanilla JS with node in the past, I'm very grateful
Meteor's development team is STILL knocking it out of the park.

~~~
ai_ia
I can assure you that you are not alone. I am developing meteor with react. I
took the clever beagle pup as the base. My app is a working smoothly and
meteor does a lot of things which I don't completely understand, but it just
works.:)

~~~
robotkdick
Clever Beagle is a great starting point as it's optimized to how Meteor works.
Ryan Glover, the brains behind CB and Meteor Chef, is both generous and smart.

------
riantogo
It’s not cool anymore but I use PHP and MySQL with a $5/mo inmotionhosting
account. This is after I decided to not take on the overhead of native with
multiple code base and App Store deployments. Good ol’ webapp it is.

However every single day I do wish there was a solution for my webapp to get
access to contacts on the phone and of course notifications. It would have
been a game changer given the nature of the product. Currently it is a world
of compromises for hobby developers (shameless plug:
[http://ping3.com](http://ping3.com))

~~~
andrewmackrodt
I use the lamp stack too, hosting on scaleway nowadays; aws is great but for
my own non critical hobbiest projects scaleway is hard to beat. Having said
that, cpanel is great on shared hosting with the ability to specify your PHP
version and modules.

As a language PHP can be a mess but the ecosystem is fantastic; the release of
PSRs, composer and 7.x have been great.

------
munchbunny
For getting web apps up fast, React, Firebase, Git, and Heroku. It's a well
trodden path so the tooling is simple and the components are reliable.

For my VR stuff... Unity is really the only choice that's fast to get off the
ground, so Unity it is.

For hacking together backend heavy stuff, Python. Flask if I need to expose an
API endpoint. Postgres if I need a real database, sqlite if I don't. Deployed
to my evergreen playpen virtual instance via Docker containers because it's,
once again, a well trodden, simple, and undramatic path.

~~~
jimmy1
Do you use firebase auth? It looks really good. I just had a heck of a time
implementing user management and a couple oauth2 flows and it looks like it
could have saved me a bit of time. My only concern is their plans are a little
weird, it just jumps from free tier to jumbo size, wish there was something a
little in between for less money.

~~~
munchbunny
Yup, I do use it. From a security and convenience standpoint it's just so much
easier than whatever I could have come up with myself. But yes, the pricing
sucks. I don't have a good answer there unfortunately.

------
nathan_f77
I built FormAPI [1] with Ruby on Rails. I used plain Rails views for most of
the CRUD things, and used React/Redux to build the template editor [2], which
is pretty complex. I've been extremely productive with Rails, and the
performance has not been an issue at all. My plan is to rewrite the API and
workers in Elixir when it will save me $2,000 per month on hosting costs. And
even then, I would probably be making so much money that it wouldn't matter.

I started on Heroku, but I had a lot of free AWS credits from Stripe Atlas
that I wanted to use. So I moved to Convox [3] on AWS, and it has been
absolutely awesome. I have a rock-solid cluster across 3 different
availability zones, and I'm also running Postgres with high availability
(RDS).

I haven't had a single second of downtime since I migrated [4] (I up the
status dashboard a few months ago, but moved to AWS earlier than that.) Convox
supports auto-scaling and rolling deploys. It waits for the web process to be
healthy, and if something crashes it rolls back the deploy without any
downtime. I can also terminate any instance at will, and another one will pop
up to replace it with zero downtime. After using it for the last ~6 months, I
feel confident enough to start offering a 99.999% SLA.

[1] [https://formapi.io](https://formapi.io)

[2]
[https://formapi.io/templates/tpl_DEMO42TmQjTgsQ7q/edit](https://formapi.io/templates/tpl_DEMO42TmQjTgsQ7q/edit)

[3] [https://convox.com](https://convox.com)

[4] [http://status.formapi.io](http://status.formapi.io)

------
motohagiography
Flask (hosted by pythonanywhere) and Neo4j from Graphene.

Chose both because I wanted consistency between the abstraction of my business
logic, and the spec of my implementation.

I get some chippy guff about using graphs, but by taking the time to define my
business logic as a grammar, expressing that grammar as a graph, then
implementing it directly into the model, I get a lot of "aha," moments from
potential customers.

Graphs can be analogous to functional languages in that if you are using them,
there is a higher likelyhood you've reasoned something through before
implementing it.

~~~
83457
Can you provide more info about your graph approach? Thanks!

~~~
motohagiography
[https://en.wikipedia.org/wiki/Ontology_(information_science)](https://en.wikipedia.org/wiki/Ontology_\(information_science\))

------
Klonoar
I actually wound up building most of my current project in Rust, on top of
actix-web.

Partly because I'm apparently a masochist, but also because... I mean c'mon,
modern architecture is CRUD and job queues. Rust can do that fine if you don't
get distracted by the bells and whistles.

I ripped out and open sourced my user-module stuff for authentication
handling, if anyone's interested:
[https://github.com/ryanmcgrath/jelly](https://github.com/ryanmcgrath/jelly)

------
raarts
My stack: Gitlab CI/CD, deploying using Ansible to Docker Swarm, running
Keycloak for auth, RabbitMQ for messaging, Postgres, Elixir/Phoenix for the
API server (GraphQL), Apollo + React Native for frontend and mobile apps.

Why? For me it's best of breed vs simplicity. OpenID Connect is the most
mature auth, rabbitmq very good messaging, elixir a lovely language, graphql
the most programmer-friendly connection between frontend and backend, and
react native allows 90% code sharing between web SPA and mobile apps.

And if you combine all of these (I mean if you finally set it all up), it's a
low number of lines of code environment.

------
mindcrime
Speaking for myself: mainly Groovy and Grails, with a little Java mixed in.
Postgresql when I need a relational DB. Bootstrap for basic CSS, and jQuery to
add AJAXy bits. I have not yet adopted a JS framework like React or Vue,
although I've been looking at giving Vue a shot. I use Ansible for automation,
Git for version control, Eclipse as an IDE. Deploy to CentOS linux mostly.
Just starting to go down the path of adopting Docker and (probably)
Kubernetes. Cloud infrastructure is either Linode or AWS.

All of that said, I'm a big believer in "use the right tool for the job" so if
something comes up that requires C++, I'll use C++. If something needs Python,
then Python it will be. If Prolog is right for something, I'll use Prolog. Or
COBOL, or Erlang, or Ruby, or CL, or Perl, or SNOBOL, etc., etc, yadda, yadda,
ad infinitum...

------
leon_sbt
My software dev path: Didn't know anything serious about web dev/software
systems 12 months ago. So if my stack seems shiny, I just picked what many
people on Medium/Hacker News were talking/raving about.

Front-end: React SPA (Via Create React App),Redux, React-Bootstrap Why: I had
no prior framework experience, single command setup, and plenty questions on
Stack Overflow and Medium articles to learn with. Going the plain Javascript
route with no frame work,seemed like I would be on a slippery slope for
spaghetti code down the line. React's one-way data flow and component
architecture made things incredibly easy to mentally digest. I found React's
documentation VERY well organized and explained, and Vue's documentation was
intimidating when compared to React.

Version Control: BitBucket Git Why: Free private tier for solo use and enjoyed
previous experience with Atlassian products

CI/CD: BitBucket Pipelines Why: Already using Bitbucket, this just worked
seamlessly with it. Only $10 for 1000 more build minutes.

Firebase: Hosting/Cloud Functions/Firestore/Auth Why: Everything is
automagical HTTPS static website hosting for the create-react-app (This is
what first got me started) Then came Storage,Firestore,Cloud Functions, and
Auth. Wish it had an automagical SQL product. Low Entry Cost

Cloud Provider: Google Cloud Why: Had no experience with any cloud provider. I
found the pricing/product offerings really easy to digest and interpret when
compared to AWS.

Email Sender: Sendgrid Why: Good starting free tier. Decent Docs. Easy to
setup.

Backend Compute: Google Compute Engine +Docker+Python-based API app Why: I can
do local dev easily with Docker, push the image to Google Container Registry,
then pull the image to the VM. It's easier to do than learning to setup a
CI/CD piped GKE cluster Eventually I want to pay the "tax" go to a GKE CI/CD
Kelsy Hightower setup,so I can git push/PR/merge a change, and it's in
production. I don't do enough changes to the backend right now to justify a
CI/CD piped GKE setup.

Other: Email Client: Gsuite Why: Custom Domain Name I'm already familiar with
Gmail

Project Management: Trello Why: Integrates with Bitbucket Multi Device Support
(Phone,Tablet,Desktop) Easy to mind map and organize features

What I value: Good Docs Free tier for solo devs/low use, and progressive
options for paid plans (Gives me breathing room on cash while I figure things
out) Lots of questions/answers on Stack Overflow or in-depth Medium articles.

------
im_cynical
Currently been working on a web app for about 8 months.

Python for the backend under the argument of "build using what you know".
ReactJS for frontend development because Python for frontend work I find very
antiquated.

Architecture wise I'm hosted in AWS. Data is stored in MySQL and Redis. All
self hosted because I'm to cheap to pay per request pricing and the overhead
is very minor when done right when rolling my own

~~~
kimdotcom
How much RAM do you allocate to Redis?

~~~
im_cynical
My current indie web app is still in development so final numbers for prod are
TBD. However I'm using it for

* Storing time counters on user actions (timestamp of last time a user posted/edited X, meant to be a throttling mechanism against abuse)

* Site content caching, around 20-50kb per page, each page being user generated content

Sizes will obviously vary on traction so not sure about the final numbers.

\----

My last 9-to-5 employer was a very well known and my largest caching tier in
Redis there was 512GB in a cluster configuration. I'm using the same server
configuration and sharding logic for the indie thing, just on a smaller scale

------
duncan-donuts
My side project is using Rails, React, Postgres, and deployed to heroku.
There’s nothing flashy but I can prototype quickly and it’s easy for 2 people
to manage.

~~~
troycarlson
Same here.

------
RandomBK
I use multiplatform Kotlin to compile shared business logic to JVM and
Javascript. The frontend then uses Typescript+React/Redux while the backend is
a Kotlin Spring app with Postgres.

~~~
FragenAntworten
How are you handling authentication? OAuth 2 with Spring Security, or
something else?

~~~
leonroy
Not the OP but I started with cookie based auth and Spring Security and then
moved to OAuth 2 - it’s extremely painless to setup (100 lines of code at
most) but it did take a while to understand it all.

The Baeldung Spring Security course helped a lot.

If in a hurry though you can always use an external service like Auth0. I had
that setup in an afternoon whereas understanding OAuth 2 and Spring Security
took a week.

~~~
FragenAntworten
Thanks! I'll check that course out.

------
noncoml
For the backend I start with Node, then get tired of the runtime errors and
switch to Go. Go is cool but soon I get tired of writing “if err == nil” so I
switch to Haskell. Haskell is nice but soon I get tired of not finding decent
libraries for some not very popular things that I use, so I say fuck it and go
to rails. Ruby is nice and Rails feels well thought out and solid, but then I
can’t help be annoyed that it’s not fast, so fuck it, I switch to Rust. I get
tired of lifetimes and wrapping everything in RefCells so I switch to Erlang.
Erlang is cool and all, but no fucking meta programming. Sucks, let’s try
Lisp...

I am not making fast progress, I think the problem is my keyboard, I should
try buying that Ducky one I have been eyeing for quite a while.

~~~
nso95
Just pick something and stick with it, every technology has its problems.

~~~
noncoml
You are right! I should stick with Scala. It will also give me the opportunity
to learn a new language!

Play looks good, but maybe I should go with Scalatra instead? Should I be
using Slick? It's quite different than any ORM I used so far, maybe I should
bake my own Scala ORM. OK then, here we go. One more decision, REST or
GraphQL? GraphQL seems to be the future. Let's go with that. Man, types are
nice and Scala's type system is powerful, but sometimes I wish I had the
flexibility of a dynamic language. It would make prototyping much faster.

Fuck it, "git checkout -b node_v2"

~~~
abledon
This is an example of some of the best performance art on hacker news

~~~
smt88
Although I love it and upvoted both comments, it's also an example of why
straightforward comments waste much less time/text than jokes/satire (on HN)

------
passivepinetree
Over and over again I keep hearing the advice to "build using what you know."

How do I separate what might be a side project to learn a new stack from a
side project that might eventually make money?

~~~
Mc_Big_G
I had to make this decision recently and my conclusion was if your goal is to
build something that makes money, do it with what you know. Why? Because you
can spend 100% of your time building instead of 50/50 learning/building (or
worse). Projects with the goal of being a business should iterate and fail
fast. If you win the app lottery and actually build something people will pay
for, they won't want to wait for you to learn while you build it out. Someone
else will do it with some "old" tech like ruby on rails and take your
customers and revenue. Spend your time working on the business, not the tech.
Developers think code is important but the reality is that it almost doesn't
matter. You can build something successful with the worst tech decisions
imaginable. I know it's hard to accept but it's true. I've personally
witnessed an absolute frankenstein's monster app, made of a mish-mash of what
are now considered the worst technologies, get sold for $30+ million and the
founders retired to the Caribbean where the build a mansion and an upscale
restaurant just for fun. I pity the people devs who have to inherit that, but
the value wasn't in the tech and it almost never is.

~~~
i_made_a_booboo
If you're spending 100% of your time building you're doing it wrong anyway.

I feel like this is just missing so much conte xt.

If you are working full time and can hack in your after hours to learn a new
tech stack first and then start your project there might be an aggregate
benefit over just starting the project right away using what you know.

Context matters to a huge degree in these kinds of discussions. I feel like
people just like to give blanket statement advice.

------
berti
C++/Qt for GUI, Go or Python for backend, Python for misc scripts/prototypes,
C for uCs. They are all well trodden paths with plenty of good libraries
available, and good tooling available. I have spent a bit of time playing with
Zig most recently, it could finally replace C for me!

------
tephra
Web: typescript frontend and phoenix (Elixir) backend is My new setup.

Apps: Flutter and if I need it switch to native. But flutter is really good
for my simple needs!

------
sorrymate
React/Redux frontend and .Net Core for backend API. The site takes advantage
of Server-Side Rendering and Lazy Loading based on Routes/components.
Authentication is built into the App with JWT and Authorize attributes on
controllers.

------
deforciant
I use Go, Vue.js, Postgres, NATS, Redis, Keel, and deploy everything
Kubernetes.

So far I am super happy with the stack, runs cheaply and requires pretty much
no maintenance. Just tag a release on GitHub, Google Cloud Builder builds the
image, Keel updates deployments and in a few seconds I have updated production
with zero downtime.

While some people are happy with their copy/paste binaries/code to remote
servers, I think a good pipeline to release and run your workloads makes
working on side projects a lot more pleasure where you can focus on code and
features. It also provides you with a valuable experience that can make you
more money than the side project itself :)

------
gorbypark
On the backend my API is using node+koa and postgres+postgis. Front end is
vue. Koa is amazing, and there's a postgis package for knex (a SQL query
builder) that lets me do geospatial stuff right in node, which is a game
changer. Backend is deployed in containers, Google container registry builds
the images for free on every git push and custom bash scripts deploy on the
digitalocean instance. Front end is deployed with Netlify, also on the free
tier, and also amazing. It's incredible how cheap (and mostly free) it is to
deploy side projects these days!

~~~
ngrilly
Thanks for sharing your stack here!

How do you deploy your backend containers without downtime?

Do you host your Node app and PostgreSQL on the same machine?

I understand your frontend is hosted on Netlify and your backend on
DigitalOcean: are they accessible under the same hostname (using Netlify proxy
for example), or do you use CORS requests?

~~~
gorbypark
I do have a slight downtime (1 second or so) when upgrading containers since
the bash scripts just pulls the new image, stops/rm the container and start up
the new one... Although my project is for an enterprise customer who works
7am-5:30pm so I just do it outside of those hours. Each end point is it's own
instance too, which minimizes the likely hood of anyone knowing.

It was all designed to run on kubernetes which would allow rolling updates
with zero downtime, but I can't justify the cost of a cluster at the moment.

The node app and postgres are on different instances. They could easily be on
the same, though. Postgres is open to the world since GIS analysts need to be
able to connect to it with QGIS. The API is also open to the world using CORS
for the same reason (a custom GIS collection tool accesses the REST API).

~~~
ngrilly
Interesting!

I think a 1 second downtime when deploying a new version of the backend is
tolerable if the app is a single-page application, because the app can
implement a retry logic client-side. This is possible only if the backend can
be stopped and restarted really quickly. Otherwise, a rolling update or green-
bue deployment is necessary.

Another question: do you expose your Node service directly to the Internet, or
is it behind a reverse proxy?

------
lkrubner
I’ve a small side project I’m working on. I am writing the backend in Clojure
and then deploy with Jenkins using the Groovy DSL — it’s useful that
everything runs on the JVM. The Jenkins code calls Terraform to set up the
servers, drawing on optimized AMIs I set up with Packer. I avoid Docker for
all the reasons I’ve written about elsewhere (you can Google if you’re
interested). Packer does everything that people would otherwise use Docker
for. For now the frontend is plain HTML and jQuery. I haven’t done the mobile
app yet so no need for Angular/Cordova or React.

~~~
stevenhuang
Link for others: [http://www.smashcompany.com/technology/docker-is-a-
dangerous...](http://www.smashcompany.com/technology/docker-is-a-dangerous-
gamble-which-we-will-regret)

It was a great--thanks.

------
jdblair
Python for control software, C++ for LED drivers, OSC (Open Sound Control) for
communication.

[https://www.youtube.com/watch?v=kG4xvTjzRwo&t=27s](https://www.youtube.com/watch?v=kG4xvTjzRwo&t=27s)
[https://www.youtube.com/watch?v=jZVFdqyaKug](https://www.youtube.com/watch?v=jZVFdqyaKug)
[https://github.com/jdblair/MegaPrayer-
oscled](https://github.com/jdblair/MegaPrayer-oscled)

------
neeleshs
Django, Postgres RDS on elastic beanstalk, with some SNS use.

Vue+vuex on the front end.

Gitlab CI/CD for deployment

Extremely fast dev/deployment turnaround time with Django and Beanstalk.

Vue/vuex is simple enough for me to understand and build SPA

~~~
bash-j
Is there a guide on the internet that would help me figure out how to use Vue
with Django? I tried a couple last month but they were poorly structured or
didn't explain enough about what they were doing, and since I'm not great at
JavaScript I gave up..

~~~
neeleshs
I've completely separated it out. Except for some authentication pages, it's
all JSON APIs. Django project does not have any frontend assets of Vue/vuex

------
EliRivers
C++, Qt and some OS API.

I'm not in web apps.

~~~
jcelerier
Same stack ! happily hacking on a DAW for interactive art -
[https://ossia.io](https://ossia.io)

------
meesterdude
Wow, lots of Vue mentioned! I was expecting mostly react, but surprised to see
there was actually some pushback against it.

> I've heard React described as "10 times as much work for a 20% better user
> experience", and I think that's about right (maybe not 10x, but probably 2x)

I thought this was a gem.

------
HugoDaniel
For [https://gridgenerator.com](https://gridgenerator.com) I am using:

    
    
      - Tachyons CSS
      - InfernoJS
      - Typescript
      - Node.js (with express and postgraphile)
      - PostgreSQL
      - Nginx
      - DragonflyBSD

~~~
wildrhythms
Are you using Typescript for frontend or backend (or both)?

~~~
HugoDaniel
Mostly front-end:

[https://github.com/HugoDaniel/gridgenerator](https://github.com/HugoDaniel/gridgenerator)

But the video producer/converter is also in TS (in that same repo). It
produces your making-of videos like these:

[https://gridgenerator.com/static/37.mp4](https://gridgenerator.com/static/37.mp4)

------
milankragujevic
I'm not sure why people connect success with the language something is written
in..?

~~~
hnarayanan
Because that’s the only only thing they have control over. It’s at least
possible to imitate someone’s stack or basic idea.

------
dopeboy
React + Django hosted on Heroku. Why? Because I'm most the productive with it.

------
zhobbs
For my recent projects, I've used Go + DynamoDB for a GraphQL backend, and
Next.JS with SSR on the frontend. Deploying both to lambda with Apex Up.
Stripe for billing, SendGrid for transactional email.

~~~
dpeck
Any tips on the go/dynamodb side of things? I’ve looked at it and experimented
a little and it seems quite easy to get data into dynamodb and quite
convoluted to get it out.

~~~
zhobbs
I'm using [https://github.com/guregu/dynamo](https://github.com/guregu/dynamo)
for the data reading/writing. In my experience, the trick with Dynamo is the
schema design. I haven't had problems with the libraries/queries as long as
the schema made sense for how I'd be accessing the data.

------
itbeho
Elixir, Phoenix and Postgres. I like a lot about Elixir and find it's a great
solution for many of the soft-realtime apps that I've been building lately.

Standing up a CRUD app in Phoenix is dead simple as well.

------
startupdiscuss
I haven't done an official count (comments plus the site) but a very strong
showing for full stack Rails or Django, and when people do stick in a front
end it is usually React or Vue.

------
mlthoughts2018
Python and Cython, flask, gunicorn, various ML frameworks, Postgres for web
services.

Python with Cython because this allows extremely nice flexibility between
concise, expressive code and low-level targeted performance optimization.

Flask with gunicorn has scaled extremely well for us, but there are many good
alternatives. Postgres because flexibility with customizations and data types
in the database has been the most important thing for us.

------
rikkipitt
Thanks for the featuring my side project
[https://www.inviewapp.com](https://www.inviewapp.com) Channing!

------
Aegis11
Vue.js on the front end with MongoDB Stitch handling authentication and
database storage. Deployed to AWS but started using Netlify and loving it.

------
Andrex
Firebase suits my needs almost perfectly for projects where I'd rather focus
on the front-end and design than maintaining a back-end, since I'm only using
it for very small apps and sites.

Past that, I'm fond of Node, but that may be an unpopular thing to say on HN.
:)

------
ta1234567890
Anyone knows of similar kits/packages to Laravel (PHP) and RailsKits (RoR)?

Something that will let you focus on creating the part that's unique to your
project rather than having to build everything (or a lot) from scratch?
(Rails/Django/etc are not enough).

~~~
greenhatman
Use Laravel Passport for OAuth. Use the Vue Cli to create your SPA. Then just
write a class in the Vue app to store the bearer token and send it through on
each request.

I'm on mobile so going into detail is difficult. If it would be useful I'll
write a guide for you.

------
hokumguru
Surprised no ones talking GraphQL with as much coverage as it gets on this
site.

I’m running my newest solo project on Prisma with GraphQL Yoga as the backend
and React + Apollo as the front end. It’s really quite something and allows
for extremely quick development.

------
holografix
Python, Django/WagtailCMS, React+Redux, Redis and RedisQ, Postgres, Kafka,
Docker + Compose for local dev. Visual Studio Code.

Tempted to learn a 2nd language well, thinking Go but curious about the
experience of Kotlin + IntelliJ

------
tannhaeuser
I'm sticking to standardized languages/tech with multiple implementations to
keep control and deployment options: JavaScript, C, SQL, HTML and SGML, and
Prolog, plus standardized APIs

------
IloveHN84
I'm using c++17 with Conan and cmake, plus SQlite/Qt.

I managed to run the deploy using terraform on AWS free tier and Azure msdn
account

------
insulanian
F# on .NET Core with PostgreSQL, written with JetBrains Rider, running on
Ubuntu on AWS.

------
briandear
Swift Vapor + PostgreSQL and you're done.

