from Hacker News

Ask HN: Is my software stack choice sound?

by m33k44 on 8/3/22, 1:32 PM with 48 comments

• by 3pt14159 on 8/3/22, 1:53 PM

  REST vs GraphQL doesn't really matter for this type of app. Since you're restricting the choice between Phoenix/Elixir and Wt, I'd definitely go the former, but you'll have something out the door even faster with Ruby or Python. I'm not just speculating here, I worked with a C/C++ dev before when we used Ruby for a project and he was blown away at how much more productive he was.

  As for CouchDB vs Postgres: "When in doubt, Postgres." Has never failed me. I burned a lot of time on other DB systems[0], but in the end Postgres was always easier for the whole picture of what a DB should do from backups to persistent to extensions, everything really. Never tried CouchDB though.

  Anyway, seems like a good project to try out some new tech since it should be pretty easy. Whatever you choose should be fine for your first 100k users.

  [0] Riak, Mongo, hand rolled custom graph DB based on BerkleyDB, tried to make Neo4J work, even wrote a persistence layer for NetworkX at one point.

• by mooreds on 8/3/22, 1:43 PM

  For a side project, you need to decide if you are trying to stretch your skillset on a fun project, or deliver software as quickly as possible to see if there's money to be made.

  Either choice is fine, but pick one. Choose whether you want to learn or earn.

  In this case, if you want to learn, pick elixir/graphql. From what you've said, that'll be quite the learning experience.

  If, on the other hand, you want to earn (or at least get something shipped as soon as possible so you can test the market), pick the Wt option.

• by hectormalot on 8/3/22, 2:25 PM

  I'd pick PostgreSQL over CouchDB because it is so common, has great documentation, and many people say it is a great default choice.

  For quickly launching an API enabled backend, maybe look at encore.dev? It's not one of your listed languages (it's go), but at least it looks somewhat like C.

  I recently had to launch an API for a hackathon, and this was as fast as Ruby on Rails for me. Comes out of the box with Postgres and PubSub (2 lines of code if you need it). Encore also does the infra provisioning and hosting for you (either your cloud, or for free at their cloud). Tip: add `sqlc` for the queries, it works well together with Encore.

  GraphQL/REST: it looks like your app will have a limited set of calls that are easy to predefine. In that case, REST wins hands down. IMO GraphQL really shines if you have (a) a data model with many relations, (b) possibly from different underlying systems/services, and/or (c) different people working on the front-end/consumption side vs the data exposure side. But that's beyond 'a simple app'.

  Other tip: if you're thinking of building an admin interface. Don't, just use something like Retool first while you're getting users.

• by hansonkd13 on 8/3/22, 2:00 PM

  I would say -> GraphqL + Phoenix + Postgres

  From my perspective I wouldn’t choose CouchDB. For one, its a pretty obscure DB that doesn’t have a lot of support. For example almost all major hosting providers now allow you to launch an app with Postgres hosting out of the box.

  Way way way way more tools and articles for building an app with postgres.

  Also I would recommend Postgres to take full advantage of Phoenix and Ecto (the ORM). In Elixir GraphQL and Ecto are deeply integrated to avoid n+1 queries when you are writing nested lookups.

  In my opinion having used Django, RoR, frameworks in Go and Rust, Elixir has the most robust and powerful ORM out of any language and it would be a shame to miss out on it by using CouchDB.

  I prefer GraphQL over REST tremendously. For a large site, in REST we had this process of the Frontend would have to tell the backend what data they wanted, the backend would make the endpoint and then the frontend would consume it.

  With Graphql the backend just defined all available data and the frontend picks and chooses what it needs. GrqphQL also prevents weird n+1 requests where you need to request the data of the children from a previous REST result.

  GraphqL + Phoenix + Postgres is a game changer IMO

• by 63 on 8/3/22, 1:56 PM

  It really depends on how much learning you're up for. If you just want to refresh your skills and have the best chance of actually delivering something, go with what you know.

  If you're just making this because you're excited about new tech and want to see what it's like to work with, then by all means go with the more experimental stack but understand that it will take longer and will be riskier.

• by halefx on 8/3/22, 1:52 PM

  Your goal should be iteration. Pick the simplest way to make this idea work with as few things as possible (preferably one) and make that. Then add another technology to upgrade it, etc. It should be usable after each step and improve each time. If you try to build a new project using that many new languages, tools, and methodologies, you won't finish.

