It annoys me that it reverses the standard (err, value) callback convention that everyone else uses.
An advantage of the standard is that you might have 0, or 2 or more value arguments to the callback. So you can return (err) or (err, value) or (err, value, optionalExtraValue) and it's fairly consistent.
justjake 1619 days ago [-]
Wow, that's totally my bad (Write a lot of Go at my day job).
Can definitely fix that one. Will bump to 2.0.0 when I get home.
laurent123456 1618 days ago [-]
Method names that start with uppercase is also something you'll see more in Go or C# but not so much in JavaScript. `db.put()` would be the JS way.
1618 days ago [-]
giorgioz 1618 days ago [-]
I agree on this one. The convention in javascript is that functions names start with a lowercase case letter.
justjake 1618 days ago [-]
Also very true. Going into V2 deploy that I've open sourced. Will publish it this evening.
Thanks for all the feedback y'all!
breck 1619 days ago [-]
I agree with your point. Just want to mention if you are using callbacks, might be worth looking at switching to async/await.
justjake 1619 days ago [-]
It supports both! If you don't provide a callback it'll return a promise.
orf 1619 days ago [-]
Really interesting project. Couple of things:
1. Your Python library (easydbio) doesn't have the correct requirements listed. It depends on 'requests' being installed, add this to the setup.py install_requires call.
2. Make the DB class accept arguments instead of a dictionary. Just do `DB(database, token)`
3. The API is just a really simple CRUD to a single endpoint, why not include curl/httpie samples in the homepage?
4. The repository link for the Python SDK 404's (or is private). People often look at the repositories for dependencies they choose to install, not having it available is not a good signal.
justjake 1619 days ago [-]
1&2. Python isn't my first choice language so really appreciate that
3&4. Going home to open-source the JS and Python clients. cURL is a good idea, will add that too.
anonytrary 1618 days ago [-]
This site is an embodiment of the idea that "good design is when there is nothing left to take away". I was able to very quickly grok what this was, thanks to the simple UX flow of creating a db and then being told how to go play with it.
franga2000 1618 days ago [-]
And yet it completely shits itself when opened in an Android WebView ("An unknown error has occured"). It's not that it can't render - it flashes the site for half a second, then decides to delete itself and just show the error.
justjake 1618 days ago [-]
Do you have steps to repro this? I can attempt to fix it.
franga2000 1618 days ago [-]
I opened the page with the Androind HN app "Materialistic". I believe it uses the default Android WebView to display the linked website. I don't have any experience debugging things inside a WebView so I unfortunately can't help you much more than that.
jjice 1619 days ago [-]
This is great! At hackathons in the past, I usually use SQLite for development, and once everything is set, switch over to a more traditional RDBMS. This is a great site that is definitely going in the bookmarks.
Out of curiosity, can you elaborate on the the technologies you used for this (lang, frameworks, hosting services)? I've been trying to learn design patterns for larger software like this, so your insight would be great.
tbtstl 1619 days ago [-]
Glad you like it! We used to use a similar method for hackathons in the past, but we were getting tired of always having to configure databases.
We used NextJS for the UI, and Node + LevelDB on the backend.
gnahckire 1619 days ago [-]
SQLite is so awesome. I love how python has a library built-in for it.
That SQLite plus SQLAlchemy makes hackathon code so easy to port to another RDBMS after finishing the initial PoC.
Also makes it super easy to run unittests; just load data into sqlite with the memory connector and go!
justjake 1619 days ago [-]
SQLite is so great. We built this partially because we wanted SQLite's capabilities without deploys blowing away the instance.
northstar702 1619 days ago [-]
This is neat. What's the actual database behind this? What kind of data model/consistency/isolation does it offer?
justjake 1619 days ago [-]
From @tbtstl's comment
"We used NextJS for the UI, and Node + LevelDB on the backend."
Just to add: Both the frontend and backend use TypeScript.
justjake 1619 days ago [-]
>What kind of data model/consistency/isolation does it offer?
Each DB is a full new instance (with a mutex for read/write and open/close). Your data isn't shared between any other DB.
It offers read-your-writes consistency since there's no sharding/duplication ATM.
Hopefully that covers it. Otherwise happy to clarify.
I see the JavaScript has all the async and callbacks while the Python is simple procedural. What are the benefits of the JavaScript version? It's definitely harder to grok for this newbie.
I also wonder what a plain ole RESTful API would look like. Why does everything need an SDK/library?
Ex:
import requests //wish this was built in
token = '07a3e79a-c34c-4603-9a87-3fa47678d37c'
db = '51e71cb3-a40d-46bc-af3a-7bb77fde04a9'
key = 'myKey'
r = requests.get(f'https://easydb.io/{db}/{key}', auth=(token, ''))
I'm also writing up a cURL section to throw on the main page. If you want to implement a client, have at err!
I'll even put a bounty of $5 (Paid in Stellar) for each client implemented.
pbreit 1618 days ago [-]
I appreciate that, don't get me wrong.
Mine was more of a general rant on why every API seems to think it needs its own client. Simply passing JSON back and forth. What could be simpler? What do the clients do?
nu11p0inter 1619 days ago [-]
The tool looks great, seems very easy to use. The UI/UX side of it is on point. The missing information about what the product is makes me hesitant to use it.
I looked through the pages... Tried a few times to find out what happens if I decide to use your tool after the 24H.
I looked for a pricing page and failed. Makes sense if this is just your POC/demo.
So yeah, the ambiguity of all this makes it highly unattractive to even evaluate. It doesn't offer any value that a terraform RDS script or even docker-compose script that renders a template to give you the copypasta database init blocks.
justjake 1619 days ago [-]
Yup, our landing could use some clarification. We'll change it from "You'll be able to use it for 24h" to "Your data will be removed after 24h".
The target demographic is for demo/small projects ATM since it is our POC.
Terraform/docker compose is definitely the way to go for any project with substantial mass. I just got really tired of writing all that when I just wanted a JSON store.
Thanks for the feedback! It's much appreciated :D.
erikig 1619 days ago [-]
Quick Question - Are you creating an instance of the database when a user clicks "Create a Database" or when they first connect to it?
justjake 1619 days ago [-]
The database is created when the first CRUD action occurs with a uuid/token combo.
This choice was largely made to not hammer the boxes from the CDN.
vertoc 1619 days ago [-]
Awesome, this will be great for hackathons :D
didgeoridoo 1619 days ago [-]
Looks great! One thing isn’t totally clear to me: Does the database itself get removed after 24 hours, or just the data?
justjake 1619 days ago [-]
Right now just the data is removed. Your writekey will stay (unless you regenerate it from the dashboard).
jedieaston 1619 days ago [-]
Is this open-source?
justjake 1619 days ago [-]
It is not (Mainly because we have so many hard-coded API keys ATM)
Happy to open-source the clients and ingest them into the landing page if people want to write their own for their favorite lang.
breck 1619 days ago [-]
I love this. I would also love an EasyVM.
jjice 1619 days ago [-]
Like an ephemeral VPS?
breck 1618 days ago [-]
Yes. Use cases are numerous. One would be if I want to fork someone’s GitHub to make a pull request without setting up a dev environment. I wish all GitHub projects had a “launch easyVM” button that would give me an ip to a micro instance for 24 hours that I could ssh into. Then I can edit some code, Run the tests (since all the dependencies should be there), push and submit a pull request, with the server auto destroying that night.
UnbugMe 1618 days ago [-]
You should look into docker for this use case.
breck 1618 days ago [-]
Thanks, I've used Docker a lot. Too slow. I want something like EasyDB. Instant. 1 second to get a new ephemeral VM with a preconfigured image. Under the hood it could be launching containers but my experience should be that of a vm user with ssh access.
I've also created a Golang repository (http. https://github.com/EasyDB-io/Golang-Client) just for you. If you're really gungho, feel free to implement the 4 http requests using Go. In fact, If you do, I'll send you $5 via Stellar.
Otherwise I'll have to do it whenever I have a free 20m, but no promises on timeline.
I hate provisioning infra. It should be easy, and it never is.
I just want some damn state for my lambdas without spinning up Firebase...again.
gitgud 1618 days ago [-]
> I just want some damn state for my lambdas without spinning up Firebase...again.
So true, we have 2 firebase servers (dev & prod) and it took ages to setup them up even with scripts. Some of it; like backing up and restoring users isn't even possible to script!
Fast creation of database instances is a huge benefit in testing
i_am_static 1618 days ago [-]
is it possible to clear DB instead of deleting DB after 24 or 72 hours?
justjake 1618 days ago [-]
This should be the behavior as of right now
keyle 1618 days ago [-]
what's running behind this? I mean the actual DB. Couch?
An advantage of the standard is that you might have 0, or 2 or more value arguments to the callback. So you can return (err) or (err, value) or (err, value, optionalExtraValue) and it's fairly consistent.
Can definitely fix that one. Will bump to 2.0.0 when I get home.
Thanks for all the feedback y'all!
1. Your Python library (easydbio) doesn't have the correct requirements listed. It depends on 'requests' being installed, add this to the setup.py install_requires call.
2. Make the DB class accept arguments instead of a dictionary. Just do `DB(database, token)`
3. The API is just a really simple CRUD to a single endpoint, why not include curl/httpie samples in the homepage?
4. The repository link for the Python SDK 404's (or is private). People often look at the repositories for dependencies they choose to install, not having it available is not a good signal.
3&4. Going home to open-source the JS and Python clients. cURL is a good idea, will add that too.
Out of curiosity, can you elaborate on the the technologies you used for this (lang, frameworks, hosting services)? I've been trying to learn design patterns for larger software like this, so your insight would be great.
We used NextJS for the UI, and Node + LevelDB on the backend.
That SQLite plus SQLAlchemy makes hackathon code so easy to port to another RDBMS after finishing the initial PoC.
Also makes it super easy to run unittests; just load data into sqlite with the memory connector and go!
"We used NextJS for the UI, and Node + LevelDB on the backend."
Just to add: Both the frontend and backend use TypeScript.
Each DB is a full new instance (with a mutex for read/write and open/close). Your data isn't shared between any other DB.
It offers read-your-writes consistency since there's no sharding/duplication ATM.
Hopefully that covers it. Otherwise happy to clarify.
One note is that the python repl.it fails on an import error upon just hitting 'run', but it does work locally as expected.
Edit: Was able to get it working in repl.it by updating pyproject.toml like so:
Thanks for flagging it!
Super awesome project and it could be great for our users as well. I just posted to our community https://repl.it/talk/announcements/EasyDBio-one-click-databa...
I also wonder what a plain ole RESTful API would look like. Why does everything need an SDK/library?
Ex:
I'm also writing up a cURL section to throw on the main page. If you want to implement a client, have at err!
I'll even put a bounty of $5 (Paid in Stellar) for each client implemented.
Mine was more of a general rant on why every API seems to think it needs its own client. Simply passing JSON back and forth. What could be simpler? What do the clients do?
I looked through the pages... Tried a few times to find out what happens if I decide to use your tool after the 24H. I looked for a pricing page and failed. Makes sense if this is just your POC/demo.
So yeah, the ambiguity of all this makes it highly unattractive to even evaluate. It doesn't offer any value that a terraform RDS script or even docker-compose script that renders a template to give you the copypasta database init blocks.
The target demographic is for demo/small projects ATM since it is our POC.
Terraform/docker compose is definitely the way to go for any project with substantial mass. I just got really tired of writing all that when I just wanted a JSON store.
Thanks for the feedback! It's much appreciated :D.
This choice was largely made to not hammer the boxes from the CDN.
Happy to open-source the clients and ingest them into the landing page if people want to write their own for their favorite lang.
I've also created a Golang repository (http. https://github.com/EasyDB-io/Golang-Client) just for you. If you're really gungho, feel free to implement the 4 http requests using Go. In fact, If you do, I'll send you $5 via Stellar.
Otherwise I'll have to do it whenever I have a free 20m, but no promises on timeline.
http://github.com/easydb-io/golang
Done :)
I just want some damn state for my lambdas without spinning up Firebase...again.
So true, we have 2 firebase servers (dev & prod) and it took ages to setup them up even with scripts. Some of it; like backing up and restoring users isn't even possible to script!
Fast creation of database instances is a huge benefit in testing