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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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 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, ''))
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?
59 comments
[ 5.2 ms ] story [ 116 ms ] threadAn 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!
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!
This choice was largely made to not hammer the boxes from the CDN.
"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.
Happy to open-source the clients and ingest them into the landing page if people want to write their own for their favorite lang.
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 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.
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.
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
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?