• by btmills on 8/3/22, 2:17 PM

  For new projects, both at work or on the side, I like to imagine I have a “new stuff budget.” That forces me to spend it wisely.

  If I over-spend my new stuff budget, I take on debt, much like tech debt, that I’ll have to pay down later. I’ll make slower progress because I’m trying to learn too many things at once, and I’ll have to go back and fix suboptimal tradeoffs where I didn’t have enough experience to make the right tradeoff at the time.

  Conversely, if I don’t spend the new stuff budget at all, then I won’t learn anything new and might miss out on a tool that would have made the problem easier.

  For side projects where the whole point is learning, sometimes I’ll spend my new stuff budget by e.g. learning a new frontend framework first, writing the backend in something I know. Then once I’m familiar with everything and have built back up the new stuff budget, I’ll go back and reimplement the backend in the new language I wanted to use, leaving the rest of the stack unchanged.

• by ch4s3 on 8/3/22, 2:09 PM

  As others are pointing out, CouchDB may not be a bad choice but it's probably more cumbersome than necessary. Phoenix/Elixir are great and I use them at work every day. The default assumption in Phoenix is a Postgres database and the data mapper Ecto works really well with Postgres. If you use fly.io or render.com for web app hosting, they both have super easy guides for Elixir/Phoenix + Postgres.

  REST might be easier to get up and running with too, because Phoenix does it out of the box. You could then move to GraphQL iteratively once you have your core logic in place and the Flutter app working.

  Overall I think you find Elixir refreshing coming from a language like C++. The tools all work pretty well and are easy to learn. The REPL is nice. The package manager is world class. Testing is built into the language. The developer experience is just really great.

• by brunojppb on 8/3/22, 1:56 PM

  Elixir + Phoenix sound like a great stack. I've been building a side-project with that stack and it has been a joy.

  With that being said, I believe it might be quite a learning curve for you. Not because it will be difficult, but just because there might be many topics at once to learn. Like you said, GraphQL, Postgres, Elixir (and a little bit about the BEAM ecosystem), Phoenix and CouchDB. If you are doing anything for the Web, you will inevitably touch JavaScript as well.

  Not sure if you are open for suggestions, but one thing you could consider would be using JavaScript or TypeScript with NodeJS. I'm not the biggest fan, but you would be able to use the same programming language in the frontend for our Web app and also the backend with NodeJS and a full-stack framework like Remix[1] or NextJS[2]

  This could reduce the overhead to start your side-project and will give you fewer puzzle parts to learn and put together.

  [1] Remix: https://remix.run/ [2] NextJS: https://nextjs.org/

• by gwbas1c on 8/3/22, 3:06 PM

  Regarding a database: Going outside of SQL is always risky. In your case, it's only worth using CouchDB if you're excited to learn something new.

  In my experience, the one time I used CouchDB I found it so flakey that I recommended we refactor to use a normal SQL database. Of course, a lot has changed; but:

  The big power of a relational database is that it's extremely easy to just tweak your indexes and get views of your data that you didn't anticipate when you created your schema. Document databases like CouchDB (and MongoDB) require that your data is organized in a way similar to how you're going to query it.

  The other power of a relational database is transactional integrity. You can update multiple rows in different tables, and the update either happens or it doesn't. Updating multiple documents in CouchDB (or MongoDB) doesn't have the same guarantee, meaning that your data can be corrupted by an incomplete update.

• by 1ark on 8/3/22, 3:10 PM

  Go with the first option, since you have skills in C++. Flutter is well documented and a lot of hand-holding. If you find that you don't like that Wt backend after some time, you can rewrite it with the second option. By then you are familiar with Flutter and probably will only have to do some minor modifications. GraphQL is good for when you want to arbitrarily query/populate data on separate screens for example, where you need a subset och merge with other data. Since it is a side-project and you write the backend yourself, you might not need that, because you can edit that code in REST on your own or just make a new endpoint. A big strong point for GraphQL is that it removes the communication and development friction between frontend and backend engineers.

