The place where random ideas get written down and lost in time.

2019-11-28 - Quote Otter choices

Category DEV

One of the goals of Quote Otter is to try some “web stuff”.

Choices to be made:

There are two goals, and they are not conflicting: a/ learn something; failure is an option, and b/ if I get it working, it should be (re)usabl. So there’s some value in choosing a “common” framework and not something fully esoteric. Looking at you, Flutter.

To be clear, I have two choices to make: backend and frontend.

Frontend:

  • Let’s try React.
  • As guides explain, React is not a full framework and needs additional libraries to do stuff. There are a myriad of choices, so let’s get some I see floating around.
  • Routing: React router.
  • State management: Redux or MobX.
  • Fetching data (from backend): jQuery.

Backend:

  • We already run Apache.
  • Let’s try nodejs for a change.
  • The way to “integrate” nodejs with Apache is to run both. Nodejs runs on port 8080 and setup Apache to access it using a proxy/reverse proxy config (example here).
  • Some people “love nodejs” (too much?)

Local Development:

  • NPM / nodejs is apparently the way to go. Doesn’t matter where it gets deployed after.

The choice of nodejs means I can be server-agnostic and don’t even need to dev on a server, can be localhost on any machine.

More links:

One thing that the React examples do not cover is the equivalent of an easy table-to-rest scaffolding as made popular by Rails. That’s kind of what I want here. For “trivial” tables, I want a rest setup with a typical list/add/delete/edit flow (CRUD: create, read, update, delete) + scaffolding. There’s a lot of value in that for rapid prototyping. Whereas Rails is a backend+frontend combo, I’m guessing here we’ll have to deal with a “nodejs database” backend and a matching “react frontend”. What I want is something that sort of works together. ⇒ From tutorial above, nodejs uses “drivers” which are installed. I’m going to guess they each have their own API.

Speaking of “SQL vs NoSQL”, in my simplified view:

  • In an SQL database, each record has defined columns, some of which are indexed. Complex SQL-based queries can be written that act on the column data. The queries inherently “understand” the meaning of each column.
  • In a NoSQL database, each record is merely a key/value. There are no queries, except maybe operating on a range of keys. Values are akin to opaque blobs.
  • SQL is useful in an application that needs to filter the data when querying it. For example only show entries from a given camera, or sorted by username. I am going to guess that some NoSQL databases probably offer secondary index columns to do just that, where data is often duplicated from the main record into that column just for that purpose (e.g. Bigtable works like that, IIRC).
  • NoSQL is ideal when the data already exists in the form of a JSON blog. Just compute some kind of unique id and that’s the key. Then retrieve it all at the same time. When the value payload grows too large, split it in 2 (e.g. list view vs detail view) and store it in the same row.


 Generated on 2024-12-21 by Rig4j 0.1-Exp-f2c0035