Live data from Hacker News

Ask HN: Is my software stack choice sound?

news.ycombinator.com

31–40 of 49 posts

Re: Ask HN: Is my software stack choice sound?

#31

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.

> With React Native you have the option of deploying OTA updates

How is this done? Any documentation, tutorial or example that you can point to?

> this allows you to deploy fixes and basic updates without going through the app store review process.

Does Apple and Google allow this?

Re: Ask HN: Is my software stack choice sound?

#32
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.

Re: Ask HN: Is my software stack choice sound?

#33

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.

Flutter has hot reload, does React Native?

Re: Ask HN: Is my software stack choice sound?

#34
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.

Re: Ask HN: Is my software stack choice sound?

#35

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-e…

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

Yeah, that is the intention. Have not checked if PouchDB can be used with Flutter.

Re: Ask HN: Is my software stack choice sound?

#37
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.

Re: Ask HN: Is my software stack choice sound?

#38
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.

Re: Ask HN: Is my software stack choice sound?

#39
post #6

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…

What IS GraphQL good for? The only time it seems like it's needed is when you want to ensure your front end devs can work without understanding API code. Am I missing something? P.S. not arguing - genuinely would like to know, since it never clicked. P.S.S. Definitely use Postgres - "When in doubt, Postgres" is a good axiom unless you need something very specific and know what that is. P.S.S.S. Elixir isn't that wide…

OK to give you a clear example.

Say you have a REST interface for Student and Class.

What do you do in rest if you want to get just a class? What do you do if you want to get a class and its students? What do you do if you want to get a Student and also its class?

For every iteration of the way you need to access the data you have to modify and extend your REST endpoint or do separate queries. Every time the frontend devs want new data related to existing data, they have to do another query or ask the backend to include it.

Or lets say Class has 1000 attributes. Does your REST interface return all 1000 every time? Or can the frontend specify which attributes to load? Things like computed attributes and functions that return data related to the object. GraphQL allows this.

In graphql doing these relationships is dead easy. You define a class and how a student is related to it. Then you could even ask a query like “give me the classes of a student. For each class give me all the students in those classes. For each of those students, give me their classes”. Without the backend having to add anything. All the backend has to do is define the relationship and permissions about how to access the data.

Most GraphQL libs provide helpers for avoiding n+1 queries also, so things get optimized in the above case by only making 4 queries to the DB. Obviously thats a contrived example and most nested things wont go so crazy. But it goes to show how a powerful the API can become from defining such a simple relationship.

As a backend dev you just have to work on transforming data, defining the relationships and checking permissions. You let the frontend determine what data they want to access.

Before working with REST almost every page seemed to need a specialized endpoint to be implemented for the frontend to work, but with GraphQL, the frontend can work much more independently without having to ask the backend to provide a specialized view for more data.

Re: Ask HN: Is my software stack choice sound?

#40

Earlier quoted context omitted.

What IS GraphQL good for? The only time it seems like it's needed is when you want to ensure your front end devs can work without understanding API code. Am I missing something? P.S. not arguing - genuinely would like to know, since it never clicked. P.S.S. Definitely use Postgres - "When in doubt, Postgres" is a good axiom unless you need something very specific and know what that is. P.S.S.S. Elixir isn't that wide…

OK to give you a clear example. Say you have a REST interface for Student and Class. What do you do in rest if you want to get just a class? What do you do if you want to get a class and its students? What do you do if you want to get a Student and also its class? For every iteration of the way you need to access the data you have to modify and extend your REST endpoint or do separate queries. Every time the frontend…

Isn't this exactly what SQL is supposed to be for? Why not just submit SQL queries and get the response directly from the DB?

That is to say, what differentiates GraphQL from SQL?

Post reply on HN