• by Gordonjcp on 8/3/22, 2:20 PM

  I don't know anything about mobile development and not a lot about frontend.

  I'd do the backend with Django and Postgresql. You can't go wrong with Postgresql, it's an industrial strength database. Nothing wrong with MariaDB (or Mysql for that matter), either, I just prefer Postgres.

  Writing your backend in Django will allow you to get the basic functionality working in an afternoon. Don't worry too much about getting all fancy with the user models at least to begin with, or any "clever" stuff. Don't worry about doing it at Google scale until you're half way towards Google traffic.

  You can use generic views in Django to rough out a web UI for it, then make it as fancy as you like with Flutter.

• by namelosw on 8/3/22, 2:14 PM

  May I ask why CouchDB though? Is it for the offline support?

  Phoenix comes with its own database tool called Ecto[0] which is excellent, and it uses Postgres by default. If you're not intended to leverage CouchDB for offline support you should go Postgres without a second thought.

  That said, I'm also curious about how to implement offline support with Phoenix in a nice and trivial way.

  [0] https://github.com/elixir-ecto/ecto

• by SanderNL on 8/3/22, 3:18 PM

  You ask if this stack is "sound". I'd say it is not.

  Most of the techs you mention are immense, humongous beasts. I'd say drop them all.

  If you really, really need an "app" instead of wrapping a simple website I'd go for React Native to skip the native stacks and something easy on the backend because it will not matter in the slightest what you use: Python/flask, Node, Go. Whatever floats you boat, but keep it simple. (I think you may like Go as a C programmer.)

  Database? SQLite or PostgreSQL.

• by okhuman on 8/3/22, 2:09 PM

  I dropped postgres for sqlite and never looked back - incredibly easy to manage and spin up applications like https://github.com/authcompanion/authcompanion2

  This post sold me on it https://blog.wesleyac.com/posts/consider-sqlite

• by KMnO4 on 8/3/22, 2:02 PM

  Build software to your strengths. GraphQL is cool, but a complete paradigm shift from RDBMS. If you choose it, you WILL spend a lot of time struggling to figure it out.

  Flutter is a good choice if you know it, but it’s terse and barebones, and honestly you’ll grok JS a lot easier coming from a C background.

  If I were you, I would go for REST/Wt/Postgres on the backend and JS with Cordova + some UI library (Ionic or Framework7?) for the frontend.

• by Areading314 on 8/3/22, 2:23 PM

  Do not use C++ for a rest API. I would recommend using common boring tech, and ignore the "magic bullet" promises of languages like elixir.

  I find in my personal projects using python backend (flask or django), with a postgres database almost always leads to the most useful work getting done quickly. There are a lot of ways to make python fast if you know C++ when you need it.

  I'm not familiar with Flutter, no opinion there.

• by pera on 8/3/22, 2:14 PM

  Ecto is one of the "killer apps" in the Elixir ecosystem and you will very likely want to use it with Postgres.

• by madlynormal on 8/3/22, 2:32 PM

  Give serious thought about using React Native over Flutter: 1) You can use JavaScript/TypeScript instead of learning another bespoke language (Dart). 2) With React Native you have the option of deploying OTA updates, this allows you to deploy fixes and basic updates without going through the app store review process.

• by oxff on 8/3/22, 2:42 PM

  You need to consider the maintenance / upgrade / patching (bug fixes etc.) burden too. For "fire and forget" projects you put to Heroku and forget about, almost any meme stack will do. For projects where you think you'll be maintaining it for 1-10 years, you have to be bit smarter.

• by warrenm on 8/3/22, 2:07 PM

  The most "sound" software stack is the one you already know, or that you most want to learn

• by 4ad on 8/3/22, 2:08 PM

  The best software stack is the one you are most familiar with. The likelihood of being negatively impacted by your choice of software stack in the beginning is practically zero.

  Of course, in the long run, this is reversed.

• by uhtred on 8/3/22, 2:21 PM

  You could probably get it done fast and easily with Perl CGI scripts and SQLite. But I realize that doesn't sound as cool. More fun though unless you enjoy learning frameworks etc.

• by aristofun on 8/3/22, 3:07 PM

  If your goal is speed and simplicity you just implement the backend in a day with rails rest scaffold.

• by waspight on 8/3/22, 9:00 PM

  Just pick the stack you are already most comfortable with. That is the only thing that matters.

• by PaulHoule on 8/3/22, 1:43 PM

  You mean SMS messages?