11–20 of 49 posts
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.
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…
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 widely used. If you want something simple use FastAPI with Python or Flask. For real projects, .NET Core API will work well, but it's a little slower to set up if you don't use a template. Your C/C++ WILL carry you through C# though. This choice will REALLY depend on what language you want to learn - most of them have good API frameworks.
Of course, in the long run, this is reversed.
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…
CouchDB is a json document based noSql system that is exposed through traditional HTTP calls (e.g. GET to get a document, POST to create a new document, PUT to update a document, and DELETE to delete a document).
In the "expose data via REST" the stack is often "service doing SQL against a RDBMS" and that service is a either Java or Python or Ruby... that can often (not always) be done as "here is couch, with this data stored in it." It's memory and CPU footprint (even doing a 3x replication in our k8s environment) is a fraction of a Java container, much less a Java container and a database.
Grab a couchdb docker compose and spin it up and give it a try. It has a built in admin console. https://docs.couchdb.org/en/3.2.2/index.html
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.
This post sold me on it https://blog.wesleyac.com/posts/consider-sqlite
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 F…
Its also not even much a paradigm shift in my experience. Queries are simply analogs to GETs and Mutations are analogs to POSTS. Thats about all you need to know to get started. To convert a REST app to a GraphQL app is ridiculously straight forward. What it does much better than REST is nested lookups, being typed, and being able to request more than one piece of data at a time.
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…
> Never tried CouchDB though CouchDB is a json document based noSql system that is exposed through traditional HTTP calls (e.g. GET to get a document, POST to create a new document, PUT to update a document, and DELETE to delete a document). In the "expose data via REST" the stack is often "service doing SQL against a RDBMS" and that service is a either Java or Python or Ruby... that can often (not always) be done as…
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.