May 29, 2019

What's your tech stack?

Rosie Sherry @rosiesherry

Whether you build things from scratch or use services / no code type options...

  • What is your tech stack?
  • Your reasons for choosing them?
  • And are you happy with your decision?

#ask-ih

  1. 16

    Indie Hackers uses…

    I settled on the majority of this tech stack back in 2016 when I was first starting IH, mostly because I thought it'd be really fun.

    If I could go back I wouldn't have made IH a single-page static app, mainly because it's harder to fix and prevent performance issues as the site grows. But hindsight is 20-20! The upside is that, as a static app, IH pretty much never crashes, which helped out a lot especially in the early days.

    1. 2

      If I could go back I wouldn't have made IH a single-page static app, mainly because it's harder to fix and prevent performance issues as the site grows.

      Can you expand on this? Which performance problems come up, and which ones are hard to fix?

      1. 6

        Which performance problems come up

        I just tried checking my notifications and the page load took 12 seconds the page took 52 seconds (and the front page takes 12).

        For anything that isn't cached, IH is literally the slowest site I ever use. On the good side, the front page and various other cached parts of the site have gotten considerably better recently. Still though, plenty of sites with more traffic that run boring old WP are free of these page speed issues.

        1. 3

          Seconded, I also find IH to be unreasonably slow and I find myself dreading hitting the "back" button, because I know the front page will be so slow to render again (and then I have to wait for all the JavaScript to catch up).

          This is especially striking after switching from Hacker News, which renders a static site.

          IH would benefit a lot from switching to at least an isometric rendering model, so that we could get the pages quicker. And less JavaScript altogether, I'd say...

          1. 1

            Front page should be faster soon, working on some performance fixes there. But rewriting the whole site not to be a SPA isn't feasible any time soon.

            1. 1

              Thanks!

              I know this could be difficult, but in general a SPA can also be server-side-rendered (this is how my https://PartsBox.io/ app works, every public page is shipped from the server and then the JavaScript jumps in later, if possible).

              Anyway, the effort is much appreciated!

        2. 2

          How many notifications do you have?

          1. 1

            Under 1k, probaly ~400

            FWIW, it didn't try to load them all. All that wait was just to get the first chunk of "infinite" scroll.

            Edit: I have 293 notifications

            1. 1

              That's just code that doesn't scale on my part. (Specifically, Firebase queries that don't scale.) I didn't write any of the code for IH initially to assume that it would get as big as it has, and I haven't touched the notifications code in years. But with proper pagination and indexing it could be super fast.

              1. 1

                I misspoke. The front page takes 12 seconds and the notifications page takes much longer, always more than 30 seconds, sometimes a full minute.

                Good luck with the indexing! I think it's still the #1 way to improve the site, if you truly can't lighten the JS load and the hosting stack isn't to blame.

      2. 2

        Since it's a single-page app, there's lots of JavaScript bundled in that's unnecessary for most users. For example, if you don't go to any of the podcast pages, you're still loading all the JS used to build and render the podcast pages. React has code splitting now, but Ember.js never really got it, so not an option for me unless I get clever. The best I can do is lazy-load external libraries.

        Additionally, since it's a "serverless" app, I have to do authentication and load data on the front end, after the initial JS payload is downloaded. That's why you see a loading screen. With a traditional server-rendered app, you can do that on the server, and even cache the rendered HTML, making things super fast.

        The most fixable thing is simply reducing the number of Firebase queries, and creating special indices in my Firebase database that help make some of my queries more efficient. Currently working on this for the homepage.

        1. 1

          Ember has Engines for code splitting. You might want to look into that.

          1. 1

            Spoken to a few people on the core team and the message is consistently, "Stay away from Engines" 😬

            1. 1

              Damn it. I didn't know that :/

    2. 1

      Do you mind sharing your search solution? Firebase (specifically Could Firestore) recommends Algolia, but it will get expensive fast for the app I want to build.

      1. 2

        I use Algolia, and it is indeed expensive :-(

    3. 1

      How is IH costs looking like? Specially Firebase, which I always hear it gets "expensive" really quickly.

      1. 1

        I spend less than $400/mo on Firebase, not bad.

  2. 10

    Clojure and ClojureScript. On the server side, this gets deployed as a single JVM jar file, the database is RethinkDB (will be switching to FoundationDB). On the client side, ClojureScript, React, Rum, Sente, Transit.

    A lot of code (actually, most if not all model code) is shared: compiled to both server-side and client-side.

    I deploy on physical servers (Hetzner), which give me a ridiculous amount of CPU and Memory for 39€/month/server. I do use Docker, but avoid any "orchestration" solutions, as their complexity is not justified in my case.

    If it wasn't for Clojure's expressiveness and the big advantages of using the same language on server side and client side, I don't think I would have been able to write and maintain such a large application by myself. The complexity would eat me alive. I am very happy with my decisions.

    The app is PartsBox, an ERP/MRP for electronics production: https://partsbox.io/

    EDIT: I forgot to add another advantage: when using the same language on the servers and on client side, you don't have to go through a different data representation. No JSON or XML for me, I just send (optimized) native Clojure data structures over websockets. This eliminates a whole huge class of potential bugs and unnecessary complexity.

    1. 2

      Glad to see another Clojure Hacker here! Who else is using Clojure for their projects on IH?

    2. 1

      Good job, that’s a nice stack.

  3. 5

    I'm using Elixir + Phoenix Framework. It's been nothing short of amazing in that it's possible to develop very quickly and the result is performant and scalable. I found it so much of a win that I've made over 100 videos teaching it, which actually turned into an indiehack. If you're comfortable with functional programming or need a very stable, scalable infrastructure (like for a free to play or ad-driven product) I'd strongly suggest checking it out. On a $5/month Digital Ocean droplet 1K + requests per second is doable and page loads are snappy.

    In the past I used Node because JavaScript was the only language I knew well. Later I moved onto Ruby on Rails for its ability to ship apps more quickly. It's still a great choice for most indies (as is Laravel). The thing that pushed me to learn Elixir was a previous startup involving a free to use video chat app with some fairly intense perf requirements.

  4. 4

    Backend

    • Django
    • Django Rest Framework to build REST APIs
    • MySQL on AWS RDS
    • AWS Elastic Beanstalk

    Frontend

    • React
    • Sass
    • AWS S3 + Cloudfront for static assets

    My main earner EditionGuard was done as a single Django app that does both the backend and frontend with some jQuery thrown in. But lately I've been building products as two separate apps for the frontend and backend, which gives me a nice seperation concerns and ability to easily outsource one or the other. Zask is the first product I built this way, and I love it!

  5. 4

    I am currently using Django/Python and I’m super happy with the choice. HTML/CSS/JavaScript of course as well. Postgres for db and digital ocean for hosting.
    Email marketing mail chimp: cause it is free
    Canva for graphics
    Adobe Premiere for Video

  6. 3

    Similar to @jwr, Clojure + ClojureScript (https://clojure.org) and using React and Ant.design from ClojureScript. PostgreSQL for database.

    Extremely happy because:

    • I'm able to use a vast ecosystem of libraries from Java and JavaScript world while having the same language on front-end and back-end.
    • There is nothing like REPL (Read-Evaluate-Print-Loop) in other languages allowing me to develop things much faster and overall results in much less code. Plus I can skip tests for the time being.
    • ClojureScript is much better than Javascript :)
    • I don't have to worry about REST and APIs. I wrote a simple 300 lines "library" that does that for me + gives me some features I like from GraphQL world. I have a simple query language using native Clojure structures to route/combine requests in one, cross-reference and bulk them. All of this in 300 lines of code, show me other languages that can do that. Link to, not very well documented, library: https://github.com/bearz/cgql
    1. 1

      Would it make sense to use Clojure / ClojureScript in conjunction with the SICP one day? Or is Scheme too different?

      1. 1

        Short answer, I wouldn't recommend it.

        I don't know Scheme and haven't read SICP but Scheme is probably the simplest language out there, so you won't have problems learning it. It will allow you to focus on what course has to teach you, participate in discussions, etc. Then you can take that knowledge and apply it for Clojure projects if you want to learn Clojure as well. To start with Clojure I highly recommend this book: https://www.braveclojure.com/clojure-for-the-brave-and-true/.

        But, when googling around I found this: http://www.sicpdistilled.com/ which answers to some extent what you asking.

  7. 2

    My intentions were

    • nodejs
    • vanilla js on frontend (some jquery)
    • ec2
    • letsEncrypt / nginx
    • on-instance mongodb

    However, I'm wondering if that stack takes too long to set up for fresh projects. Its making me consider various template / serverless options for a quick mvp. Any thoughts?

    1. 1

      Screw AWS and learn Ruby on Rails. Check out Gorails and either Heroku or Hatchbox. I say this as someone whose business is teaching Elixir!

      1. 1

        I'm trying to understand pros/cons of different techs. What are the pros and cons of heroku compared to EC2? IE, 'indications for use' / 'contraindications for use' ?

        Heroku seems like a nice solution considering all the automatic deployment / initialization / configuration scripts I've written to do much the same on EC2.

        I suppose you use it with some managed database as a service? I hear people mis-configure those constantly and leave user data exposed. Is it hard to avoid that?

        1. 1

          The primary advantages of AWS are its brand and its breadth of services and its advanced admin and roles management.

          The advantage of the two I mentioned is saving dev time.

        2. 1

          This comment was deleted a year ago.

  8. 2

    The most boring stack you'll find used by IHers is mine. PHP, Python, JS (vanilla mostly), MySQL, SQLite, PostgreSQL, Redis, and for the most part running on a simple VPS. Why? It gets the job done. Am I happy? For the most part, yeah.

  9. 2

    eventOne is comprised of a lot of different components from an API to an admin dashboard to multiple mobile apps.

    The reason I use most of those technologies is simply because they are what I know. But I recently switched to GraphQL for the API because it's amazingly awesome.

    I'm quite happy with the entire stack.

  10. 2

    My tech stack:

    Frontend:

    • Elm
    • A smattering of Jinja templates
    • A custom fork of Bulma CSS
    • Makefiles to build everything

    Backend:

    • Python (Flask + Peewee)
    • Postgres
    • Served on a DO Droplet

    I used python and flask because I was already familiar with it. I used elm because I felt kinda burned by the JS ecosystem and wanted to cut myself out from node entirely.

    I am mostly satisfied with my tech stack. I feel like my backend monolith is a bit spaghetti-y, but I'm prioritizing features and business things right now. Maybe one day I'll rewrite it in something like Pheonix.

    I also have a love (90%) hate (10%) relationship with elm. When it works, I can really fly and kick out a bunch of stuff really rapidly. I generally don't feel inhibited by the small ecosystem, but the lack of example projects kinda hurt a beginner like me. Upgrading packages is also kinda painful, and the whole BDFL aspect occasionally scares me, but in general it lives up to its promise of being rock solid.

  11. 2

    I have experience with:

    • Swift (iOS)
    • C# (ASP.Net, Dotnet Core)
    • PHP (Laravel)
    • Java
    • Microsoft SQL Server (TSQL)
    • Oracle (PLSQL)
    • PostgreSQL
    • MySQL
    • Angular
    • VueJS
    • NuxtJS
    • TypeScript
    • JavaScript

    Personally I like Swift and C# the most, as I use C# at work with Dotnet Core and Angular frontend.

  12. 2

    Rails, Postgres, Aws - Because I know these stuff and quick to get things done.

    I might move to Phoenix/Elixir or Golang for scale later

  13. 2

    Plausible uses:

    • Elixir/Phoenix as the main programming language
    • Postgresql as the main database
    • TailwindCSS to help me make things look acceptable
    • No JS framework, just a couple small libraries
    • Heroku for hosting
    • Cloudflare for DNS

    Your reasons for choosing them?

    I used to be very proficient in Ruby on Rails and I started learning Elixir when it started getting popular among the Ruby community. Phoenix feels a lot like Rails with a bunch of lessons incorporated into the design. I feel wonderfully productive with it.

    Postgresql has been my standard choice for a database for a long time. It's a SQL powerhouse, battle-tested, fully mature, amazing open-source project.

    The stack is intentionally simple, or you could even say naive. It will have to evolve to support a growing user-base. However, I'm strategically not worrying about these issues while trying to get traction :)

    And are you happy with your decision?

    So far, absolutely. I love the stack and I'm extremely productive with it.

  14. 2

    iOS - Swift
    Server - Node.js/Express & PostgreSQL

    Swift seems to be an obvious choice for iOS, I do it for my day job as well and am a big fan of the language. I chose node.js with express because it is the most familiar.

    I am happy with my decision, I think they both have suited humonym.com well, but I’m looking to advance my skills in node.js and it’s seemingly a little harder to find more advanced topics/tutorials.

  15. 2
    • Node/Express
    • React/Redux
    • jQuery
    • AWS (and all it entails)
    • MongoDB

    Chose these mostly because they were primarily used in my previous work environments so the comfort level and familiarity is there. I am happy with all the areas except a few times a year, React will release new features or deprecate old ones which forces me to consider re-writing. That's the only part that sucks.

  16. 2

    What is your tech stack?

    • Rails
    • AWS
    • Postgres

    Your reasons for choosing them?

    That said, I'm beginning to feel as an engineer I default to doing too much myself, engineers ego? ("I should just build it myself, that's what I do for a living!").

    I'm starting to discover that this approach (and tech stack) may be wrong. I need to focus on the things I'm not good at, the things I do not do all day. Maybe I'm choosing the wrong stack?

    I've been exploring less-code and no-code solutions lately so that I'm not spending all my time doing what I know best and focusing more on the business/sales/marketing/etc... side (since it's not what I do best).

    And are you happy with your decision?

    Not really, not because of technical reasons, but because of the personal reasons outlined above

    I wrote a blog post recently comparing some low-code, Rails Boilerplate Template solutions and am starting to use them in my stack as well.

    1. 1

      Solid disagree on the "focus on the things I'm not good at" if you want to take the project somewhere serious -- picking a stack you can work in effectively is critical, even if it's not sexy.

      1. 1

        Well, my point is that I spend all my time coding Boilerplate code (User management, Team management, Stripe Integrations, etc...) because I'm good at doing that stuff (and do it everyday as an engineer).

        But when trying to get a product to market and users buying it, that is the wrong stuff to heavily focus on when there are Boilerplate, Templated, Low-Code, No-Code solutions freeing me up to focus my time on Sales/Marketing/Product/etc...

        It's not about what is or is not sexy.

  17. 1

    For my new site I'm using:

    • React/Relay frontend
    • GraphQL
    • Golang backend
    • Kubernetes hosted on Digital Ocean
    • Postgres (on the k8s cluster)

    I'm new to Golang, which I chose for this project out of curiosity. So far I'm very happy with its performance and a little dissatisfied with its (lack of) expressiveness (lots of boilerplate). I suspect that most of the challenge with that is just due to my being new to Golang. I don't know how well this stack will perform under load, but I'm optimistic it could scale horizontally to handle it.

  18. 1
    • NodeJS on the server
    • Meteor as the build tool and auth service
    • Apollo GraphQL for client data caching, optimistic UI, subscriptions, etc.
    • PostGres database hosted on AWS, accessed via Sequelize
    • React
    • Material-UI React Components
    • UploadCare for image hosting
  19. 1

    Wildfly + Nginx
    Java (JSF)
    MariaDb
    BootStrap
    Cloudflare

  20. 1

    For various projects, I gravitate towards:

    • Java
    • MySQL or similar database
    • Vue.js
    • DigitalOcean
    • Various other tools (mailChimp, Carrd, postgres, etc. as the need arises)

    I'm very happy with these choices.

  21. 1
    • PHP/Laravel for back-end work and APIs
    • VueJS for front-end interfaces and general JS functionality
    • MySQL for databases
    • Flutter for iOS and Android mobile apps
  22. 1

    I'm currently working on a project with:
    AdonisJs (Node.js)
    MySQL
    jQuery
    SCSS (compiled to css with gulp)

    It will be hosted on DigitalOcean.

  23. 1
    • Nuxt/Vue for front end static site on S3/Cloudfront
    • GraphQL for "API" running on API Gateway
    • Express app running as AWS Lambda to serve ^ GraphQL
    • ReactNative for mobile
    • Mongo for data storage
    • AirTable for user friendly editable storage
    • MailChimp for email marketing
  24. 1

    www.boxycrm.io uses:

    • Java, Spring for backend
    • Angular for frontend
    • Jhipster - www.jhipster.tech as code generator
    • MySql as the main database
  25. 1

    Designer Recon uses

    • Vue.js
    • Firebase
    • SendGrid
    • Cloud Functions
  26. 1

    We are using Rails with some React front end (had to for some features to work and save dev time). That said I'd prefer now to build out as much with Rails/HTML/CSS so it's easier to work with and less complex (partially as I'm newer to coding). Overall I'm really happy using Rails and excited by the future with it.

  27. 1

    IMB uses React & Firebase (db, auth, clound fns)

    Albert uses React & hand rolled backend of NodeJS w/ postgres.

    Can't see myself hand rolling something again when I could just use Firebase for these apps. Deal with the scale problem later.

  28. 1

    Trunk uses:

    • Marketing page: Rails, Vuejs
    • App: Ember client, Rails API, Postgres, Redis
    • Devops: Docker Swarm
  29. 1

    Vuejs
    Nativescript Vue
    Tailwindcss
    Firebase
    Nodejs
    Mongo/Postgres

  30. 1

    Webrame uses:

    I'm really happy with my SPA, it enables me to scale infinitely - especially as it is statically generated.

  31. 1

    AWS for our hosting
    Terraform and Kubernetes for deployments
    Docker for development
    Postgres for our database
    Java for our back-end (WildFly, Spring and Ignite)
    Aurelia for our front-end
    E-Charts and D3 for our graphing & visualizations (though we'll be getting rid of e-charts soon)

    We love working in Aurelia, even though it's one of the more boutique javascript frameworks. We also can work very effectively in Java, even though doing things like building a plugin framework with it might be ... unintuitive. It's important for us to find tools we can work well with, without adding a bunch of overhead (both in learning, or in load time).

  32. 6

    This comment was deleted 7 months ago.

    1. 3

      I am using django for https://savedreplies.io too and I can't recommend it enough, if you know python or if you don't know any languages yet, but you want to learn a programming language and to lunch your saas as soon as possible I think django is the right choice.