Documentation site of NextGraph.org https://docs.nextgraph.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
docs-site/src/pages/en/framework/data-first.md

56 lines
5.3 KiB

---
title: Data-First
description: NextGraph is a data-first framework where applications are just viewers and editors on Documents.
layout: ../../../layouts/MainLayout.astro
---
2 months ago
2 months ago
NextGraph is a framework for app developers who want to enjoy all the benefits of local-first, end-to-end encryption, decentralization, and the powerful combination of Semantic Data (Linked Data) with CRDTs.
We believe, like many others, that data should come first. In our data-centric approach, the user owns their data, no matter what the app is doing.
It is the same concept that has been advertised by the Solid project with their PODS (Personal Online Data Stores).
The User always remains in control of their data, and chooses a repository/server where to store all their data, and then, authorize some apps to access part of this data store. This way, the app is just a tool that manipulates the data or creates new data, but the user can always access it all, and revoke the authorization too.
With NextGraph, we push this concept even further, as the data is not managed by a POD provider/server that can see all of it in clear, as this has some negative consequences on privacy, but instead, the data in NextGraph is local-first. Which means that it is primarily stored and available locally on the devices of the users. The apps can use and modify this data directly and locally, without the need to use remote API calls or a backend.
In order to work properly, we use [CRDTs](/en/framework/crdts) that prevent merge conflict when the data is synchronized between devices.
We also use a Broker, that helps with synchronization, and that is only dealing with end-to-end encrypted data, which means that it cannot read or write the data that is exchanged on the server. You can read more about the rationals behind that in the [Encryption chapter](/en/encryption).
For the developer of an App, this means that the data is accessed and manipulated with usual APIs in javascript, and that all the syncing, encryption, and offline management happens in the background, and is transparent to the developer.
Developers of modern apps today often use some front-end frameworks like **React** and **Svelte**.
The data they manipulate is often stored in a **reactive store** (Runes in Svelte, probably useContext/useState in React) that needs to be configured and plugged to a backend system with some APIs that can range from WebSocket and GraphQL to HTTP/REST APIs to a MYSQL and so on...
2 months ago
> With NextGraph, we provide the developer with a reactive store (for React, Svelte, and Deno/Node) and that's all they have to worry about. NextGraph transparently synchronizes, encrypts and deals with permissions for you.
The developer can then focus all their efforts on the business logic, design of their app, and efficient coding with modern technologies, with very short time-to-market.
Furthermore, the User will always remain in control of their data, and interoperability is available by default to every app developer, who can also reuse and ask access to some data that was generated by other apps.
By leveraging the power of **Linked Data and RDF**, we achieve the interconnection of many different kind of data structures, formats, and schemas, and usher in the advent of a Giant Global Graph of data, with strong guarantees on privacy, security, and availability.
### Class, Viewer and Editor
Developing an App in NextGraph is as simple as defining one or several new **Classes** of data, or selecting existing classes that the app can read and/or edit, and then connecting those Classes with some Viewers and Editors.
When you define your class, you have to choose among the 3 data models that we support, and define a list of ontologies that you support. Read more about that in the [schema](/en/framework/schema) section.
The Viewers and Editors can be written in React or Svelte, and more frameworks (including vanilla JS/HTML) will be provided in the future.
We tend to prefer Svelte as this is the framework we use internally in NextGraph and it is also with Svelte that we have developed a set of Official Apps that can already handle the basic Classes and most frequent use-cases.
[Checkout what we already did](/en/features), and what is planned and what we are currently working on, because there might be no need for you to redo another app that already exists or that is already planned. Instead, you could join our community of developers and participate in creating or improving existing apps.
As the goal of NextGraph is to give the smoothest experience to our users, we put a lot of efforts in order to offer a tightly integrated environment to them, that you can try when you open our [official app](/en/getting-started).
If you have innovative ideas for a new app and you want to work with permissive licenses, you can make a proposal for a new app in [our forum](https://forum.nextgraph.org) and we will work together to bring your vision about.
If we code this new app in Svelte, it will have more chances to integrate the official apps and be part of the basic features every user can enjoy.
But of course, it is always possible to code in React, and also to publish your app in any other way, without coordinating your efforts with us. Read more about that in the [Ecosystem chapter](/en/ecosystem).
Now let's read more about [CRDTs and the 3 data models](/en/framework/crdts) that we offer.