7:Fortune.js is a non-native graph [database abstraction layer](https://en.wikipedia.org/wiki/Database_abstraction_layer) that implements graph-like features on the application-level for Node.js and web browsers. It provides a common interface for databases, as well as relationships, inverse updates, referential integrity, which are built upon assumptions in the data model.
11:- Bi-directional relationships in any database.
13:- Sharing the same data models on the server and client.
21:*This is the core module. Additional features such as networking (HTTP, WebSocket), database adapters, serialization formats are listed in the [plugins page](http://fortune.js.org/plugins).*
26:Only record type definitions need to be provided. These definitions describe what data types may belong on a record and what relationships they may have, for which Fortune.js does inverse updates and maintains referential integrity. Here's an example of a basic micro-blogging service:
39:    // Many-to-one relationship of user posts to post author.
45:    // One-to-many relationship of post author to user posts.
51:Note that the primary key `id` is reserved, so there is no need to specify this. Links are `id`s that are maintained internally at the application-level by Fortune.js, and are always denormalized so that every link has a back-link. What this also means is that changes in a record will affect the links in related records.
53:By default, the data is persisted in memory (and IndexedDB for the browser). There are adapters for databases such as [MongoDB](https://github.com/fortunejs/fortune-mongodb), [Postgres](https://github.com/fortunejs/fortune-postgres), and [NeDB](https://github.com/fortunejs/fortune-nedb). See the [plugins page](http://fortune.js.org/plugins/) for more details.
59:// argument is used for finding related records in the same request and is
61:// the adapter. All methods return promises.
63:store.create(type, records, include, meta) // Records required.
104:Based on whether or not the resolved record is different from what was passed in, serializers may decide not to show the resolved record of the output hook for update and delete requests.
122:There is a [HTTP listener implementation](https://github.com/fortunejs/fortune-http), which returns a Node.js request listener that may be composed within larger applications. It maps Fortune requests and responses to the HTTP protocol automatically:
125:// Bring your own HTTP! This makes it easier to add SSL and allows the user to
126:// choose between different HTTP implementations, such as HTTP/2.
129:const fortuneHTTP = require('fortune-http')
133:// The `fortuneHTTP` function returns a listener function which does
134:// content negotiation, and maps the internal response to a HTTP response.
135:const listener = fortuneHTTP(store)
136:const server = http.createServer((request, response) =>
140:store.connect().then(() => server.listen(1337))
143:This yields an *ad hoc* JSON over HTTP API, as well as a HTML interface for humans. There are also serializers for [Micro API](https://github.com/fortunejs/fortune-micro-api) (JSON-LD) and [JSON API](https://github.com/fortunejs/fortune-json-api).
150:- Inverse relationship updates, automatically maintain both sides of relationships between records.
151:- Referential integrity, ensure that links must be valid at the application level.
153:- Adapter interface, use any database that can implement an adapter.
