RDBMS FOSS Approach

Introduction

- What is a database?
- Flat files vs RDBMS

Desktop

Cloud

FOSS RDBMS Applications

- Desktop - LibreBase
- Cloud - MySQL (MariaDB), Postgres (PostgreSQL)

CRUD - REST

https://softwareengineering.stackexchange.com/questions/120716/difference-between-rest-and-crud

CRUD means the basic operations to be done in a data repository. You directly handle records or data objects; apart from these operations, the records are passive entities. Typically it's just database tables and records.

REST, on the other hand, operates on resource representations, each one identified by an URL. These are typically not data objects, but complex object abstractions.

For example, a resource can be a user's comment. That means not only a record in a 'comment' table, but also its relationships with the 'user' resource, the post that comment is attached to, maybe another comment that it responds to.

Operating on the comment isn't a primitive database operation, it can have significant side effects, like firing an alert to the original poster, or recalculating some game-like 'points', or updating some 'followers stream'.

Also, a resource representation includes hypertext (check the HATEOAS principle), allowing the designer to express relationships between resources, or guiding the REST client in an operation's workflow.

In short, CRUD is a set primitive operations (mostly for databases and static data storages), while REST is a very high-level API style (mostly for web services and other 'live' systems).

The first one manipulates basic data, the other interacts with a complex system.

https://tyk.io/blog/rest-never-crud/

REST is about constraining the way we interact between client and server, to take advantage of what the protocol (in this case, HTTP) offers. These constraints give us freedom to focus on our API design:

Uniform interface – requests from different clients look the same, whether the client is a browser, mobile device, or anything else
Client-server separation – the client and the server act independently and the interaction between them is only in the form of requests and responses
Stateless – the server does not remember anything about the user who uses the API, so all necessary information to process the request must be provided by the client on each request. Note: this isn’t about storing server-side state
Layered system – the client is agnostic as to how many layers, if any, there are between the client and the actual server responding to the request. This is a key principle of HTTP, allowing for caching servers, reverse proxies, and access security layering – all transparent to the client sending the request
Cacheable – the server response must contain information about whether or not the data is cacheable, allowing the client and/or intermediaries (see layered constraint, above) to cache data outside of the API server
Code-on-demand (optional) – the client can request code from the server, usually in the form of a script, for client-side execution
Again, there is nothing about REST requiring a resource with a CRUD-based lifecycle. CRUD is a pattern we can apply to our APIs, but it isn’t a requirement for composing a REST-based API.

This gives us a little more freedom when we design our APIs, as we can offer resources with a CRUD-based lifecycle when it is appropriate, while mixing in functional resources when CRUD isn’t necessary.

We don’t have to be limited to this pattern when designing APIs. Let’s explore some other options that can help us design a great API that meet the needs of current and future developers.

MVC

The Model-View-Controller (MVC) is an architectural pattern that separates an application into three main logical components: the model, the view, and the controller. Each of these components are built to handle specific development aspects of an application. MVC is one of the most frequently used industry-standard web development framework to create scalable and extensible projects.

https://www.tutorialspoint.com/mvc_framework/mvc_framework_introduction.htm

Software Architecture - Framework

Model

The Model component corresponds to all the data-related logic that the user works with. This can represent either the data that is being transferred between the View and Controller components or any other business logic-related data. For example, a Customer object will retrieve the customer information from the database, manipulate it and update it data back to the database or use it to render data.

View

The View component is used for all the UI logic of the application. For example, the Customer view will include all the UI components such as text boxes, drop downs, etc. that the final user interacts with.

Controller

Controllers act as an interface between Model and View components to process all the business logic and incoming requests, manipulate data using the Model component and interact with the Views to render the final output. For example, the Customer controller will handle all the interactions and inputs from the Customer View and update the database using the Customer Model. The same controller will be used to view the Customer data.

Flow Steps

Step 1 − The client browser sends request to the MVC Application.

Step 2 − Global.ascx receives this request and performs routing based on the URL of the incoming request using the RouteTable, RouteData, UrlRoutingModule and MvcRouteHandler objects.

Step 3 − This routing operation calls the appropriate controller and executes it using the IControllerFactory object and MvcHandler object's Execute method.

Step 4 − The Controller processes the data using Model and invokes the appropriate method using ControllerActionInvoker object

Step 5 − The processed Model is then passed to the View, which in turn renders the final output.

IDE

Atom
MS Visual Studio
NetBeans
Video Studio Code

Frontend vs Backend

Logical Design

References & Links

1. https://developer.chrome.com/apps/app_frameworks
2. https://www.bbconsult.co.uk/blog/top-10-javascript-mvc-frameworks
3. https://jquerymobile.com/about/
4. https://angularjs.org/
5. https://emberjs.com/
6. https://www.esri.com/arcgis-blog/products/developers/constituent-engagement/10-open-source-projects-every-javascript-geo-dev-should-know-about/
7. https://www.mdpi.com/2076-3263/8/4/139/htm
8.