Suggestions for version 2.0

[ansarizafar]

I have just discovered Nano-SQL yesterday. Its a great project with lots of potential.Here are few suggestions for version 2.0.

Consider using uWebsockets - fastest and most efficient websocket implementation with NodeJs binding https://github.com/uNetworking/uWebSockets.

Badger - Badger is a simple, efficient, and persistent key-value store. Inspired by the simplicity of LevelDB, supports Concurrent ACID Transactionsat and least 3.5x faster than RocksDB https://blog.dgraph.io/post/badger/ https://github.com/dgraph-io/badger

Add Model types Date, Geo, Secret(for encrypted vlaues/passwords ) with supporting functions or allow database adopters to add types and other features available only in that database.

Graphql is becoming very popular. A plugin for automatic generation of graphql schema from models will make NanoSQL a success overnight https://github.com/rexxars/sql-to-graphql.

A Reql like syntax https://www.rethinkdb.com/docs/introduction-to-reql/ for queries.

[only-cliches]

Hey thanks for the feedback, to answer each of your points:

uWebsockets: I'm looking at using sockette on the client side and ws on the server with an ajax fallback using unfetch. As for uWebSockets, the npm package is currently not maintained and has compatibility issues with modern NodeJS versions. The websocket implementation we end up using should support NodeJS and plug into express easily.

Badger: This looks really cool, I was looking at migrating to RocksDB and this might be an even better choice. I don't see any NPM modules for it, though. If we can't get badger setup and running with a single npm install command like we can with RocksDB and LevelDB then we'll need to stick with the latter just for the sake of simplicity. If there's a non trivial install process for this it might be a better candidate for an external adapter.

The Geo data type is basically already supported (although not documented). I am working on changing the plugin and adapter API for v2 to make it WAY more flexible. Will probably end up using a filter system similar to wordpress and put filter hooks all over the query lifecycle.

I really like the GraphQL idea and started working towards it with the denormalization features. I was planning to split those off into a seperate plugin anyway, might call it the GraphQL plugin and throw in the rest of the other GraphQL features as well.

We've got requests for Reql syntax and MongoDB syntax support, might try to set up the plugin API to make it easy to implement your own query system ontop of nanoSQL. Should make adding these other methods of query easy, might even be able to add full SQL support with SQLite Parser.

[ansarizafar]

You can also have a look at https://www.graphile.org/ and https://www.graphile.org/graphile-build/ for graphql schema generation specially https://www.graphile.org/graphile-build/look-ahead/ feature. It would be great, If we can define models with graphql SDL https://www.prisma.io/blog/graphql-sdl-schema-definition-language-6755bcb9ce51/ We should also be able to extend the generated schema with our own types and resolvers.

[ansarizafar]

Another relevant project https://github.com/genie-team/graphql-genie

[sebastianmacias]

And another relevant project is: https://github.com/hasura/graphql-engine. I have been using Hasura in a fairly big project with great success. I evaluated it vs PostGraphile and decided to go with Hasura due to the team behind, funding, their CLI and WebUI.

[ansarizafar]

@sebastianmacias Is it possible to define our own custom types and resolvers with hasura/graphql-engine.

[sebastianmacias]

Yes, you can define your own types and revolvers as well as create computed properties (using pg views) and define relationships to interact with those views, you can also trigger events (via webhooks) when certain data stored which you are interested in is updated. The WebUI really makes working with some of these features very easy.

[sebastianmacias]

Also join-monster is another interesting project to keep in mind. I think this one could actually be used as an starting point to add GraphQL support to NanoSQL. It's written in js, supports multiple SQL Dialects (you can also write your own) and has a pretty efficient query planner that sometimes runs multiple queries instead of complex joins when it's cheaper that way.

[bkniffler]

I was wondering, how difficult would it be to allow for reactive queries. While it would be super cool to subscribe to a specific query, I'm not sure if this would ever be realistic to add to a library that allows for some pretty complex queries, since data changes are not easy to trace to their depending queries.

Maybe this would need to happen on a layer above nSQL..

[only-cliches]

It wouldn't be very difficult, the problem though is the reactive queries end up being just a thin wrapper over the change listener for the table you queried.

The "reactive query" code would just be an on change listener that performs the query for you again each time the table changes and sends the result.

There's no performant way (that I've been able to find or think of) to setup reactive queries and avoid doing the full query on each change event to discover adjustments in the result, especially with the dynamic nature of nanoSQL's query engine (with functions, order by, etc).

There might be a use case where we limit the available query options or something along those lines, I guess I need to do more research to better understand the use cases of reactive queries since I haven't used them frequently in my code.