I just found something quite cool which I thought might be interesting to some of you.
Alon Zaka created emskripten, a LLVM-to-JavaScript converter. It can convert LLVM-bytecode such as provided by compilation from C/C++ code into JavaScript. This approach seems quite cool and it already proved to produce some cool results:
He converted the SQLite-library, which is written in C, into JavaScript. You can find (and fork) the project on github or just try the demo.
The first thing that I was curious about was: How does it store the database file? Well, it creates a new database when you do SQL.open(). But you can pass data to SQL.open(data) to start with a pre-filled database. So I think using this library would normally look like this:
- fetch the initial database from the server (e.g using AJAX). At least DB schema and some important data.
- open the database with SQL.js
- do some operations on the database, mostly SELECTs probably
- maybe fetch some more data using AJAX from the server when needed
- maybe send some data to the server to save changes using form or ajax
So this would mean we move some more stuff to the client. It would allow us to use SQL on the client side just like we do on the server-side. So we could use the same queries for javascript-based clients on the client and for html-only-clients on the server. (But exposing SQL-queries used in the server might make SQL injection as easy as never before…)
I see two other interesting ways of using this:
- In combination with HTML5 local storage – this would allow to store a persistent client-side database that could be accessed using SQL. Sounds pretty cool and the main usage scenario of SQL.js for me.
- On the server using node.js – but when I think about it: There are better ways to access a database within node.js, so this is probably only showing that it works, but no real usage scenario.
Tell me what you think about it.
Parece Interesante, voy a seguir en laces, llevo todo el dia leyendo.
Tengo algunas dudas?
Sql lite sera compatible con ie y crome, pues vi un grafica que ponia que no.
Los enlaces me llevaran a algun sitio? o volvere a dar tumbos como en toda la mañana.
Y por ultimo, Realmente este paradigma, del uso de base de datos en servidor-cliente, es lo que usan app como whatssap?
Comment by Adrian — 13. March 2013 @ 13:49
Ahora no se si utilizar node.js o que?
Veo que el enlace de ejemplo ya no funciona, y no tengo muy claro cuantos archivos necesito del repositorio de gitub?
Por donde Tiro?
Sigo buscando info de sql.js ….
En fin no me gusta nada Gitub!!
Comment by Adrian — 13. March 2013 @ 13:56
@Adrian: Sorry, my Spanish is not good enough to understand everything you say. And it is far from good enough to answer in Spanish – so here we go in English:
Regarding apps like whatsapp: I think they usually use the normal SQLite library. See http://www.vogella.com/articles/AndroidSQLite/article.html for a tutorial on how to use SQLite in a (Java) Android app. You can use Phonegap (Apache Cordova) to build JS-based apps for example that can use the phone API to SQLite http://docs.phonegap.com/en/2.5.0/cordova_storage_storage.md.html#Storage and are even platform-independent.
But in theory, JavaScript based apps might make use of sql.js, yes. I don’t know if there is already any that does.
The “paradigma” of using a small-size DB (SQLite) on the client (the smartphone) however is something that Mobile apps do already for a long time, correct.
Yes, the demo link is currently broken. I could not find a working link, the same one is still used on the official github page. Maybe it will work again soon.
No, I don’t use sql.js with node.js as I don’t think it’s a good way to use SQLite from node.js. Was just an idea.
Comment by Christopher Kramer — 13. March 2013 @ 19:52
Alon Zakai does not maintain sql.js anymore. I do. See http://github.com/lovasoa/sql.js
Comment by lovasoa — 29. May 2014 @ 21:58